5 ms·

More people need to read https://grugbrain.dev/ https://grugbrain.dev/

by sebmellen 3y ago

jeremyjh 3y ago
I really wish I'd read this 25 years ago, but probably I wouldn't have believed any of it.
- sebmellen 3y ago
  In some way, building absurdly complex systems and watching them fail is a rite of passage.
  - Arson9416 3y ago
    Fortunately (unfortunately?) most places are in some stage of that process, so it's easy enough to participate in.
- gedy 3y ago
  I don’t know, I’ve mostly followed this approach over my 20 year career, but it really depends on your surroundings, and honestly hasn’t led to great success. E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined. There’s also plenty of companies who don’t want engineers getting involved with decisions, and product and UX people work upfront and in isolation until you’re handed tiny Jira tickets with Figma mockups attached. Discussion at that point is considered “disruptive“. It honestly seems like this has gotten worse in the past 5 to 10 years.
  - sebmellen 3y ago
    > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer > sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice > but grug must to grug be true, and "no" is magic grug word. Hard say at first, especially if you nice grug and don't like disappoint people (many such grugs!) but easier over time even though shiney rock pile not as high as might otherwise be > is ok: how many shiney rock grug really need anyway?
  - Karrot_Kream 3y ago
    > E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined. I'm amazed at how non-obvious this seems to most engineers and how often this angst gets repeated in online tech communities. I mean, when I was in academia there was a tension between publishing impactful results or cozying up with the right professors into the right conferences vs outputting meaningful work (pressures into p-hacking or having big names author suspicious results is par for the course.) In industry it's the tension between product folks and engineers. Have you ever talked to high-level finance folks who deal with the tension of product folks just wanting to do things and finance folks who remind them how money works? It turns out that the hardest thing about getting things done with people is... dealing with people. I wish there was a way to remove this weird somewhat-ascetic blockage found in tech communities about this. Many of the more physical engineering occupations have to deal with this in the form of contractors and supervisors. Wait until you have to work on a government contract lol. When I mentor junior engineers with these feelings, I like to use an adage: "Where there are people there are politics." Look at pretty much any prominent FOSS project and you'll see tons of it (by dint of transparency) and those folks generally focus on the project and not a product!
    - no_wizard 3y ago
      I can see this in academia, because you're working on reputation as much as anything, if not more so, sorta prone to being like this in a way. Finance however, not once[0] have I either observed nor heard of someone working in finance being overruled by a product person. If finance says no go its no go, simple as that. People tend to listen to the money folks, even at a high-level. [0]: I work both in fintech and have lots of professional colleagues that work at other financial firms from big banks to all manner of investment firms and much in-between, as well as several generations of family who have all worked in finance on various levels. Honestly, its high level finance people trying to pressure others into getting things done faster when they want something done, not the other way around.
      - Karrot_Kream 3y ago
        > Finance however, not once[0] have I either observed nor heard of someone working in finance being overruled by a product person. If finance says no go its no go, simple as that. People tend to listen to the money folks, even at a high-level. Totally, but finance people want to see the company succeed too, and even if finance says it's a no-go, product people will still keep trying to push around them. I just mean that this tension exists between different stakeholders in every organization. If we knew ways out of this, we'd revolutionize government bureaucracies, vastly increase firm efficiencies, sort out FOSS issues, the world would be our oyster! But human coordination problems are really hard. The hardest problems out there really. That's my general point. Too much airtime is given to tech people who seem to not understand this. It's a bit like complaining that when I jump I fall down. I also can't imagine spending 20 years bemoaning this aspect of human nature.
  - no_wizard 3y ago
    It has, because embracing agile as it was laid out in 12 principles put too much power in these "technical" people by giving them a stake at the table, to anyone who doesn't work in an ENG first / ENG focused company. If you look at how "Agile" is implemented in most organizations - even in technology companies! - there's alot of barrier process put up to sideline / minimize engineering input by focusing on stakeholders where stakeholder is defined by everyone telling engineering what to do as opposed to engineering being seen as a valid and reasonable stakeholder too. I think its because in part there is a linear pipeline that the non technical business side sees as how things go: you plan X, it gets designed by Y, and then "manufactured" by engineers, if you will. Engineers - good ones, in my estimation - want more stake in each step, both in planning and design, because often its engineers that work on the system the closest (you'd be shocked how many designers don't use their own products on a daily basis, same goes for alot of business oriented folks) and this is not "the way the world works". Thats my thesis anyway
  - esafak 3y ago
    I wonder how you could open up product development to the whole company (including engineers) without the product organization getting overwhelmed?
    - gedy 3y ago
      "Real" agile is meant to do just this, but it's rare without falling into cargo culting.
      - esafak 3y ago
        So let others add ideas to the backlog and the product owners triage? I would be worried about ideas getting drowned, leading to a disincentive in participation. I would probably add a layer of voting or something to allow good ideas to surface.
        gedy 3y ago
        I meant that product still writes the high level user stories, but eng figures out the solution along side UX, product, etc. Not handed broken down tasks and mockups first.
