By now you’ve probably seen some bad code.
Code that looks like wild grass growing out of an abandoned highway.
You’ve probably also expressed hatred and disgust towards the code either loudly in front of everyone or privately when no one’s looking.
You say to yourself, “I’m going to end this once and for all so that nobody on this team, including myself, will ever write code this bad again.”
So you wait for that opportunity to refactor, rewrite, or rebuild from the ground up.
Because when that opportunity comes, things will start to change for the better for good. You will set things straight and do things right the first time around.
That opportunity arrives. Your blood start pumping, an excitement and drive you haven’t felt in a long time.
You know exactly what the first thing to do is, and the second, and the third, and the fifteenth; you feel like your fingers are not typing fast enough to keep up with all these cool ideas you have in your brain:
- I’m gonna add a linter so everyone will be the same page in terms of coding styles
- I’ll put in a git hook to format all the code anyway so that standard styleguide is enforced
- Why don’t I also throw in an automated script to generate folder and file structures so people can’t screw it up to begin with
- Oh and we need TypeScript because it prevents people from writing implicit and confusing APIs
- Let’s not forget Redux because it forces everything we write to be functional
- It goes without saying that from now on we’ll start writing tests, so I will have that set up perfectly as well
As you work on this single-source-of-truth-for-our-team-projects base project, you announce to everyone that help and savior is about to be here to eliminate future bad code forever.
Then this one-week project turns into a two-weeker…
Then you get pulled into more urgent and high priority tasks, so the two-weeker goes into the backlog…
But you haven’t given up. In week 4, you finally picked it back up and finished it!
The best part is, everyone’s on board with the standards, patterns, best practices and coercions (read automatic scripts) you’ve included.
The manager gave you a go ahead as well!
From then on, you’ve proven that you are the chosen one, the savior of bad code, and the visionary who prevents future bad code.
You are secretly appreciated by juniors on the team because they are learning a lot.
You get praises from other experienced devs on the team while they whisper to each others’ ears, “I hate this new project template”.
3 months go by.
People have accepted and adopted your amazing base project structure that you promised and over-delivered on.
There’s only one problem: people’s velocity dropped.
The majority of the sprints turned into turning off or bypassing the features you included as part of this bad-code-killer-project-starter-template-kit.
This project-starter-template-kit has officially become an over-engineered and hard to maintain pile of dread.
“Shit,” you say to yourself, “where did it all go wrong?”
“I meant to improve the developer-experience, but I end up losing everyone’s sanity.”
Sometimes the code can be so bad that it creates fear in you:
- fear that you will have to deal with bad code again
- fear that your reputation goes down the drain because of someone else’s bad decisions
- fear that you yourself would end up writing bad code like this because of pressure, and you know others will hate you just like how you hate bad code writers
So you set out to prove that you stand against bad code.
You will use your skills to end it once and for all.
This fear has gotten to you — deep as well.
It causes you to lose your cool because you are so irritated and frustrated by it.
It causes you to exaggerate how big a problem it is and bring a tank to a sword fight (swords can hurt real good).
Bad code creates fear, and fear creates over-engineering.