[HN Gopher] Five coding hats
___________________________________________________________________
Five coding hats
Author : pdubroy
Score : 69 points
Date : 2025-02-06 14:44 UTC (2 days ago)
(HTM) web link (dubroy.com)
(TXT) w3m dump (dubroy.com)
| Blackarea wrote:
| Looks like different flavors of doing it "clean" and going
| "hacky". No real content here imo tbh - Hat analogy is fun though
| throwaway092323 wrote:
| 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 wrote:
| 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.
| ludston wrote:
| 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.
| NotAnOtter wrote:
| 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 wrote:
| I got the same impression. Chefs hat was a reach.
| user3939382 wrote:
| 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?
| steveBK123 wrote:
| macgruber hat
| rqtwteye wrote:
| I think old saying "slow is quick, quick is slow" applies here.
| Don't do anything stupid because you are in panic mode.
| KineticLensman wrote:
| Slow is smooth and smooth is fast
| RestartKernel wrote:
| The Junior hat, absolving you from any responsibility for
| prod's status.
| unregistereddev wrote:
| 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 wrote:
| 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.
| pdimitar wrote:
| 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 wrote:
| The red hat.
| jmkni wrote:
| aka The Pirate Hat
| disambiguation wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| FWIW I know a self-described scrappy who is definitely in
| the mcgyver category.
| pdubroy wrote:
| Hey, author here! Yes, that's how I see it as well.
| gorjusborg wrote:
| 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 wrote:
| 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 wrote:
| 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
| em-bee wrote:
| what about the tightrope walker without a net for coding in
| production?
| pdimitar wrote:
| 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 wrote:
| 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 wrote:
| 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.
| motorest wrote:
| > 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 wrote:
| 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.
| aqueueaqueue wrote:
| 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.
| stevage wrote:
| 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.
| fullstackwife wrote:
| There is another hat: cannot resist pigeonholing other people
|
| once you get someone pigeonholed, it becomes a self fulfilling
| prophecy
| motorest wrote:
| > 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 wrote:
| 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".
| motorest wrote:
| 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.
| KerryJones wrote:
| 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.
___________________________________________________________________
(page generated 2025-02-08 23:01 UTC)