I know how to write good code.
Usually it means spending more time now to make the code better for some future state of the world. This assumes that I know what the future will look like. In software we rarely know what the future holds.
In software we rarely know what the future holds
Uncertainty can be caused by:
When I have uncertainty about the future, cycle time is most important. It allows me to capture value from my code by: learning as quickly as possible, minimizing impacts of bad or faulty code, as well as shortening my time to market.
Any friction hurts my cycle time. This decreases the rate I can turn uncertainty into certainty aka learning. My longest term value is created by learning as quickly as possible, since it is a multiplier for all future code I write or systems I design. Said another way: As “writing is re-writing”, coding is refactoring.
My longest term value is created by learning as quickly as possible
Here is why you should write shitty code. Or more precisely, why you should write MORE shitty code.
If you want to learn how to write code the best way to develop that skill is practice. I have found I can read all I want, but I don’t retain the lesson until I type the code with my fingers. Coding is a skill that is not learned in a day. It is a way of thinking and approaching problems. It is a collection of knowledge about tools and computing environments. The only way to develop this knowledge is to use the tools and environments. Each time I write code the easier and less shitty the next time will be.
Each time I write code the easier and less shitty the next time will be
Writing shitty code means focusing on getting to the outcome as quickly as possible. This means getting to that feeling of success and satisfaction that something, anything is working. I wrote my first line of code about three decades ago, I still get a thrill each time I get a new piece of code working.
Systems fail. I have found that these are the most precious opportunities to learn. My biggest learnings have come not from making some quality trade-off I anticipated, it was some behavior or input to the system that I never even considered. If I spend time building something that is “flawless” I am emotionally invested in it working. Then, when something goes wrong I look for errors external to the code I wrote.
When I write shitty code I have no emotional attachment to it functioning. When it fails I assume it is the weakest link and dive into learning more about the code and system. This mental state is a state of wonder and joy.
No code runs wholly in isolation. Each unexpected failure (by definition) is something that I didn’t understand. Therefore each failure is a perfectly crafted lesson that is adaptively constructed for me to maximize my learning.
When I code I have several standard loops of feedback. When I write shitty code I turn up the frequency of those feedback loops. This naturally puts pressure on me to understand where to look and how to look for output from the code I am writing. Each time I write code I learn more about my tools. I could learn a new keyboard short-cut for my editor or I could write a script for some manual step in the testing process. The point is that each time I write code I improve the quality of my tools and my understanding of those tools.
If I am writing code to do something that I am unfamiliar with, which is basically all the code I write, because otherwise it would be refactoring, I don’t know the design space. I don’t know what is possible because I don’t know what I don’t know.
In drawing classes sometimes they assign variation studies. Basically you come up with 5 or 10 initial sketches from some prompt. Then you draw 5 or 10 variations of each. This is an exploration of the design space. Sometimes I find myself comparing two possible designs. This is a limitation on what is truly possible. There are more likely to be dozens of different possible designs. Writing more shitty code lets me see more of what is possible. I look up from where I stand and see the whole landscape of possibility.
Writing more shitty code lets me see more of what is possible
I know I mentioned this in previous reasons, however the change in emotional state I experience when I let go of the ego of my code being “right”, is monumental. Instead of feeling frustration or irritation I feel wonder, discovery, joy and a sense of accomplishment. Even if all the other reasons are wrong, the difference in personal emotional state is worth writing more shitty code.
Instead of feeling frustration or irritation I feel wonder, discovery, joy
A lot of senior experienced people will talk about all the “shoulds” your code should be like. They are usually describing some far distance promised land that they have never visited either. Some of these “shoulds” are packaged as frameworks to help think through tradeoffs in system design. The best have an explicit out clause for knowing when the rules don’t apply. In the end they are helpful if they guide you, and are not if they slow you down.
Said another way, know where you are headed but embrace the shittyness of producing code for today.
Enter your email If you would like to get an email the next time we post.
We post about ~1-3x per month, and up to once a month about company news.
Why you should write MORE shitty code and feel good about it.
If you have ever worked with AWS as a developer then you will know what I mean, AWS tools suck. They suck so bad there is an entire industry focused on solving for this pile of suck. For just Infrastructure as Code, for example, there are Terraform, Pulumi and Serverless. AWS is famous for "listening to customers". So what gives? Why do their tools still feel clunky, complex and riddled with infuriating edge cases?