Humans Are Shit — Replace Them With Tools
How Human Input is Bogging Down Your Software Development Processes
--
Introduction
I usually keep my articles strictly technical and straight to the point.
This one, however, will have a bitchy and philosophical tone, and that’s for a reason. It serves as a sort of manifesto of a developer determined to streamline processes by replacing as much human input as possible with cold, hard machines.
In this article, I will discuss how human input bogs software development processes and the proposed solutions.
Humans Are Inherently Flawed
Provocative title aside, I am not a socially inept misanthrope. However, it doesn’t take one to recognize that humans are inherently flawed.
We get tired, lose focus, lose motivation or give up.
We lose passion, stop giving a fuck or cut corners to meet deadlines.
We have egos. We get angry, emotional, and defensive.
Humans are shit. — Gilfoyle, “Silicon Valley”
We like to make choices and form opinions.
When presented with a choice, different people will more often than not form different opinions and make different choices. Guess what happens next?
Choice Leads to Opinions — Opinions Lead To Friction
Show of hands: How many of you have spent time and energy discussing code style, linting rules, or different ways of achieving the same thing?
This probably occurs with every project where a language with no strong, tooling-enforced opinions is used.
More so, It’s true for most human interactions. The outcome of every relationship, both personal and professional, is largely defined by our ability to understand and convey opinions.
“Opinions are like assholes— everybody has one, and they all stink.” — an old adage
I’m sure you have wondered many times if all this could somehow be avoided. Well, it turns out, it can.
Removing Choice Removes Friction
As you might know, if you’re one of my readers, I have a background in C#. Even though it’s an extremely productive tool and an absolute joy to work with, it carries with it decades of opinions and a lot of room for choice.
While most of my professional time is spent within the .NET ecosystem, my passion for everything software development-related has led me to explore many different technologies.
Lately, I’ve been working extensively with Go and Flutter. The thing Google seems to have figured out is that proper tooling eliminates a lot of friction inside teams.
Go and Flutter enforce style and formatting on the language level.
The result?
Code Style or formatting discussions? Nonexistent. Hours spent each week formatting code? Zero.
Go takes this notion to the extreme: everything should be simple. There should, preferably, be only one way of achieving a single thing. This helps reduce opinions, preferences, and discussions related to them.
It is such a refreshing concept, especially if you’re coming from old communities with decades of accumulated opinions and dozens of different ways to achieve the same thing, such as .NET, Java, or JavaScript.
The JavaScript community has tried to enforce this with tools like prettier, but they have only partially succeeded because they made the mistake of allowing configuration, and thus, opinions.
“But I like using code as an artistic medium and expressing myself”, you might think. Thinking emotionally, I would probably agree. However, that’s not our job.
Time Spent Not Delivering Value Is Time Wasted
As fun as toying around with code is, we deliver value by solving business problems, not by playing with format, style, and the new obscure pattern we read about.
Our purpose is to consistently deliver functioning, efficient, and maintainable code. The business value we produce is what earns our pay checks.
At the end of the day, the most important is how productive we are and how much we contribute toward a common goal.
Chasing productivity, however, can often lead to its evil twin sister — pseudo-productivity.
Pseudo-productivity
It’s easy to fall into the trap of doing pseudo-productive bullshit to try and create a perception of contribution and/or trigger those feel-good hormones.
We’ve all done it. It looks like you’re working, it feels like you’re being productive, but you’re not achieving anything of value.
I consider pseudo-productivity to be all actions or discussions that are subjective, opinionated, don’t add business value, and, more importantly, could be done by a machine.
Your usual suspects include, but are not limited to: menial tasks, manual testing (mostly), code style discussions, code smell discussions, format discussions, or nitpicking PR reviews that add any kind of opinion on the aforementioned.
Not only are they pseudo-productive, but by not delegating them to machines, we’re effectively wasting time.
Doing Work That a Machine Can Do is a Waste of Time
Humans have bad days, get tired, inattentive, and lose focus and motivation.
A well-programmed machine on the other hand will do its job 100% right 100% of the time. A machine doesn’t have bad days, get tired, inattentive, and lose focus or motivation. It doesn’t care whether it’s being compensated fairly or not. It doesn’t cut corners because it has a deadline to meet.
Even as I’m writing this article, a tool is constantly checking my grammar and style. It’s not because I’m illiterate or don’t have a reasonably good grasp of English. It’s because a machine is inherently superior at that task, and not utilizing it would be a waste of time.
Automating and delegating this task to a machine is a no-brainer.
Automate Everything
This kind of automation should be employed as much as possible.
Most teams will find automating their Pull Request workflow extremely valuable. I believe PRs are one of the most misused concepts in software development. Most of the time, they allow too much room for ego-driven discussions.
They require a lot of time and great discipline, restraint, and people skills to ensure a productive exchange of ideas without anyone feeling hurt — which can be challenging.
They could be so much more if they relied less on humans.
Instead of wasting time on analyzing and commenting on code smells, why not introduce a static analyzer (linter) into your pipeline? A linter won’t base its feeling of personal worth on whether it adds input to a meaningless discussion. Make adhering to the linter mandatory and introduce it into the pipeline. No exceptions, no choice — no feelings.
Instead of discussing code style, why not enforce it on language level (Go), or pre-commit hook + pipeline (tools like prettier for JS)?
Save the human energy for things we cannot (yet) dump onto the machines, like the big picture, strategy, and architectural decisions.
Make the PRs a part of the feedback loop and an instrument for knowledge sharing, not a place that fosters unproductive quarrels.
Don’t keep it limited to just code, either. Expand this principle onto as many processes as you can.
There’s time and place for manual work and creativity — encourage it where it’s valuable and aggressively restrain it where it’s not.
Final Thoughts
Have you been losing hours resolving issues that could’ve been prevented by automated processes?
Have you been engaging in pseudo-productive bullshit? Have you been doing work that a machine could do?
Any thoughts, stories, opinions? Leave a comment.
