8 ms·

I find the article amusing but it feels like it is missing a clear closing statement about why this matters. My take is that "dumb and get things done" is dang

I find the article amusing but it feels like it is missing a clear closing statement about why this matters. My take is that "dumb and get things done" is dangerous because they can do harm quickly, unlike dumb and lazy which at least doesn't get on the way. These are the ones that pump thousands of lines of spaghetti code, copy pasting all over the place and creating a unmaintainable big ball of mud. They are the ones that implement the first solution that comes to mind before considering alternatives. Are the ones that never refactor or tidy their code and simply add another if statement. The irony is that in certain companies these people might be seen as heroes. After all, isn't it more impressive to produce hundreds of complicated lines of code in half the time rather than a few dozen of clean and maintainable lines of code in twice the time.

MichaelRo 3y ago
Unfortunately it seems to me like the majority of programmers I've come in contact with belong to the "dumb and get things done" group. The algorithm is: 1) Get hired at a new place. 2) Vomit a lot of code adopting the latest and greatest fad without any prior experience in it (like "template metaprogramming") and with no knowledge whatsoever of the domain in cause (ex: finance, map navigation etc). None of these are an impediment in immediately starting to produce code in great quantities. 3) Keep on #2 until some resemblance of responsability appears, like need to actually deliver that project. Or until the unintended and accidental complexity of said code exceeds their limited mental capacity. Then apply for a new job somewhere else, padding their resume with "experience in fad X" and quit, leaving the burden of making some use (and sense) of their abomination to another poor soul teleported there at the last moment to "help".
- whstl 3y ago
  Couldn't agree more. In almost 20 years I've learned that, at least to me, the most challenging group to manage are mid-level developers. Juniors don't have a lot of experience with complex code, so they just make simple code which I can understand with a glance. Mid-level developers are often into trying new stuff and fall in love with complex solutions, so the code isn't really easy to understand, but damn if it isn't interesting, full of crazy new libraries, patterns and ideas. Seniors have a lot of experience with complex code, so they just make simple code which I can understand with a glance. Similar: https://pages.cpsc.ucalgary.ca/~robin/class/449/Evolution.htm https://pages.cpsc.ucalgary.ca/~robin/class/449/Evolution.ht...
  - JohnFen 3y ago
    Yes, there's a name for this, but I forget what it is. Being a beginner or a true expert are relatively safe. Beginners are aware of the limits of their knowledge/skills. Likewise, true experts are aware of the limits of their knowledge/skills. In between the two, though, people tend to think they understand more than they actually do. And, of course, being a beginner, intermediate, or expert is topic-specific. You can be an expert in one things and a beginner in another at the same time.
    - Benjammer 3y ago
      It's along the same lines as Fred Brooks' "Second system effect," although not quite the same.
    - astura 3y ago
      >Yes, there's a name for this, but I forget what it is. Resume Driven Development.
    - hhh 3y ago
      Bell curve moment
    - 6D794163636F756 3y ago
      This sounds like the Dunning Kruger effect
      - JohnFen 3y ago
        Dunning-Kruger is certainly a closely related effect, yes, but wasn't what I was thinking of.
    - lcnPylGDnU4H9OF 3y ago
      > name for this Sounds like "Advanced Beginner" https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th... "Expert Beginner" is the one who barely knows shit but convinces themselves they know everything and "Advanced Beginner" is the one who thinks they know just slightly more than they really do until their compiler gives them an error they didn't expect.
- throwawaysleep 3y ago
  All comes down to incentives. My leetcode has done far more for my salary than work quality. If there is no reward for work that works long term, I will not do work that works long term or bother to learn how it is done.
- 2devnull 3y ago
  I suspect this will get a lot of upvotes but the important bit in context to keep in mind is that the industry has optimized for these people. It’s not really their fault if they’re just playing the game. Maybe companies shouldn’t hire people who job hop every three years?
  - ChrisMarshallNY 3y ago
    > job hop every three years I was told by a manager at a startup we worked with, that he expects his employees to be there about 18 months, and described that as “average” for Silicon Valley. I can’t even imagine working with code, written by someone like that.
- Aerbil313 3y ago
  Haha, just today I saw comments seriously praising this exact approach on HN.
