Application Developer vs. Computer Scientist

One of the most poorly understood problems we have in our industry is our failure to recognize that Application Developers and Computer Scientists are actual two entirely separate careers. Instead, we continue to refer to both of these as “Programmers” or “Software Engineers”. Because we don’t understand this difference, we continue to hire smart people to do the wrong job and the results are disastrous.

Computer Scientist

A Computer Scientist’s role is to optimize code to run as fast as possible, while using as few computing resources as possible. They are trained to analyze the time complexity and space complexity of an algorithm, and have a familiarity with a large number of algorithms and data structures.

Training as a Computer Scientist is necessary to write code that is performance-sensitive. For code to be performance-sensitive, generally, it will either be required to process unusually large quantities of data, or it will be required to finish executing in an unusually short period of time (or, both).

A Computer Scientist has a low rate of individual Productivity. Their work takes a much longer time to complete, and the code they produce is difficult to understand and very fragile, which decreases its Maintainability.

Computer Scientists work for large tech companies like Google or Facebook. A company this size will pay a Computer Scientist $200k+ to spend an entire year to reduce the execution time of a few lines of code from 20ms to 15ms. If this code gets executed a hundred million times per day, that 5ms reduction might save the company $2mm in server costs over the next several years, which is well worth that $200k salary.

Application Developer

An Application Developer’s job is to deliver new value and functionality to the end-user at a high rate of Productivity sustained for a long periods of time. They must maintain this level of Productivity without sacrificing the software’s Quality.

In order to sustain both high software Quality and a high rate of individual Productivity, the software must be designed in a way that maximizes the Maintainability of the application. It needs to be done quickly, it has to work, and six months from now someone other than you is going to have to make changes to it without breaking it.

Almost all of the code an Application Developer will write is NOT performance-sensitive. Selecting a sub-optimal algorithm or data structure will have a trivial and insignificant impact on the end-user’s experience.

Application Developers work pretty much everywhere—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 because their only user is their Mom.

Confessions of a Former Computer Scientist

For anyone with a Computer Science background who finds themselves working as an Application Developer, I highly recommend Jonathan Blow’s outstanding talk Programing Aesthetics Learned From Developing Independent Games. Programming video games for consoles is difficult. You have to write 100,000 lines of c++ code, by yourself, finish in three years, and all that code has to never leak any memory and never crash.

To succeed in video game development you have to be 10x more productive than the average programmer and your code has to be bulletproof. How did Jonathan Blow do it? He had to stop thinking like a Computer Scientist, and learn how to think like an Application Developer.

Think Like An Application Developer

  • Optimizations require assumptions about usage
  • Assumptions make code brittle
  • Most code is not performance sensitive
  • Therefore optimizations are usually bad

Every time we micro-optimize the code for Performance, that optimization comes with a trade off. Most people don’t know what that trade off is, which is a terrifying thought. To optimize for increased Performance the trade off we are making is almost always decreased 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

When To Optimize For Performance

If optimizing code for Performance is so bad then why do big tech companies do it? Because they don’t have a choice—they are forced to. They have to support so many users that in order to do anything at that scale, it must be optimized for Performance. They compensate by hiring the absolute best talent and pay them above market rate. You’d be surprised what can be overcome by hiring insanely smart people and paying them what they deserve. For most companies, this is not option.

Everywhere else those optimizations will get you something that you don’t need—Performance—and come at the direct cost of something you desperately need—Maintainability. Never optimize for Performance until you are forced to.

When To Optimize For Productivity

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 a new feature. You don’t have half a billion users, you have thirteen.

Enterprise Teams

I work with Application Development teams who are stacked with talent and yet their apps are still full of bugs and releasing new features is painfully slow. They all make the same mistake: they are trying to do Application Development with a Computer Scientist mindset.

Performance optimized code takes more time to write and more time to debug. And this mistake just keeps on giving: not only does it take longer up front, but every change and update you make in the future will be slower as well. Think about all the time spent by dozens or hundreds of developers on optimizations that yielded no noticeable difference to the end-user. Now think about all the features you didn’t work on because you spent time doing that instead. You have too many features on your roadmap to waste time optimizing code that doesn’t need it.

Early Stage Start-Up Teams

Your priority as a start-up is Productivity and nothing else. 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 re-write them. Then go back to the enterprise Application Developer priorities of Maintainability and Productivity.

Published by David Zuidema

Master Software Craftsman