5 ms·

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) G

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.
  - B1FF_PSUVM 3y ago
    > a name for this The canny valley. Aka just learned enough to be dangerous.
  - phkahler 3y ago
    >> You can be an expert in one things and a beginner in another at the same time. That's apparent or implied mastery. Psych friend says it happens all the time, executive type comes to therapy. He's a master at his business, has all sorts of industry experience, really knows his stuff, but then has trouble in say... personal relationships because he's absolutely clueless on those types of things. Mastery in one area does not imply it in another. So when you think "this person is really smart, why are they making xxx stupid decision?" just check if the reason you think they are smart is in any way related to the area of the stupid decision ;-)
- MichaelRo 3y ago
  One big problem if not "the problem" in software development is that it's just too easy to forgo responsibility for the code one writes. With all agile sprints and shit, real feedback for one's actions still comes very very late in the life of a project. This means most people will collect their checks with zero liability for a long time and leave the minute they face the slightest accountability for their actions (code, architecture etc). I'm not condoning it but it's a useful parable. Story goes that during World War 2, the engineers responsible for designing armor for Soviet tanks were required by direct Stalin orders to test it themselves in the final stage: they'd be crammed in a tank equipped with the armor they built and the tank would be fired at with live ammunition. This sort of "your life depends upon it" test should be introduced as standard requirement for software engineers, there'd be a lot fewer remaining but at least we'd have some quality :)
  - JohnFen 3y ago
    > With all agile sprints and shit, real feedback for one's actions still comes very very late in the life of a project. This is one of the things I dislike about agile methodologies. A big part of why I choose the jobs that I do is because I'll learn something new in them that I want to learn. Agile methodologies don't leave much room for that sort of analysis and learning. They are very focused on production, and only production.
    - nradov 3y ago
      The Scaled Agile Framework (SAFe) places a major emphasis on learning. https://scaledagileframework.com/continuous-learning-culture/ https://scaledagileframework.com/continuous-learning-culture... https://scaledagileframework.com/iteration-retrospective/ https://scaledagileframework.com/iteration-retrospective/ https://scaledagileframework.com/innovation-and-planning-iteration/ https://scaledagileframework.com/innovation-and-planning-ite... Of course some organizations fail to implement the methodology correctly and skip the learning part. But you can't blame the methodology for that.
      - JohnFen 3y ago
- aledalgrande 3y ago
  > In almost 20 years I've learned that, at least to me, the most challenging group to manage are mid-level developers. mid-level develeopers promoted to architects/managers because the startup grows fast, in a startup that mostly hires juniors, and then sitting there without ever updating their knowledge
- mkaic 3y ago
  This is that one meme with the normal distribution from total novice to jedi master: https://i.kym-cdn.com/entries/icons/original/000/035/645/cover4.jpg https://i.kym-cdn.com/entries/icons/original/000/035/645/cov...
- BlargMcLarg 3y ago
  Hasn't been my experience. People who overthink will always overthink. People who play safe and love to discuss things until the sun comes up, will do just that. People who want to be hands on, break things first and then try it again with new information will do exactly that. Whenever I see people overcomplicate things, the idea usually comes from a senior and then passed down to the chain of loyal followers. We can have a debate on whether that is a 'true senior', but the books sold, praised by the majority of the dev crowd and then recommended by said seniors don't lie. 5+ years or 40+ years, there have been those going for 'crazy new libraries, patterns and ideas', even bold enough to claim things that no study has been able to back up so far. And god forbid sometimes a mid-level does figure out something can be done in a better way and the seniors ignore it while stuck in their old ways.
  - cratermoon 3y ago
    OK, I'll bite. > even bold enough to claim things that no study has been able to back up so far. What claims? Who and where do those claims come from?
  - whstl 3y ago
    That's fair and fine. You can call the three levels "beginner - expert beginner - experienced", if you don't want to use the ranks. Doesn't matter. This still happens in the middle of the career and way more often than it should.