- brigadier132 3y ago
  They aren't dumb, companies reward this behavior. Go to company A, shit out some code that barely works (but it works) and is written without any thought for future changes to the product, get promoted, then leave to a different company when you have to deal with the fallout of what you created but now you join company b at a higher level.
- __seka__ 3y ago
  Dealing with lack of experience and ego can be very challenging for others. I wonder what do people gain from calling people dumb or treating them as dumb?
- MilStdJunkie 3y ago
  Yeah. Management metrics (at least in my experience) often don't catch the "dumb", but they do catch the "get things done", so it creates a disincentive to do things smart. Under those conditions Dumb-Energetic will put your project in a hole that no amount of Smart-Energetic can dig you out from; the sad but correct diagnosis is often to just shoot the problem and cover over the hole so you can build on it. But first, fix the incentives and change the metrics that govern decisions, or else it's going to happen all over again - THIS is the chokepoint, because so many leadership staff are (emotionally) invested in the current metric.
- jack_h 3y ago
  I've never seen a "dumb" programmer vomit out TMP code. Generally speaking what I encounter are programmers who don't know or want to know anything beyond basic C, even when programming C++. I consider this an issue with the C++ language though. I think the ultimate issue is how businesses optimize software development. The "dumb" programmers do as the business expects because they just want a salary so they can enjoy their life outside of work. For instance at work we distribute our packages by downloading the artifacts off of our build server, uploading them to Sharepoint in the appropriate folder and re-arranging any previous artifact versions if needed. My team maintains 30-40 products, so we have a lot of artifacts. Other groups then manually download all of these artifacts and do whatever they need to do. This is error prone and very manual. I'm not sure if package managers can be considered the latest and greatest fad at this point, but that is my boring solution. I've had a ton of pushback on this though because my solution is apparently too complex. Instead management is pushing for every team to hack some scripts together to automate what the team is currently doing manually. It sure seems like we're reinventing a package manager to me, but the business is heavily pushing a code-first approach. I've also been in a situation where a junior dev picked up a ticket and completed it in a completely different way from what was specified; it was not a maintainable solution. I pushed back but I was overridden at the director level because the work was already done, so let's just merge it in; the problem has expanded and it is a constant pain point now. In fact I have been told that it's concerning my team does code reviews with a PR workflow. The expectation is that almost all changes should be merged into master directly and very few need to be reviewed before merge. The code my team maintains is an unmaintainable ball of mud and the answer from the business has been more Agile, more code, and more output. Companies incentivize this short-term thinking, promote people who do what is expected, and the cycle continues.
  - jerf 3y ago
    'I've never seen a "dumb" programmer vomit out TMP code.' There's a lot of accidental equivocation that can occur in these sorts of conversations since intelligence can be measured along a lot of different axes. Template metaprogramming is generally something that does require a certain raw intelligence to get into and use extensively, but at the same time, putting it into a system that doesn't need it can be a very dumb decision. Perhaps you'd prefer the term "unwise" over "dumb" in this case; adding "wisdom" in to the discussion at least helps, but even so, there's more than just those two axes as well.
- angarg12 3y ago
  Funny that you mention this, because it reminds me to a developer archetype that I noticed a few times, that I call "80/20 optimizer" for lack of a better name. I was thinking about writing an article about this. I call them 80/20 optimizers because they seem fixated with getting the most stuff done with the least effort. Why do something to 100% in 100% the time when you can get 5 things 80% done? That's a good principle in theory. Delivering value incrementally and being smart about your efforts is positive, particularly in small and fast paced companies. However these people take it to the extreme. These are the developers that will crank out solutions fast that seem to work, but things fall apart once they leave. Once you open the lid, you find a system that barely qualifies as a PoC, with messy code, no documentation, manually set up infrastructure and config, etc. As you mention the key here is that the time it takes the team to find this has to be longer than their tenure in the project to make this work. Specifically the people I'm talking about are deliberate about this. Managers love them because "they get shit done", so they usually get promoted or moved to another initiative, so it is someone else's problem to deal with their mess. If they are particularly devious, they might use this as a double whammy: the poor souls that have to deal with their crap will look even worse compared with them (why does Mary need 1 week to implement a simple feature when Bill wrote the entire thing in 2 weeks?). These people move laterally and up in an organization, and if the chicken ever come home to roost, they will simply change companies. Remember, you don't need to fool everyone all the time, you just need to fool the right people long enough.
  - Mawr 3y ago
    This is a tough one. Efficiency is what tends to be the ultimate goal of any venture, and getting 5 things 80% done instead of 1 thing 100% done is incredibly efficient. Moreover, no matter what course of action you choose, it will have downsides, you only get to choose which ones. I'm not so sure that the downsides of this hyper-efficient approach are worse than those of the alternatives. There's a bit of human bias at work here, you focus on the downsides in front of you because those are the ones you can see. However, you ignore the downsides other approaches would have because you can't see them. That doesn't mean they don't exist. Another aspect, it's considerably easier to find and solve problems with an implemented solution than an unimplemented one. That's what this hyper-optimized approach is likely great at - paving the way for other engineers. In the end, I think you need a few such 80/20 engineers on your team, but they must be coupled with a few "completionist" types as well, who'll come in afterwards to bring everything up to standard.
