Programmers love to optimize their code and their tools. Why then is there so much slow and bloated code and so many arcane and fragile tool chains? Because programmers aren’t always optimizing for efficiency. There are many things programmers can optimize for, and a team can quickly end up working at cross purposes when everyone is optimizing for something different. Here are just a few of the things programmers optimize for:
Speed, memory usage, efficiency
What most of us think we mean when we talk about optimizing: making the code as fast and efficient as possible.
There’s a line between concise expression and obfuscation that we recognize when we see it, except in our own code. If you can’t easily understand someone’s code because it’s too terse, and they defend it by citing Occam’s Razor, that line has been crossed.
The flip side of conciseness. Some programmers enjoy making code more complicated than necessary, but usually this optimization is a side-effect of forgetting YAGNI (You Aren’t Gonna Need It) or going off into the weeds with a new language.
When a programmer spends a lot of time lining up comments, converting tabs to spaces, converting all variable names to a single style, etc. they are optimizing to relieve their OCD. Converting all variables to Hungarian notation and forcing the team to comply “for consistency” is an extreme form of this optimization and may require an intervention.
Looking ahead to the next code review or scrum, the programmer writes code that they can show off to the team. The code will be just clever or obscure enough to require the author to explain it to everyone and show how clever he or she is.
GitHub, StackOverflow, etc.
Showing off in public, and usually looking forward to either adulation or picking a fight in an online forum.
Job security, technical debt
Code is written with an eye to making maintenance and future enhancements difficult for anyone else. When a programmer is recognized as the only person who can work with a code base they are guaranteed employment.
Ritual, ideology, purity
Everything must comply with a methodology or fad. Programming decisions are defended by appeals to the authority of scrum, TDD, functional programming, etc.
Passive-aggression, being right
Failing to persuade co-workers to do it their way, the programmer changes a big chunk of code over the weekend to force the team to come around. Replacing a crucial piece of the testing or build process with something written in that cool new language is an example of this optimization.
Nothing will be released until everything conforms to the opinion of an expert. Tufte and Nielsen will be referenced.
The project is optimized to make a new language or tool seem like a good solution. Programmers read about something cool online and suddenly the project can’t succeed without it.
The code is optimized so all unit tests are green.
Not wanting to be blamed for anything leads to code that can be defended against any criticism.
Creating roadblocks and diversions in the code to force a meeting about the new problems. Meetings are an opportunity for schedule and specification changes.
The code is optimized to meet ever-changing marketing requirements. These are frequently in conflict with each other, to say nothing of core business requirements, leading to HAL 9000 syndrome.
Code has to be written so the least-skilled programmers can understand it and work on it.