njonsson/The difference between the junior and senior Rails developer

## The difference between the junior and senior Rails developer
Someone recently asked the following question in the discussion forum of the Rubyists LinkedIn group: What separates a junior Rails developer from a senior one?

My response follows. Join us at http://www.linkedin.com/groups?gid=120725 to weigh in on this and other topics of interest to Rubyists. As of today there are almost 1,200 members, including numerous movers and shakers in the Ruby and Rails communities.

“Distinguishing between junior and senior people in the Rails world is not so different from making the distinction in other web development environments.

“Junior Rails people have not dealt with scaling issues to the degree that senior people have. Getting a public-facing Rails application to perform under significant stress is more challenging than doing the same with other building materials such as PHP. Senior people know how to performance-test Rails applications, where to look for bottlenecks, and how to eliminate them one after another until performance is acceptable in real conditions. The Rails community loves to poke fun at the notion that ‘Rails Doesn’t Scale.’ All joking aside, surviving a traffic spike and handling increasing load with Rails is no laughing matter.

“Junior people are less experienced with deployment issues. Rails was created to scratch the itch of speeding web development, so its advantages show up in programming tasks, not when it comes time to push to production. Most senior people have used multiple deployment tools and know their limitations and pain points.

“Junior people are less disciplined and experienced in regard to automated testing best practices. Testing can be a bit of a trap in that it’s easy to invest too much effort in the wrong places. Senior people have used multiple libraries and DSLs for testing and understand the purpose and relative value of testing at the unit level, the integration level, and the system level. Senior people know the pain points of testing client-side code and why it’s important to do it right. Senior people know the value of clean, well-tested code, and also that testing has to be right-sized for the team and the product being built.

“Junior people are less likely to have ventured outside the standard Rails stack. Senior people have used a templating DSL other than ERb, an ORM library other than Active Record, and databases other than MySQL and SQLite. They’ve written secure authentication from scratch as well as having used plugins for it. They have experience with background processes, web services interop (RESTful and/or otherwise), and other aspects of connected application development. Senior people have also dipped their toes in the water of other Ruby web frameworks, and they know something about progressive web server frameworks written in languages other than Ruby.

“Junior people generally know more about the Rails framework than they do about the Ruby language. Senior people recognize that the power and beauty of Rails comes from its basis in Ruby. They can explain how Ruby makes possible all the killer features of Rails, and how the Rails clones for other languages and platforms are hobbled by the language they are built on. Senior people have no fear about delving into the Rails source code.

“Junior people don’t understand as profoundly all the reasons why Rails is such a huge win. Lots of people have got on the Rails bandwagon in the five years since the first release in summer of 2004. Not all of them have battle scars from diverse experience writing code for the web. Senior people can articulate why Rails has caused a tsunami across the open-source and commercial market space, changing the shape of new frameworks and established ones. Senior people can tell you where the best ideas in Ruby and in Rails come from, how they’ve developed over time, and where they’re going in the near future.

“Junior people are more likely to think technology is all that matters. Senior people know that small teams of experienced players, who communicate well with each other and their stakeholders, are the secret sauce to building the right product on time and under budget. Senior people can explain the advantages and drawbacks of various project management approaches and which ones are best suited to a given situation.

“This post is starting to feel a little curmudgeonly with all the talk about ‘senior’ vs ‘junior’ — sorry.”
	Someone recently asked the following question in the discussion forum of the Rubyists LinkedIn group: What separates a junior Rails developer from a senior one?

	My response follows. Join us at http://www.linkedin.com/groups?gid=120725 to weigh in on this and other topics of interest to Rubyists. As of today there are almost 1,200 members, including numerous movers and shakers in the Ruby and Rails communities.

	“Distinguishing between junior and senior people in the Rails world is not so different from making the distinction in other web development environments.

	“Junior Rails people have not dealt with scaling issues to the degree that senior people have. Getting a public-facing Rails application to perform under significant stress is more challenging than doing the same with other building materials such as PHP. Senior people know how to performance-test Rails applications, where to look for bottlenecks, and how to eliminate them one after another until performance is acceptable in real conditions. The Rails community loves to poke fun at the notion that ‘Rails Doesn’t Scale.’ All joking aside, surviving a traffic spike and handling increasing load with Rails is no laughing matter.

	“Junior people are less experienced with deployment issues. Rails was created to scratch the itch of speeding web development, so its advantages show up in programming tasks, not when it comes time to push to production. Most senior people have used multiple deployment tools and know their limitations and pain points.

	“Junior people are less disciplined and experienced in regard to automated testing best practices. Testing can be a bit of a trap in that it’s easy to invest too much effort in the wrong places. Senior people have used multiple libraries and DSLs for testing and understand the purpose and relative value of testing at the unit level, the integration level, and the system level. Senior people know the pain points of testing client-side code and why it’s important to do it right. Senior people know the value of clean, well-tested code, and also that testing has to be right-sized for the team and the product being built.

	“Junior people are less likely to have ventured outside the standard Rails stack. Senior people have used a templating DSL other than ERb, an ORM library other than Active Record, and databases other than MySQL and SQLite. They’ve written secure authentication from scratch as well as having used plugins for it. They have experience with background processes, web services interop (RESTful and/or otherwise), and other aspects of connected application development. Senior people have also dipped their toes in the water of other Ruby web frameworks, and they know something about progressive web server frameworks written in languages other than Ruby.

	“Junior people generally know more about the Rails framework than they do about the Ruby language. Senior people recognize that the power and beauty of Rails comes from its basis in Ruby. They can explain how Ruby makes possible all the killer features of Rails, and how the Rails clones for other languages and platforms are hobbled by the language they are built on. Senior people have no fear about delving into the Rails source code.

	“Junior people don’t understand as profoundly all the reasons why Rails is such a huge win. Lots of people have got on the Rails bandwagon in the five years since the first release in summer of 2004. Not all of them have battle scars from diverse experience writing code for the web. Senior people can articulate why Rails has caused a tsunami across the open-source and commercial market space, changing the shape of new frameworks and established ones. Senior people can tell you where the best ideas in Ruby and in Rails come from, how they’ve developed over time, and where they’re going in the near future.

	“Junior people are more likely to think technology is all that matters. Senior people know that small teams of experienced players, who communicate well with each other and their stakeholders, are the secret sauce to building the right product on time and under budget. Senior people can explain the advantages and drawbacks of various project management approaches and which ones are best suited to a given situation.

	“This post is starting to feel a little curmudgeonly with all the talk about ‘senior’ vs ‘junior’ — sorry.”