- chaostheory 3y ago
  > 2) Vomit a lot of code adopting the latest and greatest fad without any prior experience in it (like "template metaprogramming") and with no knowledge whatsoever of the domain in cause > 3) Keep on #2 until some resemblance of responsability appears, like need to actually deliver that project. Or until the unintended and accidental complexity of said code exceeds their limited mental capacity. Then apply for a new job somewhere else, padding their resume with "experience in fad X" This is called resume / CV driven development. It’s popular because it’s rewarded well. If you’re good with maintenance instead of creating new projects, you might as well be invisible; especially to the non-technical. Google’s reward mechanism is a notorious example, though tbf you’ll see a lesser form of this in nearly every organization Edit: if we’re being fair, even if developers were competent in using x bleeding edge tech, it’s still a negative when they leave. For the longest time, yahoo engineers didn’t know what to do with pg’s store front lisp code
- rmason 3y ago
  I remember being told the story of the two programmers. One was fast, a real code generating machine. Course he shipped with errors, lots of errors. He didn't document any of this code. But the bosses just loved the guy. Then there was the guy who was slow, but thorough. Part of that extra time was writing tests and doing lots of documentation. When he shipped there were never any errors, just send it to production. So when times got hard naturally it was the slow programmer who the bosses laid off.
goeiedaggoeie 3y ago
accidental complexity is a long term productivity killer.
BlargMcLarg 3y ago
Because the latter barely ever happens in 'twice the time' right from the start. Even assuming the flat 2x, that's a lot for a project that takes 6 months the 'dumb way' for any company nowadays. The pay-off for 'smart way', is unlikely to be there before 2 years from project start. You're lucky to have a company look ahead more than 2 quarters, let alone 2 years. That's not to mention all the other problems as commenters on a different article about speed pointed out yesterday. Dumb way at least gives you something. 'Smart' way goes in and makes a hundred assumptions only to realize they forgot something a prototype would've pointed out to them. Not the dev's fault management doesn't listen to "this is a throwaway prototype".
- toss1 3y ago
  This is why you should apply the Dumb&Fast approach for a first ~MVP version, plan to throw it away, then apply the smart & careful approach for the more durable versions. The first version should get out there quickly and validate, adjust, and/or destroy your assumptions about your customers, systems, usage & load patterns, etc., then that deeper knowledge and more careful approach goes into the next 'real' version. Prevents premature scaling & optimization, and you never have to pay the tech debt from the 1st version. Source: been there, done that, works great.
- angarg12 3y ago
  I guess using ambiguous terms like "smart" and "dumb" is the downfall of this article. You could replace them with "good developer" and "bad developer" for whichever definition of good and bad you choose (which will vary for person). From your description, I don't consider smart to do some big upfront design and release a system in 2 years; in fact I'd consider that very dumb instead. In that context dumb would be to go ahead with the first solution that comes to your mind rather than looking at 2-3 solutions, compare them, possibly PoC and measure them (if possible) and then make an informed choice including other's input (depending on the scale of the project).