- jcadam 3y ago
  ...and yet, mid-level developers seem to be the most in-demand.
  - whstl 3y ago
    Because they're the ones who know enough to get the job done, and are not as expensive or difficult to hire as senior developers. Doesn't mean they aren't the most challenging group to manage.
  - Spooky23 3y ago
    Nobody wants to pay for senior people with a clue, and nobody wants to train cheap juniors.
- jt2190 3y ago
  > … they just make simple code which I can understand with a glance. That locks the team into “as smart as me, but no smarter” and doesn’t really scale beyond very small teams and very rote work. One person rarely has all the ability plus all of the “on the ground” context that’s necessary to do great work across a larger system. It’s more important IMHO to require devs to communicate what they’re doing at a design level, to help them set clear goals and define (and enforce) boundaries. Far too often I’ve seen seniors go nuts “fixing” a system that in some theoretical sense was broken but for all practical purposes worked just fine, while neglecting things that were truly issues for the organization. Note that this is primarily a management issue, mainly a lack of oversight and control.
  - thebigwinning 3y ago
    Agreed. It's much harder to be a manager of people smarter than you doing stuff you don't understand, but also absolutely necessary.
  - whstl 3y ago
    > That locks the team into “as smart as me, but no smarter” No it doesn't. People aren't really "smarter" just because they write incomprehensible code. The "smarter" way is being able to get things done without making a mess for yourself, the other people working with you, and after you. Over-engineering is not a positive quality. And "not easy to understand" doesn't mean "impossible". Maybe for Juniors! In fact, it's the people writing the difficult code that are forcing teams to be "as smart or smarter than me". It's time to stop rationalizing architecture astronautics. There is nothing "smarter", it's just annoying and expensive. - > One person rarely has all the ability plus all of the “on the ground” context that’s necessary to do great work across a larger system. And this is exactly why we need code to be comprehensible to everyone.
    - deleted 3y ago
      [deleted]
    - deleted 3y ago
      [deleted]
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.

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.
- B1FF_PSUVM 3y ago
  > a name for this The canny valley. Aka just learned enough to be dangerous.
- phkahler 3y ago
  >> You can be an expert in one things and a beginner in another at the same time. That's apparent or implied mastery. Psych friend says it happens all the time, executive type comes to therapy. He's a master at his business, has all sorts of industry experience, really knows his stuff, but then has trouble in say... personal relationships because he's absolutely clueless on those types of things. Mastery in one area does not imply it in another. So when you think "this person is really smart, why are they making xxx stupid decision?" just check if the reason you think they are smart is in any way related to the area of the stupid decision ;-)
MichaelRo 3y ago
One big problem if not "the problem" in software development is that it's just too easy to forgo responsibility for the code one writes. With all agile sprints and shit, real feedback for one's actions still comes very very late in the life of a project. This means most people will collect their checks with zero liability for a long time and leave the minute they face the slightest accountability for their actions (code, architecture etc). I'm not condoning it but it's a useful parable. Story goes that during World War 2, the engineers responsible for designing armor for Soviet tanks were required by direct Stalin orders to test it themselves in the final stage: they'd be crammed in a tank equipped with the armor they built and the tank would be fired at with live ammunition. This sort of "your life depends upon it" test should be introduced as standard requirement for software engineers, there'd be a lot fewer remaining but at least we'd have some quality :)
- JohnFen 3y ago
  > With all agile sprints and shit, real feedback for one's actions still comes very very late in the life of a project. This is one of the things I dislike about agile methodologies. A big part of why I choose the jobs that I do is because I'll learn something new in them that I want to learn. Agile methodologies don't leave much room for that sort of analysis and learning. They are very focused on production, and only production.
  - nradov 3y ago
    The Scaled Agile Framework (SAFe) places a major emphasis on learning. https://scaledagileframework.com/continuous-learning-culture/ https://scaledagileframework.com/continuous-learning-culture... https://scaledagileframework.com/iteration-retrospective/ https://scaledagileframework.com/iteration-retrospective/ https://scaledagileframework.com/innovation-and-planning-iteration/ https://scaledagileframework.com/innovation-and-planning-ite... Of course some organizations fail to implement the methodology correctly and skip the learning part. But you can't blame the methodology for that.
    - JohnFen 3y ago