TurkishPoptart 3y ago
I like this but I don't understand one part under "Saying OK" *sometimes probably best just not tell project manager and do it 80/20 way.* Does 80/20 in this context mean that we'll implement 80% of what is asked for an leave out the remaining complex parts?
- sebmellen 3y ago
  Kind of, and it usually works. Even as a founder you can trick yourself into doing things that way. I've found that 20/80, Pareto style, is even better. 20% of the features can achieve 80% of the sales, and you'll be a lot happier if you're not constantly chasing the long tail.
- bcrosby95 3y ago
  80% of the features/details for 20% of the code/complexity. Even minor tweaks can have an outsized effect on the final code. A large part of my job is doing this in such a way that satisfies the stakeholders.
- internet101010 3y ago
  More or less and it usually gets the job done. The last 20% can be a real time suck if it isn't managed properly. What you don't want is for the last 20% to occupy 80% of the time.
- jacquesm 3y ago
  You do 80% of the functionality with 20% of the required code and pretend that this is what the project manager asked for. Likely they'll never notice the missing bits which may have seemed like a good idea at the time .If they insist you do 80% of what remains with another 20% of the code. But with some luck your project managers' butterfly mind will have flitted on to greener pastures and everybody is happy. No need for Grug to reach for his club (while remaining calm).
airstrike 3y ago
LMAO that's hilarious, thanks for sharing > best weapon against complexity spirit demon is magic word: "no" > "no, grug not build that feature" > "no, grug not build that abstraction" > "no, grug not put water on body every day or drink less black think juice you stop repeat ask now" > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer
- moffkalast 3y ago
  > sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice Perfection
oooyay 3y ago
This is some really beautiful prose
jacquesm 3y ago
It's priceless. I figure most programmers at some point during their career will be able to relate to having a Grug Brain. complexity very, very bad! This site has more knowledge condensed in one page than a stack of randomly assorted books on software development do.

More people need to read https://grugbrain.dev/ https://grugbrain.dev/

jeremyjh 3y ago

I really wish I'd read this 25 years ago, but probably I wouldn't have believed any of it.

sebmellen 3y ago
In some way, building absurdly complex systems and watching them fail is a rite of passage.
- Arson9416 3y ago
  Fortunately (unfortunately?) most places are in some stage of that process, so it's easy enough to participate in.
gedy 3y ago
I don’t know, I’ve mostly followed this approach over my 20 year career, but it really depends on your surroundings, and honestly hasn’t led to great success. E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined. There’s also plenty of companies who don’t want engineers getting involved with decisions, and product and UX people work upfront and in isolation until you’re handed tiny Jira tickets with Figma mockups attached. Discussion at that point is considered “disruptive“. It honestly seems like this has gotten worse in the past 5 to 10 years.
- sebmellen 3y ago
  > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer > sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice > but grug must to grug be true, and "no" is magic grug word. Hard say at first, especially if you nice grug and don't like disappoint people (many such grugs!) but easier over time even though shiney rock pile not as high as might otherwise be > is ok: how many shiney rock grug really need anyway?