hirundo 3y ago
I'm never the hero when my code is designed and implemented properly. It just gets deployed and used and maybe a new checked box appears on a marketing page. The reaction I get is "here's your next project." But if I fuck it up and it brings down the world and half the clients are filing tickets and calling the management, and they send me the bat signal and I come in and put a band-aid on my own bad judgement, which takes a half hour, I'm the hero.
throwawaysleep 3y ago
All comes down to incentives. My leetcode has done far more for my salary than work quality. If there is no reward for work that works long term, I will not do work that works long term or bother to learn how it is done.
base698 3y ago
Definitely worse than the smart and gets things done 10x dev who wraps every method call in a separate service connected by queues.
- seadan83 3y ago
  Code is fast to write, slow to modify. That 10x dev is just in the initial write phase; anyone coming in later to modify that code will appear to be slower.
- intelVISA 3y ago
  That's a -10x dev pattern..!
isk517 3y ago
The article seems to forget that 'If it's stupid but it works then it isn't stupid' is a common saying. 'Dumb and energetic' is what I usually associate with the various stories my firefighter uncle or paramedic friend tell me about.
intelVISA 3y ago
High-energy, dumb and get things done, juniors are a curse. Complete 3 tickets a day (WOW!) but make about 5-10 bugs as a result. Always fun later reducing a 400+ LOC ball of mud to under 100 lines :)
JoeAltmaier 3y ago
The most applauded programmers at my first job were the communications protocol guys. They'd ship broken code then go to the customer site and patch it. Heros! The rest of us shipped good, tested code and didn't need to do that. Never got applauded at executive meetings; never got special rewards from customer reps, just doing our job.
- hinkley 3y ago
  One of our platform engineers figured out one day that the Ops guys and the management were in a Stockholm Syndrome toxic loop. They were always in war rooms together, meanwhile our stuff, broken as it still is, mostly works, so we often weren’t needed. Those managers are gone, but the Ops guys still think they're cocks of the walk and it’s never been less true. I’ve had two bosses give an all engineering staff speech that could be summarized as, “we are too big to tolerate heroes now”. But is should have been 6, not 2.
- johnvaluk 3y ago
  I call them firemen who put out their own fires. Also annoying are the managers who suddenly champion mission continuity without wondering why operations have been free of disruption for years...
- cratermoon 3y ago
  > they'd ship broken code then go to the customer site and patch it From management's perspective, maybe it looks like the customers love them so much they keep asking for them to personally come and work with them.
hinkley 3y ago
Kurt von Hammerstein-Equord, German general I divide my officers into four classes as follows: the clever, the industrious, the lazy, and the stupid. Each officer always possesses two of these qualities. Those who are clever and industrious I appoint to the General Staff. Use can under certain circumstances be made of those who are stupid and lazy. The man who is clever and lazy qualifies for the highest leadership posts. He has the requisite and the mental clarity for difficult decisions. But whoever is stupid and industrious must be got rid of, for he is too dangerous.
- ojbyrne 3y ago
  Just googling around a bit, I suspect this is the real source of the quote, not Napoleon.
  - hinkley 3y ago
    I've never heard Napoleon, but I'm pretty sure that it's usually attributed to a different German military officer. Quote Investigation is not definitive in who said it. But this seems to be the oldest recorded version?
- deleted 3y ago
  [deleted]
0tt049 3y ago
The article is indeed amusing, but it needs a closing statement as much as Schindler's List needed that coda. However, anyone who wishes to delve deeper into the dangers of stupidity should read 'Eichmann in Jerusalem' by Hannah Arendt.
Spooky23 3y ago
The apocryphal Prussian General 2x2 captures the problem. “General Freiherr von Hammerstein-Equord, the present chief of the German Army, has a method of selecting officers which strikes us as being highly original and peculiarly un-Prussian. According to Exchange, a Berlin newspaper has printed the following as his answer to a query as to how he judged his officers: “I divide my officers into four classes as follows: The clever, the industrious, the lazy, and the stupid. Each officer always possesses two of these qualities. Those who are clever and industrious I appoint to the General Staff. Use can under certain circumstances be made of those who are stupid and lazy. The man who is clever and lazy qualifies for the highest leadership posts. He has the requisite nerves and the mental clarity for difficult decisions. But whoever is stupid and industrious must be got rid of, for he is too dangerous.”
- pfdietz 3y ago
  Clever and Lazy is a good description of Admiral Raymond Spruance. He was famously lazy, delegating any task he didn't have to do himself, but was perhaps the best US seagoing commander of the Second World War.
