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.

I got the same impression. Chefs hat was a reach.

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.

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.

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.

FWIW I know a self-described scrappy who is definitely in the mcgyver category.

Hey, author here! Yes, that's how I see it as well.

incidentally, yesterday i saw "scrappy" used in a job description for the first time. i was unfamiliar with that term before reading your post.

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.

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.

Looks like different flavors of doing it "clean" and going "hacky". No real content here imo tbh - Hat analogy is fun though

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.

> 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.

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.

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.

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.

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.

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.

1. https://en.wikipedia.org/wiki/Perspectivism

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.

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.

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.

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?

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.

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.

I think old saying “slow is quick, quick is slow” applies here. Don’t do anything stupid because you are in panic mode.

Slow is smooth and smooth is fast

The Junior hat, absolving you from any responsibility for prod's status.

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.

The red hat.

aka The Pirate Hat

macgruber hat

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.

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.

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.

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.

There is another hat: cannot resist pigeonholing other people

once you get someone pigeonholed, it becomes a self fulfilling prophecy

> 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.

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".

what about the tightrope walker without a net for coding in production?