I find it useful to think of Software Engineers as part of one of two buckets: Application Developers and Computer Scientists.
Computer Scientists work for large tech companies like Google or Facebook. At Big Tech, you’re going to become an ultra-specialist where they give you some tiny bit of code that they want you to optimize the hell out of. The priority for Computer Scientists is Scale and Performance regardless of Productivity or Maintainability. It makes financial sense to pay someone $200k+ to spend an year working on a few lines of code, that already work, to reduce execution time from 20ms to 15ms. If that code gets executed a hundred million times per day, that 5ms reduction can save the company $2mm in server costs over the next three years.
Application Developers work pretty much everywhere else—particularly for enterprise level companies whose primary revenue stream is not based on selling software. Most of the software that exists will be used by, at most, a few hundred concurrent users and most of those users are employees of the company. Early stage start-ups also fall into this bucket. The priority for Application Developers is to achieve Maintainability and Productivity. It needs to be done quickly, it has to work, and someone other than you is going to have to dig into this thing four years from now so don’t leave them a slapped together mess.
It’s important for you to understand what kind of team you are, regardless of where you work or what your title is. For anyone with a Computer Science background working as an Application Developer, I recommend Jonathan Blow’s excellent talk Programing Aesthetics Learned From Developing Independent Games. He outlines the major mistakes that Computer Scientists make when asked to do Application Development:
- Optimizations require assumptions about usage
- Assumptions make code brittle
- Most code is not performance sensitive
- Therefore optimizations are usually bad
If you’re working at an early stage start-up or in enterprise, you don’t have Google-level scaling and performance problems. Your job is to churn out high volumes of quality application code that aren’t spaghetti. Notice nowhere in there does it say “that supports one million concurrent users”. Every optimization necessary to support a million users comes with a trade off. That tradeoff is usually maintainability.
- Optimizations make code harder to understand
- I need to understand to make changes without breaking anything
- Optimizing one part of the code is bad
- Optimizing the entire system is a disaster
For Big Tech it’s not a problem that the optimized code is more difficult to understand and maintain. They are going to have way more people dedicated to that code and will document the hell out of it. Either way it’s not really an option for them. At that scale you have no choice.
Everywhere else those optimizations will get you something that you don’t need—Scale—and come at the direct cost of something you desperately need—Maintainability. You should never optimize something until you are forced to.
Start-ups who aspire to become big tech companies make the mistake of scaling too soon. Facebook can’t do “Lean Startup” anymore. If they’re going to roll something out it’s either half a billion users or no one. They have no choice but to spend six months developing new feature. You don’t have half a billion users, you have thirteen.
Your priority as a start-up is Productivity. You don’t even need Maintainability. Assume all the code you are writing is going to be thrown away. Try lots of things and toss them. Even after you figure out what works, throw away all your prototypes and replace them. Now you’re back to the Application Developer priorities of Maintainability and Productivity. You have too many features on your roadmap to waste time optimizing code that doesn’t need it.
I work with Application Development teams who are stacked with talent and everything they make is overdue and full of bugs. They’re all making the same mistake: someone taught them that optimizing for Performance and Redundancy will get them Maintainability and Productivity. If you want to be a high-performance software team, first you have to know what kind of team you are.
You’re not Google.
Let me know what you thought of this post: firstname.lastname@example.org.
I read every email.