All new code is sh*t!
Nov 28, 2023
Some of you probably saw this and scoffed, "Not mine". If that was you 🫵, stop reading this and start looking for a new job. I imagine you're significantly underpaid!
Have they gone yet? Good, I wouldn't say it to their face, but their code is shit too!
Now that it's just us mere mortals let's continue.
All new code is shit!
Sounds controversial? It's not! We can all think of examples of shit code, maybe from code we committed or famous stories from Google, Nasa, Moonpig, etc, etc... etc.
There are layers of protection in engineering teams. Unit tests, pair programming, PR reviews, automated regression tests, manual testing, What's it all they for if not to catch shit code before it becomes "live shit code"?
A lot of additional effort is spent on every dev task!
Would you skip all other steps if a dev said, "It's good"? Probably not. After being a developer for over two decades, I would never say this if I thought something was going straight out! It's only "good enough" to proceed to the next stage of checks.
It's a lot of time! And it's a lot of new code to test new code. The Unit tests and any new automated regression tests are new code, and "all new code is shit".
Let's get ridiculous for a second. Should the automated regression tests have unit tests? Should there be a testing team that tests the testing team? Should it be "Testers all the way down"?
Good devs, shit code!
It's "all new code is shit," not "developers are shit"! Most code nowadays is developed in "a sprint".
Have you ever tried making an omelet in a sprint? You'd likely break as many legs as eggs. Has anyone ever done their best work with someone watching over them, whispering "I thought this was only 3 points of effort".
The development process is broken, but that's another rant for another day! The takeaway is all great code came from a dev, but it probably started as "new shit code".
Credit: Mo Selim
How does "new shit code" become "great code"?
It's not like fine wine or whiskey, which improves with age, changing on a chemical level. Nor is it like a Magikarp evolving almost instantly from shitness to greatness.
Great code is more like nostalgia from a song you initially had no love for.
You might even have hated the song when it first came out and would grit your teeth if you ever heard it played in the background of a shop. But then, one day, you hear it again, and it hits differently. It hasn't changed, but it has stood the test of time, and now you have a greater appreciation for its beauty. You even find yourself enjoying it. It's gone from shit to great without changing.
Time is the only factor that proves code. If it's shit, you or your customers will catch it, eventually. The code will change from "new shit code" to "newer shit code" and the clock resets.
How do we move fast while increasing the "great code" percentage?
I'd suggest two things:
Use code that is already tried and tested. Your dev team is likely doing this, utilizing open-source modules or third parties.
Stop testing your bespoke "new shit code" with your own bespoke "new shit code".
End. Fin. Stop reading!
You're still reading! Stop it!
Ok, so now it's just me pondering to myself. Some more cynically-minded people will see a marketing piece than an honest rant. They will think, "If my new code is shit, why isn't their new code shit, too?". I guess it is, or was, or is a mixture of both.
Maybe I should address this in the post? But would that seem defensive? Probably.
Maybe I should make the point that although time is the only factor that proves code, it’s not measured in days, one to the next, but in seconds of use. hmm.
Anyway, I better get back to writing some more shit code... send it!
