[HN Gopher] Five Coding Hats
       ___________________________________________________________________
        
       Five Coding Hats
        
       Author : azhenley
       Score  : 60 points
       Date   : 2025-02-04 21:00 UTC (3 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.
        
       | 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.
        
       | 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.
        
         | 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.
        
       | 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.
        
       | 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?
        
       ___________________________________________________________________
       (page generated 2025-02-07 23:01 UTC)