I’m a terrible cook.
I can make food that is functional as sustenance, but rarely is it delicious.
Tonight was my night to cook dinner, and my wife handed me a recipe sheet titled “Easy Fried Rice.”
I read through the full recipe (one side of one sheet) and set out all the necessary ingredients and cookware. Thinking that was plenty of prep work, I got right to heating the oil in the skillet and began prepping the spices.
By the time I had the tiny bit of ginger grated and a few cloves of garlic smashed up, the oil was already hot. I threw in the spices and knew I’d have plenty of time to crack and whisk the eggs. Once the eggs were ready, I turned around to a smoking skillet full of blackened ginger and garlic and saw exactly how mistaken I was.
This experience was not unlike a poorly executed software project. I got some basic requirements but didn’t really dig any deeper. I didn’t ask any questions, I did the bare minimum of design, and I just started writing code. All too quickly I found out how wrong my assumptions about implementing the requirements were.
On my second attempt at the rice, I prepped all of the spices, eggs, and other ingredients, separated them all in their own containers, and set them on the counter in the order I would need them – all before I ever turned the stovetop on again.
Typing the code is only the transferring of the food to the plate for a recipe that took weeks to perfect. The best software developers will spend the majority of their time staring out the window – or perhaps talking to a rubber duck – mulling over problems, planning out solutions, iterating through possible outcomes and potential pitfalls. The act of typing is tertiary and could be done by just about anyone.
Writing code is easy – perhaps even easier than “Easy Fried Rice.”
Creating clean, readable, maintainable, professional code takes considerate collaboration, critical thinking, and patience.