peteradio 3y ago
Dumb and gets things done at least surfaces the true requirements. Yea its annoying as f to fix these guys mistakes or horrendous antipatterns but I praise them for going first and getting that precious feedback. This only works when we aren't testing on customers but instead have good internal testing.

MichaelRo 3y ago

Unfortunately it seems to me like the majority of programmers I've come in contact with belong to the "dumb and get things done" group. The algorithm is: 1) Get hired at a new place. 2) Vomit a lot of code adopting the latest and greatest fad without any prior experience in it (like "template metaprogramming") and with no knowledge whatsoever of the domain in cause (ex: finance, map navigation etc). None of these are an impediment in immediately starting to produce code in great quantities. 3) Keep on #2 until some resemblance of responsability appears, like need to actually deliver that project. Or until the unintended and accidental complexity of said code exceeds their limited mental capacity. Then apply for a new job somewhere else, padding their resume with "experience in fad X" and quit, leaving the burden of making some use (and sense) of their abomination to another poor soul teleported there at the last moment to "help".

whstl 3y ago
Couldn't agree more. In almost 20 years I've learned that, at least to me, the most challenging group to manage are mid-level developers. Juniors don't have a lot of experience with complex code, so they just make simple code which I can understand with a glance. Mid-level developers are often into trying new stuff and fall in love with complex solutions, so the code isn't really easy to understand, but damn if it isn't interesting, full of crazy new libraries, patterns and ideas. Seniors have a lot of experience with complex code, so they just make simple code which I can understand with a glance. Similar: https://pages.cpsc.ucalgary.ca/~robin/class/449/Evolution.htm https://pages.cpsc.ucalgary.ca/~robin/class/449/Evolution.ht...
- JohnFen 3y ago
  Yes, there's a name for this, but I forget what it is. Being a beginner or a true expert are relatively safe. Beginners are aware of the limits of their knowledge/skills. Likewise, true experts are aware of the limits of their knowledge/skills. In between the two, though, people tend to think they understand more than they actually do. And, of course, being a beginner, intermediate, or expert is topic-specific. You can be an expert in one things and a beginner in another at the same time.
  - Benjammer 3y ago
    It's along the same lines as Fred Brooks' "Second system effect," although not quite the same.
  - astura 3y ago
    >Yes, there's a name for this, but I forget what it is. Resume Driven Development.
  - hhh 3y ago
    Bell curve moment
  - 6D794163636F756 3y ago
    This sounds like the Dunning Kruger effect
    - JohnFen 3y ago
      Dunning-Kruger is certainly a closely related effect, yes, but wasn't what I was thinking of.
  - lcnPylGDnU4H9OF 3y ago
    > name for this Sounds like "Advanced Beginner" https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th... "Expert Beginner" is the one who barely knows shit but convinces themselves they know everything and "Advanced Beginner" is the one who thinks they know just slightly more than they really do until their compiler gives them an error they didn't expect.
throwawaysleep 3y ago
All comes down to incentives. My leetcode has done far more for my salary than work quality. If there is no reward for work that works long term, I will not do work that works long term or bother to learn how it is done.
2devnull 3y ago
I suspect this will get a lot of upvotes but the important bit in context to keep in mind is that the industry has optimized for these people. It’s not really their fault if they’re just playing the game. Maybe companies shouldn’t hire people who job hop every three years?
- ChrisMarshallNY 3y ago
  > job hop every three years I was told by a manager at a startup we worked with, that he expects his employees to be there about 18 months, and described that as “average” for Silicon Valley. I can’t even imagine working with code, written by someone like that.
