Early in my career, I was convinced there was “good code” and “bad code”. That you could look at something and — without knowing anything about the context — pass judgement on it.
These days, my views are much more nuanced. I try to adapt my style to the situation. The code I write, and the process I use, depends a lot more on what the goals are. Am I trying to bang together a quick prototype to learn something? Or am I fixing a bug that might affect hundreds of thousands of users? My approach would be completely different in those two scenarios.
Years ago, I read Edward De Bono’s Six Thinking Hats, which describes a framework for problem solving and creative thinking. The idea is that you can “put on a hat” to deliberately adopt a specific mode of thinking. It’s a bit corny but (imo) there’s a useful idea there.
Maybe this applies to different styles of programming, too? What “coding hats” do I use?
Dubroy suggests five “programming hats”: Captain (by the book code for mission critical systems), Scrappy (minimalist style for MVPs), MacGyver (figuring out if something is even possible), Chef (beautiful code), and Teacher (emphasizing communication and demonstration).
I like this concept. It reminds me of the idea of register in language. In many languages, speakers adapt their language to the situation and who they are speaking with. With code, it’s the same. The type of code I write for a production service, a one-off script, and a personal project is different and this “hat” concept is a useful one to categorize them. A mismatch between hats seems like a common interview failure mode to me. For example, you wrote in Captain’s mode because you wanted to show off how careful you can be, but the interviewer wanted the Scrappy mode because they wanted to see how you could react to changes.