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.
bellBivDinesh 34 days ago [-]
I got the same impression. Chefs hat was a reach.
disambiguation 35 days ago [-]
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 35 days ago [-]
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 35 days ago [-]
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 35 days ago [-]
FWIW I know a self-described scrappy who is definitely in the mcgyver category.
pdubroy 35 days ago [-]
Hey, author here! Yes, that's how I see it as well.
em-bee 33 days ago [-]
incidentally, yesterday i saw "scrappy" used in a job description for the first time. i was unfamiliar with that term before reading your post.
gorjusborg 35 days ago [-]
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 35 days ago [-]
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.
Blackarea 35 days ago [-]
Looks like different flavors of doing it "clean" and going "hacky". No real content here imo tbh - Hat analogy is fun though
pdimitar 35 days ago [-]
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.
motorest 35 days ago [-]
> I'd simplify this to "commercial hat" and "hobbyist hat", (...)
Your suggestion doesn't make sense, though. They mean nothing beyond disdaining code and convey nothing useful, whereas the article offers ways to classify different perspectives that are taken in highly professional settings.
To help you understand what's being discussed, highly successful companies made it thanks to their founders opting to put on their MacGyver hat to roll out a MVP instead of opting to put a Captain's hat.
pdimitar 35 days ago [-]
No, I disagree that it doesn't make sense. I was mostly saying that the OP's "hats" are generally just various random points along the spectrum of "how much would you invest in the code". They are kinda arbitrary which is fine. I was mostly trying to reformulate their points and disagree with one of them.
3vidence 35 days ago [-]
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 35 days ago [-]
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.
stevage 35 days ago [-]
That's actually a pretty useful way to think about it all.
Probably the different hands vary from person to person.
The "Chef's hat" reminds me of when you're writing code for a publicly distributed library, with inline documentation. Making it look nice does matter.
zoogeny 35 days ago [-]
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.
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.
eamonobr 32 days ago [-]
I let copilot add onto this framework and liked it:
Detective's Hat
The detective's hat is all about investigation and debugging. When you put on this hat, you're diving deep into the code to find the root cause of a bug or issue. This involves a lot of patience, attention to detail, and sometimes a bit of intuition. You might use tools like debuggers, log analyzers, and performance profilers to track down elusive problems.
Architect's Hat
The architect's hat is for designing systems and thinking about the big picture. With this hat on, you're considering how different components of the system interact, scalability, maintainability, and future growth. This involves creating diagrams, writing design documents, and making decisions that will impact the project long-term.
Gardener's Hat
The gardener's hat is about nurturing and maintaining code. This involves refactoring, cleaning up technical debt, and ensuring that the codebase remains healthy and manageable over time. It's about pruning unnecessary parts and fostering good practices so that the code can grow sustainably.
Scientist's Hat
The scientist's hat is for experimentation and research. When you wear this hat, you're exploring new technologies, trying out different algorithms, or conducting performance benchmarks. It's about being curious and methodical in your approach to discovering new solutions.
Librarian's Hat
The librarian's hat is focused on documentation and knowledge sharing. With this hat on, you're writing clear documentation, creating tutorials, and ensuring that information is easily accessible to others. This helps in building a knowledge base that can be referred to by team members or the wider community.
Diplomat's Hat
The diplomat's hat is for collaboration and communication. When you wear this hat, you're working with other teams, stakeholders, or clients to understand their needs and ensure that everyone is on the same page. It's about negotiating requirements, managing expectations, and fostering a collaborative environment.
KerryJones 34 days ago [-]
This comes across more as styles than hats. Hat's, typically, refer to a "role description". Put on my "eng manager hat", put on my "product manager hat", not doing the same thing differently.
I'm not sure "style" is the right word, but "hat" feels like the wrong one.
user3939382 35 days ago [-]
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 35 days ago [-]
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 35 days ago [-]
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 35 days ago [-]
I think old saying “slow is quick, quick is slow” applies here. Don’t do anything stupid because you are in panic mode.
KineticLensman 35 days ago [-]
Slow is smooth and smooth is fast
RestartKernel 35 days ago [-]
The Junior hat, absolving you from any responsibility for prod's status.
pdimitar 35 days ago [-]
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.
userbinator 35 days ago [-]
The red hat.
jmkni 34 days ago [-]
aka The Pirate Hat
steveBK123 35 days ago [-]
macgruber hat
throwaway092323 35 days ago [-]
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.
ludston 35 days ago [-]
The difference is that code designed to be easy to read is not the same as code written to aesthetic principles. The easiest example of this I can think of is the difference between code that follows formal whitespace rules and code that gives variables long names so that it is easier to understand them. Or the difference between ensuring that none of the declarations at the top of a file are redundant vs ordering all of the function definitions such that they tell some kind of narrative.
Code can be aesthetic and yet hard to understand or ugly but obvious.
mmcdermott 35 days ago [-]
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.
motorest 35 days ago [-]
What a wonderful and highly quotable link. I was looking for a good way to communicate these concepts and here it is. I think this ca be specially useful in PRs, when you have reviewers wearing a chef's hat reviewing spike code that was written with a scrappy or macgyver's hat.
35 days ago [-]
fullstackwife 35 days ago [-]
There is another hat: cannot resist pigeonholing other people
once you get someone pigeonholed, it becomes a self fulfilling prophecy
motorest 35 days ago [-]
> There is another hat: cannot resist pigeonholing other people
I think you failed to read the article. This article has nothing to do with pigeonholing people. This has nothing to do with people at all. This is about framing paths taken when working on solutions. Those who fail to understand this can even become toxic team members because they ignore contexts and start to nitpick with a chef's hat code that was clearly written as a proof of concept while wearing a macgyver's hat.
blah2244 34 days ago [-]
Everything comes back to social identity theory :) Especially programmers, who are already partially drawn to pattern matching.
I still enjoy articles like these, though -- think the author did a good job of describing the hats as "modes of working that you switch between" instead of "all-encompassing static personality traits that put you in a box".
em-bee 35 days ago [-]
what about the tightrope walker without a net for coding in production?
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.
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.
The former might be worth keeping around, the latter is firmly in the "build one to throw away" territory.
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.
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.
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.
Your suggestion doesn't make sense, though. They mean nothing beyond disdaining code and convey nothing useful, whereas the article offers ways to classify different perspectives that are taken in highly professional settings.
To help you understand what's being discussed, highly successful companies made it thanks to their founders opting to put on their MacGyver hat to roll out a MVP instead of opting to put a Captain's hat.
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.
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.
Probably the different hands vary from person to person.
The "Chef's hat" reminds me of when you're writing code for a publicly distributed library, with inline documentation. Making it look nice does matter.
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.
1. https://en.wikipedia.org/wiki/Perspectivism
Detective's Hat The detective's hat is all about investigation and debugging. When you put on this hat, you're diving deep into the code to find the root cause of a bug or issue. This involves a lot of patience, attention to detail, and sometimes a bit of intuition. You might use tools like debuggers, log analyzers, and performance profilers to track down elusive problems.
Architect's Hat The architect's hat is for designing systems and thinking about the big picture. With this hat on, you're considering how different components of the system interact, scalability, maintainability, and future growth. This involves creating diagrams, writing design documents, and making decisions that will impact the project long-term.
Gardener's Hat The gardener's hat is about nurturing and maintaining code. This involves refactoring, cleaning up technical debt, and ensuring that the codebase remains healthy and manageable over time. It's about pruning unnecessary parts and fostering good practices so that the code can grow sustainably.
Scientist's Hat The scientist's hat is for experimentation and research. When you wear this hat, you're exploring new technologies, trying out different algorithms, or conducting performance benchmarks. It's about being curious and methodical in your approach to discovering new solutions.
Librarian's Hat The librarian's hat is focused on documentation and knowledge sharing. With this hat on, you're writing clear documentation, creating tutorials, and ensuring that information is easily accessible to others. This helps in building a knowledge base that can be referred to by team members or the wider community.
Diplomat's Hat The diplomat's hat is for collaboration and communication. When you wear this hat, you're working with other teams, stakeholders, or clients to understand their needs and ensure that everyone is on the same page. It's about negotiating requirements, managing expectations, and fostering a collaborative environment.
I'm not sure "style" is the right word, but "hat" feels like the wrong one.
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.
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.
Code can be aesthetic and yet hard to understand or ugly but obvious.
You can see this dichotomy in Scheme. Versions <= 5 were teaching first, everything else second. Versions 6+ tried to do both.
once you get someone pigeonholed, it becomes a self fulfilling prophecy
I think you failed to read the article. This article has nothing to do with pigeonholing people. This has nothing to do with people at all. This is about framing paths taken when working on solutions. Those who fail to understand this can even become toxic team members because they ignore contexts and start to nitpick with a chef's hat code that was clearly written as a proof of concept while wearing a macgyver's hat.
I still enjoy articles like these, though -- think the author did a good job of describing the hats as "modes of working that you switch between" instead of "all-encompassing static personality traits that put you in a box".