Chaos Is Our EmployerPabloBlockedUnblockFollowFollowingMar 22Almost five years ago Peter Welch wrote his epic and sad-but-true essay Programming Sucks.
I really love his writing and I find the article very interesting and mostly true, but it also contains what I consider a pretty common misconception:Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer.
It’s a different file for every programmer.
Sometimes they wrote it, sometimes they found it and knew they had to save it.
They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.
This file is Good Code.
It has sensible and consistent names for functions and variables.
It doesn’t do anything obviously stupid.
It has never had to live in the wild, or answer to a sales team.
It does exactly one, mundane, specific thing, and it does it well.
It was written by a single person, and never touched by another.
It reads like poetry written by someone over thirty.
I used to share that idealistic vision of our job: code can be something beautiful and poetic, and can take us to other worlds of perfection and simplicity, like a symphony that makes objects dance and magic happen by directing a choreography of data flowing along the methods.
But nobody really cares.
Even if it’s beautiful in the theory.
A program has to solve a problem, a real one if possible, just like books are meant to be read, roads are meant to be driven on, or board games are meant to be played.
And all of that has to happen in the cruel, unglamorous, and unpoetic reality.
Books are made of paper and ink.
They have to be printed by noisy machines, distributed by polluting trucks, and sold by people who work for money.
The number of pages has to be a multiple of 4, the cover can’t be made of marble, and the ink should be black, or dark at the very least.
Let’s say you write a book and in your mind yellow ink represents pure perfection.
To you, using plain old-fashioned black ink means bowing down to the market’s ruthlessness.
Well, tough luck.
You still have to use black ink.
It has to be printed and it has to be read by someone.
It has to be in touch with reality.
Yosemite from Tunnel View, CaliforniaThe same applies to software.
Maybe the first version was a beautiful piece of code and you feel that all those weird requirements ruined everything (“Why do they want to be able to change that? Why do they need such granular permissions? Why are the stupid colors so important? Why do they need this super complex algorithm for such a shitty task?”).
The world out there is full of chaos.
Trying to extract a slice of that chaos and represent it with a program can be tedious and frustrating.
You start the day in front of your computer, willing to do engineer stuff to make the world a better place while creating pure beauty, just to find yourself eight hours later crying and sinking in the mud because everything keeps changing and you are supposed to turn that stupid set of random requirements written on a paper napkin into production software.
But for me, the beauty is actually there.
The real challenge is to build something that is able to survive that chaos, against all odds, and that at the same time serves a purpose and is loved by the people using it.
There is no merit in building something and keeping it in your drawer, just for you.
That program might look beautiful, but it won’t survive in the light of the sun.
That’s why the hypothetical developer Peter Welch wrote about turns off the lights before opening his program.
He needs to keep it safe from the real world.
But that program has to run, it has to be exposed to stupid users, to production outages, and to the business problem it’s trying to solve, in order to prove its value and show its actual beauty.
The chaos out there is not our enemy, it is our employer (or our customer!), and one that pays us pretty well, mostly because dealing with it is not for everyone.
We are engineers.
We build things that have a purpose, things that have to solve a real problem, ideally a very complex and expensive one.
The type of problem you hire an engineer for.