Five coding hats
23 comments
·February 6, 2025disambiguation
Putting on my nitpick hat:
I think scrappy and mcguyver could be the same hat.
I also think chef here is really craftsman, whereas chef makes me think of cooking, as in playful discovery, which is worth its own hat.
As someone else mentioned, war time / emergency this is not a drill hat deserves a spot on the shelf.
aidenn0
IIUC scrappy is just poorly named; it's about taking a minimalist approach, which IMO is distinct from the "baling wire and duct-tape" implied by the MacGyver approach.
The former might be worth keeping around, the latter is firmly in the "build one to throw away" territory.
em-bee
right, scrappy is about implementing the bare minimum needed, keeping it small and simple, and mcgyver is about using what gives me the fastest results, even if that means hooking up wordpress to mongodb and using excel as the interface to input data.
RossBencina
FWIW I know a self-described scrappy who is definitely in the mcgyver category.
aqueueaqueue
There is another hat: the space helmet. This is for the architecture astronaut. When you see the word Monad in Java code, this is likely them.
Blackarea
Looks like different flavors of doing it "clean" and going "hacky". No real content here imo tbh - Hat analogy is fun though
pdimitar
This could be formulated much better IMO but it's good that OP gave us this to check out and comment on.
I'd simplify this to "commercial hat" and "hobbyist hat", more or less, but there's another axis entirely and that's the hat OP kind of looks down on, namely "chef's hat".
Because making code readable and maintainable also makes it suitable for teaching and onboarding juniors -- or any other teammate really.
As a guy with 23 years in the profession I started getting sick of myself being a hobbyist at times so I just do whatever is needed for a code to work BUT I don't keep it together with spit and 5-year old duct tape; I also give it some of the "chef's hat" treatment. How much of the "chef" touch do you give it determines the readability and maintainability. And whether you or your employer care about those, well, this is where actual real-world nuance and spectrum come into play.
3vidence
I'm not sure that distinction is completely fair.
Can't say I have nearly as much time under my belt but I've still seen the full continuum of straight well tested, documented code down to hacked together nonsense all within the same commerical code base.
I think to OP's point different code has different purposes commercial or not.
pdimitar
I am not sure what you find unfair, not like I am polarizing anything. I too introduced nuance via the "chef's hat" amount of effort one is willing to introduce.
I was also disagreeing with OP about their idea that polishing code is a waste time more often than not. That has been very far from the truth in my career. If you know what you are doing then "polishing" absolutely does bring value in the form of better velocity even as soon as one week in the future.
gorjusborg
I'd also add "Surgeon's hat":
Coding using only exacting, mechanical transformations that can be reasoned to be safe. Used when coding in poorly understood, mission-critical code bases. You do the bare minimum change to get the result, using verifiably safe operations.
owlbite
I think my normal approach to coding is "Scrappy" followed by "Surgeon" i.e. get the thing that works done in simple code style and then apply a series of transformation to obtain something that is significantly more complicated (and performant).
But maybe that's a peculiarity of the numerical algorithm performance space I live in, where debugging the numerics of a fully parallelized and vectorized algorithm with all sorts of performance bells and whistles, inline assembly and accelerator usage is much much more difficult than fixing the bug in simple scalar C code.
zoogeny
I too read de Bono's Thinking Hats book and found it worth considering. It reminds me of Nietzsche's Perspectivism [1]
I don't think having a fixed set of N perspectives is the correct approach. Rather, it is often a good idea to understand that there are many perspectives to view things from and to encourage productive perspectives when possible.
One frustrating thing I find with people I consider closed minded is an insistence on viewing every single issue from a single unchanging perspective.
user3939382
How about the hat where Prod is crashed, your heart is racing, and you throw caution to the wind because things can’t get any worse?
unregistereddev
Old hat here. Things certainly can get worse. Outages can turn into a loss of customer data. Attempts at restoring lost data can result in corrupting an unknown amount of customer data.
Throw caution to the wind and you can turn a 20-minute prod outage into a multi-day all hands disaster recovery. It's best to get your heart rate down, put on your captain's hat, and choose your next step carefully.
aqueueaqueue
Yeah that why my job has incident managers. When you get paged you only invesitgate. No touchy. When the team bands together, facts are shared and decisions are made carefully. Usually gonna be stuff like roll backs.
rqtwteye
I think old saying “slow is quick, quick is slow” applies here. Don’t do anything stupid because you are in panic mode.
pdimitar
Not sure I got you right here but this is exactly the situation where you should calm your breathing and make triple sure you don't make things worse -- because things can always get worse.
RestartKernel
The Junior hat, absolving you from any responsibility for prod's status.
steveBK123
macgruber hat
throwaway092323
I think this is a very useful framework for "choosing the right tool for the job".
For me personally, there isn't much difference between the Chef's Hat and the Teacher's Hat; the way I make code presentable is the same as how I make it self-documenting. I can tell I did a good job if the person reading my code feels smart.
mmcdermott
I see one key difference. Teaching code should be stripped down to only what is required for what is being taught. Everything else must go.
You can see this dichotomy in Scheme. Versions <= 5 were teaching first, everything else second. Versions 6+ tried to do both.
em-bee
what about the tightrope walker without a net for coding in production?
I like analogy's like this. Not in love with this specific one. It feels like OP thought of the first two hats and then tried to think up other hats, rather than have the nebulas idea of different ways of working and structured the analogy around it.
Analogies should "simplify" not complicate. If you're ever writing an analogy and think "How can I add more meat to this? You know, enough to make it worth sharing in a blog post?" you're on the wrong path.