aledalgrande 3y ago
> In almost 20 years I've learned that, at least to me, the most challenging group to manage are mid-level developers. mid-level develeopers promoted to architects/managers because the startup grows fast, in a startup that mostly hires juniors, and then sitting there without ever updating their knowledge
mkaic 3y ago
This is that one meme with the normal distribution from total novice to jedi master: https://i.kym-cdn.com/entries/icons/original/000/035/645/cover4.jpg https://i.kym-cdn.com/entries/icons/original/000/035/645/cov...
BlargMcLarg 3y ago
Hasn't been my experience. People who overthink will always overthink. People who play safe and love to discuss things until the sun comes up, will do just that. People who want to be hands on, break things first and then try it again with new information will do exactly that. Whenever I see people overcomplicate things, the idea usually comes from a senior and then passed down to the chain of loyal followers. We can have a debate on whether that is a 'true senior', but the books sold, praised by the majority of the dev crowd and then recommended by said seniors don't lie. 5+ years or 40+ years, there have been those going for 'crazy new libraries, patterns and ideas', even bold enough to claim things that no study has been able to back up so far. And god forbid sometimes a mid-level does figure out something can be done in a better way and the seniors ignore it while stuck in their old ways.
- cratermoon 3y ago
  OK, I'll bite. > even bold enough to claim things that no study has been able to back up so far. What claims? Who and where do those claims come from?
- whstl 3y ago
  That's fair and fine. You can call the three levels "beginner - expert beginner - experienced", if you don't want to use the ranks. Doesn't matter. This still happens in the middle of the career and way more often than it should.
jcadam 3y ago
...and yet, mid-level developers seem to be the most in-demand.
- whstl 3y ago
  Because they're the ones who know enough to get the job done, and are not as expensive or difficult to hire as senior developers. Doesn't mean they aren't the most challenging group to manage.
- Spooky23 3y ago
  Nobody wants to pay for senior people with a clue, and nobody wants to train cheap juniors.
jt2190 3y ago
> … they just make simple code which I can understand with a glance. That locks the team into “as smart as me, but no smarter” and doesn’t really scale beyond very small teams and very rote work. One person rarely has all the ability plus all of the “on the ground” context that’s necessary to do great work across a larger system. It’s more important IMHO to require devs to communicate what they’re doing at a design level, to help them set clear goals and define (and enforce) boundaries. Far too often I’ve seen seniors go nuts “fixing” a system that in some theoretical sense was broken but for all practical purposes worked just fine, while neglecting things that were truly issues for the organization. Note that this is primarily a management issue, mainly a lack of oversight and control.
- thebigwinning 3y ago
  Agreed. It's much harder to be a manager of people smarter than you doing stuff you don't understand, but also absolutely necessary.
- whstl 3y ago
  > That locks the team into “as smart as me, but no smarter” No it doesn't. People aren't really "smarter" just because they write incomprehensible code. The "smarter" way is being able to get things done without making a mess for yourself, the other people working with you, and after you. Over-engineering is not a positive quality. And "not easy to understand" doesn't mean "impossible". Maybe for Juniors! In fact, it's the people writing the difficult code that are forcing teams to be "as smart or smarter than me". It's time to stop rationalizing architecture astronautics. There is nothing "smarter", it's just annoying and expensive. - > One person rarely has all the ability plus all of the “on the ground” context that’s necessary to do great work across a larger system. And this is exactly why we need code to be comprehensible to everyone.
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]

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.