Aerbil313 3y ago
Haha, just today I saw comments seriously praising this exact approach on HN.
brigadier132 3y ago
They aren't dumb, companies reward this behavior. Go to company A, shit out some code that barely works (but it works) and is written without any thought for future changes to the product, get promoted, then leave to a different company when you have to deal with the fallout of what you created but now you join company b at a higher level.
__seka__ 3y ago
Dealing with lack of experience and ego can be very challenging for others. I wonder what do people gain from calling people dumb or treating them as dumb?
MilStdJunkie 3y ago
Yeah. Management metrics (at least in my experience) often don't catch the "dumb", but they do catch the "get things done", so it creates a disincentive to do things smart. Under those conditions Dumb-Energetic will put your project in a hole that no amount of Smart-Energetic can dig you out from; the sad but correct diagnosis is often to just shoot the problem and cover over the hole so you can build on it. But first, fix the incentives and change the metrics that govern decisions, or else it's going to happen all over again - THIS is the chokepoint, because so many leadership staff are (emotionally) invested in the current metric.
jack_h 3y ago
I've never seen a "dumb" programmer vomit out TMP code. Generally speaking what I encounter are programmers who don't know or want to know anything beyond basic C, even when programming C++. I consider this an issue with the C++ language though. I think the ultimate issue is how businesses optimize software development. The "dumb" programmers do as the business expects because they just want a salary so they can enjoy their life outside of work. For instance at work we distribute our packages by downloading the artifacts off of our build server, uploading them to Sharepoint in the appropriate folder and re-arranging any previous artifact versions if needed. My team maintains 30-40 products, so we have a lot of artifacts. Other groups then manually download all of these artifacts and do whatever they need to do. This is error prone and very manual. I'm not sure if package managers can be considered the latest and greatest fad at this point, but that is my boring solution. I've had a ton of pushback on this though because my solution is apparently too complex. Instead management is pushing for every team to hack some scripts together to automate what the team is currently doing manually. It sure seems like we're reinventing a package manager to me, but the business is heavily pushing a code-first approach. I've also been in a situation where a junior dev picked up a ticket and completed it in a completely different way from what was specified; it was not a maintainable solution. I pushed back but I was overridden at the director level because the work was already done, so let's just merge it in; the problem has expanded and it is a constant pain point now. In fact I have been told that it's concerning my team does code reviews with a PR workflow. The expectation is that almost all changes should be merged into master directly and very few need to be reviewed before merge. The code my team maintains is an unmaintainable ball of mud and the answer from the business has been more Agile, more code, and more output. Companies incentivize this short-term thinking, promote people who do what is expected, and the cycle continues.
- jerf 3y ago
  'I've never seen a "dumb" programmer vomit out TMP code.' There's a lot of accidental equivocation that can occur in these sorts of conversations since intelligence can be measured along a lot of different axes. Template metaprogramming is generally something that does require a certain raw intelligence to get into and use extensively, but at the same time, putting it into a system that doesn't need it can be a very dumb decision. Perhaps you'd prefer the term "unwise" over "dumb" in this case; adding "wisdom" in to the discussion at least helps, but even so, there's more than just those two axes as well.
angarg12 3y ago
Funny that you mention this, because it reminds me to a developer archetype that I noticed a few times, that I call "80/20 optimizer" for lack of a better name. I was thinking about writing an article about this. I call them 80/20 optimizers because they seem fixated with getting the most stuff done with the least effort. Why do something to 100% in 100% the time when you can get 5 things 80% done? That's a good principle in theory. Delivering value incrementally and being smart about your efforts is positive, particularly in small and fast paced companies. However these people take it to the extreme. These are the developers that will crank out solutions fast that seem to work, but things fall apart once they leave. Once you open the lid, you find a system that barely qualifies as a PoC, with messy code, no documentation, manually set up infrastructure and config, etc. As you mention the key here is that the time it takes the team to find this has to be longer than their tenure in the project to make this work. Specifically the people I'm talking about are deliberate about this. Managers love them because "they get shit done", so they usually get promoted or moved to another initiative, so it is someone else's problem to deal with their mess. If they are particularly devious, they might use this as a double whammy: the poor souls that have to deal with their crap will look even worse compared with them (why does Mary need 1 week to implement a simple feature when Bill wrote the entire thing in 2 weeks?). These people move laterally and up in an organization, and if the chicken ever come home to roost, they will simply change companies. Remember, you don't need to fool everyone all the time, you just need to fool the right people long enough.
- Mawr 3y ago
  This is a tough one. Efficiency is what tends to be the ultimate goal of any venture, and getting 5 things 80% done instead of 1 thing 100% done is incredibly efficient. Moreover, no matter what course of action you choose, it will have downsides, you only get to choose which ones. I'm not so sure that the downsides of this hyper-efficient approach are worse than those of the alternatives. There's a bit of human bias at work here, you focus on the downsides in front of you because those are the ones you can see. However, you ignore the downsides other approaches would have because you can't see them. That doesn't mean they don't exist. Another aspect, it's considerably easier to find and solve problems with an implemented solution than an unimplemented one. That's what this hyper-optimized approach is likely great at - paving the way for other engineers. In the end, I think you need a few such 80/20 engineers on your team, but they must be coupled with a few "completionist" types as well, who'll come in afterwards to bring everything up to standard.