- Karrot_Kream 3y ago
  > E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined. I'm amazed at how non-obvious this seems to most engineers and how often this angst gets repeated in online tech communities. I mean, when I was in academia there was a tension between publishing impactful results or cozying up with the right professors into the right conferences vs outputting meaningful work (pressures into p-hacking or having big names author suspicious results is par for the course.) In industry it's the tension between product folks and engineers. Have you ever talked to high-level finance folks who deal with the tension of product folks just wanting to do things and finance folks who remind them how money works? It turns out that the hardest thing about getting things done with people is... dealing with people. I wish there was a way to remove this weird somewhat-ascetic blockage found in tech communities about this. Many of the more physical engineering occupations have to deal with this in the form of contractors and supervisors. Wait until you have to work on a government contract lol. When I mentor junior engineers with these feelings, I like to use an adage: "Where there are people there are politics." Look at pretty much any prominent FOSS project and you'll see tons of it (by dint of transparency) and those folks generally focus on the project and not a product!
  - no_wizard 3y ago
    I can see this in academia, because you're working on reputation as much as anything, if not more so, sorta prone to being like this in a way. Finance however, not once[0] have I either observed nor heard of someone working in finance being overruled by a product person. If finance says no go its no go, simple as that. People tend to listen to the money folks, even at a high-level. [0]: I work both in fintech and have lots of professional colleagues that work at other financial firms from big banks to all manner of investment firms and much in-between, as well as several generations of family who have all worked in finance on various levels. Honestly, its high level finance people trying to pressure others into getting things done faster when they want something done, not the other way around.
    - Karrot_Kream 3y ago
      > Finance however, not once[0] have I either observed nor heard of someone working in finance being overruled by a product person. If finance says no go its no go, simple as that. People tend to listen to the money folks, even at a high-level. Totally, but finance people want to see the company succeed too, and even if finance says it's a no-go, product people will still keep trying to push around them. I just mean that this tension exists between different stakeholders in every organization. If we knew ways out of this, we'd revolutionize government bureaucracies, vastly increase firm efficiencies, sort out FOSS issues, the world would be our oyster! But human coordination problems are really hard. The hardest problems out there really. That's my general point. Too much airtime is given to tech people who seem to not understand this. It's a bit like complaining that when I jump I fall down. I also can't imagine spending 20 years bemoaning this aspect of human nature.
- no_wizard 3y ago
  It has, because embracing agile as it was laid out in 12 principles put too much power in these "technical" people by giving them a stake at the table, to anyone who doesn't work in an ENG first / ENG focused company. If you look at how "Agile" is implemented in most organizations - even in technology companies! - there's alot of barrier process put up to sideline / minimize engineering input by focusing on stakeholders where stakeholder is defined by everyone telling engineering what to do as opposed to engineering being seen as a valid and reasonable stakeholder too. I think its because in part there is a linear pipeline that the non technical business side sees as how things go: you plan X, it gets designed by Y, and then "manufactured" by engineers, if you will. Engineers - good ones, in my estimation - want more stake in each step, both in planning and design, because often its engineers that work on the system the closest (you'd be shocked how many designers don't use their own products on a daily basis, same goes for alot of business oriented folks) and this is not "the way the world works". Thats my thesis anyway
- esafak 3y ago
  I wonder how you could open up product development to the whole company (including engineers) without the product organization getting overwhelmed?
  - gedy 3y ago
    "Real" agile is meant to do just this, but it's rare without falling into cargo culting.
    - esafak 3y ago
      So let others add ideas to the backlog and the product owners triage? I would be worried about ideas getting drowned, leading to a disincentive in participation. I would probably add a layer of voting or something to allow good ideas to surface.
      - gedy 3y ago
        I meant that product still writes the high level user stories, but eng figures out the solution along side UX, product, etc. Not handed broken down tasks and mockups first.

TurkishPoptart 3y ago

I like this but I don't understand one part under "Saying OK" *sometimes probably best just not tell project manager and do it 80/20 way.* Does 80/20 in this context mean that we'll implement 80% of what is asked for an leave out the remaining complex parts?

sebmellen 3y ago
Kind of, and it usually works. Even as a founder you can trick yourself into doing things that way. I've found that 20/80, Pareto style, is even better. 20% of the features can achieve 80% of the sales, and you'll be a lot happier if you're not constantly chasing the long tail.
bcrosby95 3y ago
80% of the features/details for 20% of the code/complexity. Even minor tweaks can have an outsized effect on the final code. A large part of my job is doing this in such a way that satisfies the stakeholders.
internet101010 3y ago
More or less and it usually gets the job done. The last 20% can be a real time suck if it isn't managed properly. What you don't want is for the last 20% to occupy 80% of the time.
jacquesm 3y ago
You do 80% of the functionality with 20% of the required code and pretend that this is what the project manager asked for. Likely they'll never notice the missing bits which may have seemed like a good idea at the time .If they insist you do 80% of what remains with another 20% of the code. But with some luck your project managers' butterfly mind will have flitted on to greener pastures and everybody is happy. No need for Grug to reach for his club (while remaining calm).

airstrike 3y ago

LMAO that's hilarious, thanks for sharing > best weapon against complexity spirit demon is magic word: "no" > "no, grug not build that feature" > "no, grug not build that abstraction" > "no, grug not put water on body every day or drink less black think juice you stop repeat ask now" > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer

moffkalast 3y ago
> sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice Perfection

oooyay 3y ago

This is some really beautiful prose

jacquesm 3y ago

It's priceless. I figure most programmers at some point during their career will be able to relate to having a Grug Brain. complexity very, very bad! This site has more knowledge condensed in one page than a stack of randomly assorted books on software development do.