[ibimage==33465==Original==none==self==null]
This is a post shared from Jason's new blog, Venture Evolved, which examines the venture capital business and the startup world through the lens of a software engineer. Follow Jason on Twitter to get notified of new posts.
Last week I had a conversation with a Chicago-based 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.