chaostheory 3y ago
> 2) Vomit a lot of code adopting the latest and greatest fad without any prior experience in it (like "template metaprogramming") and with no knowledge whatsoever of the domain in cause > 3) Keep on #2 until some resemblance of responsability appears, like need to actually deliver that project. Or until the unintended and accidental complexity of said code exceeds their limited mental capacity. Then apply for a new job somewhere else, padding their resume with "experience in fad X" This is called resume / CV driven development. It’s popular because it’s rewarded well. If you’re good with maintenance instead of creating new projects, you might as well be invisible; especially to the non-technical. Google’s reward mechanism is a notorious example, though tbf you’ll see a lesser form of this in nearly every organization Edit: if we’re being fair, even if developers were competent in using x bleeding edge tech, it’s still a negative when they leave. For the longest time, yahoo engineers didn’t know what to do with pg’s store front lisp code
rmason 3y ago
I remember being told the story of the two programmers. One was fast, a real code generating machine. Course he shipped with errors, lots of errors. He didn't document any of this code. But the bosses just loved the guy. Then there was the guy who was slow, but thorough. Part of that extra time was writing tests and doing lots of documentation. When he shipped there were never any errors, just send it to production. So when times got hard naturally it was the slow programmer who the bosses laid off.

goeiedaggoeie 3y ago

accidental complexity is a long term productivity killer.

BlargMcLarg 3y ago

Because the latter barely ever happens in 'twice the time' right from the start. Even assuming the flat 2x, that's a lot for a project that takes 6 months the 'dumb way' for any company nowadays. The pay-off for 'smart way', is unlikely to be there before 2 years from project start. You're lucky to have a company look ahead more than 2 quarters, let alone 2 years. That's not to mention all the other problems as commenters on a different article about speed pointed out yesterday. Dumb way at least gives you something. 'Smart' way goes in and makes a hundred assumptions only to realize they forgot something a prototype would've pointed out to them. Not the dev's fault management doesn't listen to "this is a throwaway prototype".

toss1 3y ago
This is why you should apply the Dumb&Fast approach for a first ~MVP version, plan to throw it away, then apply the smart & careful approach for the more durable versions. The first version should get out there quickly and validate, adjust, and/or destroy your assumptions about your customers, systems, usage & load patterns, etc., then that deeper knowledge and more careful approach goes into the next 'real' version. Prevents premature scaling & optimization, and you never have to pay the tech debt from the 1st version. Source: been there, done that, works great.
angarg12 3y ago
I guess using ambiguous terms like "smart" and "dumb" is the downfall of this article. You could replace them with "good developer" and "bad developer" for whichever definition of good and bad you choose (which will vary for person). From your description, I don't consider smart to do some big upfront design and release a system in 2 years; in fact I'd consider that very dumb instead. In that context dumb would be to go ahead with the first solution that comes to your mind rather than looking at 2-3 solutions, compare them, possibly PoC and measure them (if possible) and then make an informed choice including other's input (depending on the scale of the project).

hirundo 3y ago

I'm never the hero when my code is designed and implemented properly. It just gets deployed and used and maybe a new checked box appears on a marketing page. The reaction I get is "here's your next project." But if I fuck it up and it brings down the world and half the clients are filing tickets and calling the management, and they send me the bat signal and I come in and put a band-aid on my own bad judgement, which takes a half hour, I'm the hero.

throwawaysleep 3y ago

All comes down to incentives. My leetcode has done far more for my salary than work quality. If there is no reward for work that works long term, I will not do work that works long term or bother to learn how it is done.

