The Differences Among Junior & Senior Developers & Architects

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on RedditEmail this to someone
Last week I had a conversation with a founder about hiring development talent. It’s no secret that there is a shortage of software development talent in Chicago and throughout the country. A natural response to the constrained supply of developers is to widen your net, increase compensation and/or lower your standards. None of those are fun but it is a reality in today’s world. 
We talked about the pros/cons of hiring junior development talent versus senior development talent. The question posed was is it better to hire two junior developers or one senior developer? It occured to me during the talk that the essence of the difference between junior and senior developers is this: an ability to understand tradeoffs. 
Software, like any engineering pursuit, requires engineers to make tradeoffs. Is your software trying to optimize response time? Ease of coding? Storage? Cost to operate? Revenue? Efficiency/compute cycles? Reliability? I could go on and on. Not all of these are mutually exclusive, but emphasis on one aspect is typically at the expense of another and should be a conscious choice. And understanding the implications of these decisions takes time and experience. Twitter early on relied on Ruby on Rails for its backend. It wasn’t until several years into the company as it started to scale where the tradeoff between ease of coding (a strength of Ruby) and scalability (Ruby’s weakness at the time) reared its ugly head.  Remember getting the fail whale regularly? Eventually Twitter rewrote the backend in C++, a language that has proven its ability to scale. But this introduced complexity of maintaining a system written in multiple languages– something that a more mature Twitter organization was able to handle at that time but perhaps not at the outset. Many systems that scale wind up making different decisions about these tradeoffs over time. 
The main point here is that junior developers typically lack the experience of seeing how these tradeoffs and architecture decisions manifest themselves in the real world. Yes, a good junior developer from a good school will understand the tradeoffs, but until you see them work in an organic, living, breathing system it’s just a different story. It’s easier to ignore these tradeoffs (either consciously or unconsciously) and just crank out code. That requires rewrites later and results in a system that is making different tradeoffs than what the business requirements would dictate. 
A strong architect goes a long way to help guide junior developers. But developers in a startup are making lots of small decisions on the fly that in aggregate can have big implications. The architect can’t be looking over every dev’s shoulder. And in a lot of startup environments, the founder is the architect and the founder is overwhelmed with a million different things. So there is a lot more comfort in having a senior developer in these environments because of their longer-term view and understanding of the implications of architecting for the future. 
The other thing to highlight for founders out there who are not technical is that there is a big difference between someone who can be a software architect (or engineer) and a software developer. Architects choose the programming language, database, hosting infrastructure, development toolkits and set development standards. These people deeply understand the various tradeoffs just like an architect of a building understands cost vs. safety vs. aesthetics vs. function etc. This is different than software developers who use the framework established by the architects to build the software. Much like a general contractor. It’s design vs. building. As you spend your time and dollars recruiting this talent, make sure you understand the difference. 
Tweet about this on TwitterShare on LinkedInShare on FacebookShare on RedditEmail this to someone
  • TaskMaster

    Totally agree, but its often tough at the startup stage to think long term. There is an initial drive to push the product out the door and get initial users. As you rightly state, many startups are developer constrained and go with the best development talent available at the time…this often leads to longer term heart ache and swiss cheese code, but at least you validate the market

  • jheltzer

    TaskMaster, you are right. Hopefully after reading this post, startups will appreciate that they are making the tradeoff that you describe, even if they don’t have a choice: they are trading conservation of resources in the short term, for the long term cost of having to rewrite code/rearchitect. If there is no long term, then it wasn’t much of a tradeoff.

Copyright © 2014 Jason Heltzer