base698 3y ago

Definitely worse than the smart and gets things done 10x dev who wraps every method call in a separate service connected by queues.

seadan83 3y ago
Code is fast to write, slow to modify. That 10x dev is just in the initial write phase; anyone coming in later to modify that code will appear to be slower.
intelVISA 3y ago
That's a -10x dev pattern..!

isk517 3y ago

The article seems to forget that 'If it's stupid but it works then it isn't stupid' is a common saying. 'Dumb and energetic' is what I usually associate with the various stories my firefighter uncle or paramedic friend tell me about.

intelVISA 3y ago

High-energy, dumb and get things done, juniors are a curse. Complete 3 tickets a day (WOW!) but make about 5-10 bugs as a result. Always fun later reducing a 400+ LOC ball of mud to under 100 lines :)

JoeAltmaier 3y ago

The most applauded programmers at my first job were the communications protocol guys. They'd ship broken code then go to the customer site and patch it. Heros! The rest of us shipped good, tested code and didn't need to do that. Never got applauded at executive meetings; never got special rewards from customer reps, just doing our job.

hinkley 3y ago
One of our platform engineers figured out one day that the Ops guys and the management were in a Stockholm Syndrome toxic loop. They were always in war rooms together, meanwhile our stuff, broken as it still is, mostly works, so we often weren’t needed. Those managers are gone, but the Ops guys still think they're cocks of the walk and it’s never been less true. I’ve had two bosses give an all engineering staff speech that could be summarized as, “we are too big to tolerate heroes now”. But is should have been 6, not 2.
johnvaluk 3y ago
I call them firemen who put out their own fires. Also annoying are the managers who suddenly champion mission continuity without wondering why operations have been free of disruption for years...
cratermoon 3y ago
> they'd ship broken code then go to the customer site and patch it From management's perspective, maybe it looks like the customers love them so much they keep asking for them to personally come and work with them.

hinkley 3y ago

Kurt von Hammerstein-Equord, German general I divide my officers into four classes as follows: the clever, the industrious, the lazy, and the stupid. Each officer always possesses two of these qualities. Those who are clever and industrious I appoint to the General Staff. Use can under certain circumstances be made of those who are stupid and lazy. The man who is clever and lazy qualifies for the highest leadership posts. He has the requisite and the mental clarity for difficult decisions. But whoever is stupid and industrious must be got rid of, for he is too dangerous.

ojbyrne 3y ago
Just googling around a bit, I suspect this is the real source of the quote, not Napoleon.
- hinkley 3y ago
  I've never heard Napoleon, but I'm pretty sure that it's usually attributed to a different German military officer. Quote Investigation is not definitive in who said it. But this seems to be the oldest recorded version?
deleted 3y ago
[deleted]

0tt049 3y ago

The article is indeed amusing, but it needs a closing statement as much as Schindler's List needed that coda. However, anyone who wishes to delve deeper into the dangers of stupidity should read 'Eichmann in Jerusalem' by Hannah Arendt.

Spooky23 3y ago

The apocryphal Prussian General 2x2 captures the problem. “General Freiherr von Hammerstein-Equord, the present chief of the German Army, has a method of selecting officers which strikes us as being highly original and peculiarly un-Prussian. According to Exchange, a Berlin newspaper has printed the following as his answer to a query as to how he judged his officers: “I divide my officers into four classes as follows: The clever, the industrious, the lazy, and the stupid. Each officer always possesses two of these qualities. Those who are clever and industrious I appoint to the General Staff. Use can under certain circumstances be made of those who are stupid and lazy. The man who is clever and lazy qualifies for the highest leadership posts. He has the requisite nerves and the mental clarity for difficult decisions. But whoever is stupid and industrious must be got rid of, for he is too dangerous.”

pfdietz 3y ago
Clever and Lazy is a good description of Admiral Raymond Spruance. He was famously lazy, delegating any task he didn't have to do himself, but was perhaps the best US seagoing commander of the Second World War.

peteradio 3y ago

Dumb and gets things done at least surfaces the true requirements. Yea its annoying as f to fix these guys mistakes or horrendous antipatterns but I praise them for going first and getting that precious feedback. This only works when we aren't testing on customers but instead have good internal testing.