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.
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".
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.
> … 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.
> 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.
Then we might have a misunderstanding. If so, I'm gonna need more context for the phrase “as smart as me, but no smarter”.
In the original comment I never claimed there were different "smartness" levels across the ranks, and stated that Juniors can write code that is understandable. It's not about experience or smartness, it's simply about the importance of not overcomplicating the codebase to the best of your ability, no matter if you're a Junior or Senior. To me, that's being "smarter", and it's definitely possible to have this kind of "smarter" in any team.
> 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
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.
Richard Dreyfus came up with a Five-Stage Model of Adult Skills Acquisition.
1 Novice. Follows simple rules. Performance is poor.
2 Advanced beginner. Rules modified by context & situation.
3 Competence. Able to recognize more contextual elements than can be used. Ability to chose a perspective for analysis and prioritize features of the context. However, does poorly at choosing the right perspective.
4 Proficient. If detached rule-following is replaced by intentional learning, learns to use judgment and emotion in choosing perspectives. However, that judgement and emotion informs a decision still based on rules and maxims.
5 Expertise. Applies refined discriminatory perceptions to determine what must be done and what must happen to get there. Analysis and calculation are not necessary.
It's stage 3, "does poorly at choosing the right perspective" and 4, "decision still based on rules and maxims" where problems arise. In Dreyfus' original paper, he considered learning in the context with feedback.
BTW the paper is worth reading for Dreyfus' comments on feedforward simulated neural networks.
"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.
>> 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 ;-)
Sounds like the 'bell curve'/'midwit' meme, which shows an IQ bell curve and three people: one on the left, one in the middle and one on the right. The left and right have the same view, and the middle has a (clearly worse, usually overcomplicated) view.
Example: The dimwit just uses a simple notes app. The midwit uses an overengineered and elaborate note-taking system using flash cards, Anki, spaced repetition, etc. The midwit spends more time on his note-taking system than he does actually taking notes on anything. The expert realises that all of that bloat is unnecessary and that he is more effective just using a simple notes app. You can communicate all of this in one image: https://media.licdn.com/dms/image/C5622AQFrWvMGA7E7bA/feedsh...
A complication is the skills curves overlap so while I was a dangerous intermediate at database design 15 years ago, now I am a dangerous intermediate at organization design.
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.
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 :)
That's very capital-A Agile. As per the original agile manifesto, getting feedback as soon as possible is the primary goal of agile, and all the rest is just potential ways of making that happen.
> 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.
Well, this comes around to a perennial debate about agile methodologies in general. Yes, an argument can be made that the fault isn't the methodology, but the poor implementation of the methodology.
However, the case can also be made that if a methodology is rarely implemented correctly, that's because there's something wrong with the methodology.
Most companies (every single company I've worked for, anyway) implement an agile methodology purely to crank up production speed. No other consideration enters into it.
I have worked for quite a few consultancies and feedback is just not there, either the code works or it doesnt, there is no feedback just additional features/bugs to discover.
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?
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.
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.
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.
> 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
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.
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.
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.
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.
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.
'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.
Yeah that makes sense. I suppose that juxtaposition just didn't click with my brain when I read it. Intelligent people can certainly be naive or ignorant.
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.
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?
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.
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.
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.
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...
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.”
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.
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.
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.
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".
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.
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).
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.
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.
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.
What I deem smart or dumb changes over the years. When I was a junior dev, I saw someone totally new to coding create a single static class method that did tens of thousands of lines of if else checks for a state machine. The group of us junior devs shared the code snippet with each other and laughed at how ridiculous it was. The code could've been so much cleaner with proper extraction and abstraction. The bootcamp fresh minted dev was what I had considered as someone who's dumb but gets things done.
Over the years as I worked with more teams, I've seen people do "smart" things like a one liner quadruple nested ternary return. Everyone marveled at how clean it looked. I've also seen smart devs who experimented with Haskell or OCaml in their spare time start using closures in closures in closures. Lambdas everywhere when remotely possible. Anyone who didn't understand what they were doing were too inexperienced and dumb. They were always heralded as the geniuses of the company.
Nowadays, I very much rather debug a ten thousand line static method with if else clauses. It's quick to navigate, and incredibly easy to debug. Stupidly simple is my new smart.
The only thing I've really concluded after so long is that, the only dumb person in the room is always me. I've been told I'm a pretty kick-ass teacher so that pretty much seals my dumbass status.
This is the main reason I dislike java Spring Boot: too much magick going on at runtime which is difficult to figure out if you are not an expert in Spring.
Much better to have (pre)generated code which is then compiled like any other java code. In this case you can see the code, you can navigate it, you can single-step thru it when running.
Spring Boot is too much like monkey patching in Ruby. Please let me see the code that runs.
Early in my career I remember being really bothered by a guy who insisted we use a finite state machine for handling some stuff I’d already written and was pretty happy with. In my mind it was such overkill and he was being academically ostentatious or something.
I now love having opportunities to lean on finite state machines because I’m more aware of how dumb my primate brain is and how helpful it is to have guard rails. So, multiple layers of dumb: I couldn’t figure out that this guy was smart enough to see how dumb we were in the context of the problem we were solving, and he was ultimately trying to save me from myself.
This was around ten years ago.
I’ve also been told I’m a great teacher, haha. Sealed.
This is a fun example because I've seen exactly the reverse situation. (Not to say state machines are bad, just to say sometimes they don't fit as much as it seems on first glance.)
A bunch of mid-level devs on the team wanted to model our new thing as a state machine. But it dealt with a LOT of edge cases. Including real fun things like "that actually CAN be a valid state transition if Customer Service does it to manually resolve an issue caused by a previous bug or something, or just to make a customer happy, even."
I was the guy who eventually convinced them not to by illustrating just how many states and transitions this machine would actually have to have to do everything it needed to. A lot fewer people want to write thousand-node state machine descriptions than who want to write 20-node ones.
(How did I know that would happen? Because I'd previously been a mid-level engineer who jumped straight to "state machine!" for something and it added countless complexity and pain to the project. :D )
Absolutely, that's a legitimate concern. A real benefit of approaching state machines model-first is that you get to see those nodes on paper before trying to write the code, and you can quickly recognize a tire-fire of an idea vs a situation where you can sanely box in logic and avoid state-explosions.
I've had a few tasks with state machines turn into messes, but thankfully they were only at the cost of my personal time rather than my team's. I definitely prefer them for cases where a model juuust fits into your head, or nearly so — it seems fairly intuitive, and not totally monolithic in scale or inversely tiny in proportion. There's this sweet spot where it's just complex enough that you want to box it in, but not so complex that a formal description using a rigid convention would endanger you from your coworkers.
Yeah the attempting-to-model first approach is great too for trying to avoid walking into "we thought this would take three weeks but it's gonna take 6 month" situations because the initial requirements were not all the way thought through around edge cases and such, and looping stakeholders in to just how nasty it may or may not be early-on.
That dovetails really well into our other thread about putting an emphasis on listening and understanding rather than trying to lead conversations. Putting attention to properly understanding a problem is very empowering, and often leads to more decisive data points than discussions can.
Ooof, saw a team get hung up on modeling the application as a state machine once. No existing solution could support all the edge cases so they had to write a templated state machine engine first.. Yeah.. No surprise what happened to that later.
I think going state machines all the way down is almost always a mistake. I can maybe see using state machines to undergird some logic in an application, like… I don’t know, maybe you’ve got some authentication stuff you’d like to reliably model as states, and that’ll be fairly foundational. But if you then model authenticated and unauthenticated states as substates, then have further nested states representing the sort of scaffolding or actual features of the application… That’s a nightmare.
I’ve noticed some people are hesitant to compose state machines too, like using dumb states to execute smarter state machines such that you can localize complexity and isolate things better. Almost like people think it needs to be a monolithic machine in order to truly maintain safety?
In any case, like any pattern there’s plenty of room for abuse, haha. I am a pattern abuser myself, usually learning things the hard way.
I was recently discussing something similar, and we came to the conclusion that the difference lies in Intention
Doing an overly complex method because that's the only way you know vs doing it because it has benefits
We came to it in a discussion about manners (My interlocutor usually does something considered rude, but does it in an over the top way that always get a chuckle) You need to know plenty about rules, before you know how to break them with good results
As someone who runs a startup, Id kill for a couple of "dumb" people who can get something done.
A number of years a go I worked at a startup, and we had a young inexperienced employee, who didn't know very much at all. When we had meetings he would unprompted send out lists of everything we had discussed, along with links and useful information. If someone had mentioned that we needed a to rent a truck once we get to LA, to move some gear, he would look up all the places where that could be done. Simple stuff like typing stuff in to google. One of the best employees i have ever worked with.
Every time he asked a question, it was a question based on all the research he had done based on the question he asked a few days ago.
Its great if you already have the solution, but what i really want is people who can go out and find the solution. There are a lot of smart and lazy people out there, but if you build the future you cant rely on old information, you need to iterate on new solutions, and that requires people who can get things done.
So please be smart and experienced, but unless you can get things done you are just in the way.
In this particular context, the connotation of "dumb" does not pertain to a complete lack of knowledge. Even individuals regarded as intelligent may find themselves in situations where their knowledge is limited. Rather, it pertains more to one's capacity for logical reasoning and discerning connections, which your employee seems to have demonstrated proficiently. They embody the role of the "field commander" as described in the article.
Consider, instead, if the employee inundated your inbox with materials only loosely relevant to the meetings, rather than undertaking the extensive efforts described earlier. Alternatively, envision the employee hiring a moving company without consulting you, rather than researching truck rental options.
The article's reference to "dumb and energetic" pertains to this type of behavior—acting impulsively and energetically without proper consideration—rather than the situation you are describing.
Indeed, there are companies that would reward that type of 'bias to action' even if the results weren't helpful at all.
> When we had meetings he would unprompted send out lists of everything we had discussed, along with links and useful information.
This has been a practice of mine for a long time now. A boss of mine once told me “the guy taking notes will never have any sway in the conversation, you’re handicapping yourself”, and I said something like “the guy taking notes actually knows what’s going on, though”. He wasn’t very receptive at first, but it stuck, and he actually began to use me as a reference to know what was going on.
I love talking to people and keeping tabs on what’s up. Teams tend to be awful at it, but it’s no specific person’s fault. Making a point of doing it is like a relatively inexpensive super power. You can help your coworkers a lot, and you rarely end up doing unnecessary work. That’s one of my favourite parts I think; I really can’t stand wasting my or other people’s time.
I think my boss was wrong, too. When you’ve got a good grasp on what’s going on, you’re in a far better position to weigh in after initial conversations. I’d prefer to hear people out and only interject if I see obvious issues with their ideas. Otherwise I’ll just listen.
Yeah, I like to say the person who has the most impactful/efficient sway in a conversation is the one who knows what's going on well enough to not have to talk constantly, but to just drop in some important questions or corrections or other considerations at the necessary time. ;)
It's much easier to talk than it is to change people's minds.
The article doesn't equate "dumb" with "inexperienced". It equates dumb with "makes wrong and dangerous decisions".
In this context, you probably do not want industrious people who will consistently make mistakes and create more work and a mess for others to clean up. The dumb also do not learn from their mistakes -- they are not simply inexperienced.
> One time I heard someone praised as a good teacher. Not knowledgeable, but a good teacher. I objected that if someone is ignorant but a good teacher, does that mean they’re effective in conveying their ignorance? Wouldn’t that be a bad thing? No, all that mattered was that he was a good teacher.
I recently started volunteering with an organization that works to build CS programs in schools that don't have them[0]. The typical way that CS programs get started is a teacher of some other subject is given the CS curriculum and told to teach it. They typically don't know anything about CS, often have not taught a related subject (e.g. math), and yet they're expected to teach it effectively. Why? Because they are teachers. They are trained to teach, and the smart ones are smart /at that/. Note that for a new CS teacher, they typically use an existing curriculum developed by someone else (e.g. Code.org), so aside from the teacher's own internal biases, any ignorance comes from someone else.
I've always had respect for teachers as people who do something that try to build up other people, but seeing how a teacher goes from zero-to-teaching has opened my eyes to how and why great teachers are real multipliers.
You don't have to be that knowledgeable to teach the basics. If the curriculum is binary arithmetic, there's far more skill in trying to articulately convey the concept to someone who has done base10 all their life, than there is actually knowing how to do base2.
There's a lot of people out there that are amazing at their jobs/domain - but they absolutely cannot explain it to a newbie.
I generally like his essays, but is there anything substantive here?
He doesn't define smart. He doesn't define what it means to get stuff done. He doesn't convince me that there are a lot of dumb people getting stuff done. If there are, he doesn't convince me that they are much of a problem (hypothetical good teachers that teach ignorance isn't an argument, it's not even an anecdote). And even if they are a problem, he doesn't offer a solution.
If anyone was able to takeaway anything useful from this article, please share.
I have seen people honestly suggest that it doesn't matter exactly what they're adding to the software, or how they add it, as long as they're adding something that someone else sort of asked for.
I think this post might be useful for those people – a way to suggest "but what if not?"
I agree and also think the author did a wrong turn somewhere after the original quote.
One point of the quote roughly translated into the modern office is that dumb managers that create pointless busywork for others are part of big corporations and all together not a big deal as long as they are lazy dumb managers. Energetic dumb managers on the other hand may create a neverending spiral of problems and need to be watched carefully.
(On a sidenote there are several versions of the quote attributed to German generals - Moltke the elder, von Mannstein and von Hammerstein-Equord and I think most of them are better).
I have indeed encountered numerous individuals proclaiming the mantra of "any action is better than inaction," leading inevitably to the notion that "more actions equate to greater efficacy."
In reality, countless establishments still uphold the belief that the measure of "lines of code" serves as a suitable yardstick for gauging "productivity," even in unexpected contexts.
The key lesson to be gleaned from this is the need to convey this concept in a manner comprehensible to executives, who often grasp the intricacies of warfare terminology and analogies.
Agreed. He’s unnecessarily conflating “fast” and “bad”. Often times people move quickly because they know what they’re doing, not because they’re mindlessly flailing.
The attempt to characterize the two traits as inseparable is like drawing a picture of a <demographic_x> robbing a store and showing it to people like “See how awful <demographic_x> is?”. There’s no actual evidence, it’s just a baseless assertion.
I'd go as far as to say that those of us posting on HN on a Wednesday consider ourselves both clever and lazy - I do! - and so the joke is little more than puffery bait.
I figured if the author was going to make such a egregious mistake in the opening paragraph that he was too lazy to write anything that I could trust afterwards, and so I stopped reading.
The author refers to it as a joke, which immediately changes this from "A quote from Napoleon" to "A joke about Napoleon." I don't think it's wise to write off the rest of the article because of it.
In Ross Perot's defense (I know...) there's an argument that without him we wouldn't have the iPhone. He provided NeXT with some critical funding at a time when their technology was still outside the computing mainstream. Without NeXT, no MacOS X. No OS X, no iOS.
> Someone who always seems to be finishing stuff so fast it makes your head spin. That's what my Done clause means. It means they're frigging done all the time.
> You can't interview these people. For starters, they're not interested; these are the people that companies hold on to as long as humanly or companyly possible. The kinds of people that companies file lawsuits over when they're recruited away.
I work with one of these. They're a Gervais Principle Loser, only works three days a week, doesn't care about promotions, work politics, money or anything really. He's an extreme person as well, dressing in the same clothes every single day because he doesn't care about clothing.
He's there to help us when we mortals get stuck. I tried to poach him once, let's just say people got upset.
This article is such a mix of hilarious and deeply frustrating.
It does identify a real problem of people who get things done but what they have done is useless at best or harmful at worst.
The issue is what to do about it. I’m guessing it’s hard to say because the two skills that I’d think of as smart in the context of this article are, understanding what is important and taste to know what good looks like.
Of course both of those things are very hard to teach and in practice mostly seem to be taught via apprenticeship.
The article delineates a course of action: Shoot them. Clearly, not in the literal sense, but rather suggesting that "dumb and energetic" ought to be dismissed if they can't rectify it.
One thing that I often repeat is that stupidity is worse than malice. And by "stupidity" I don't mean lack of knowledge; I mean lack of reasoning. The people who are malicious but smart will only cause you damage when it benefits them, but the stupid will cause you damage all the time - even when it harms them.
I feel like this text has a similar reasoning. The "dumb and gets things done", or the "dumb and energetic", they're so eager to help, and yet they're doing the opposite. For example they'll write that piece of spaghetti that breaks often, has more holes than a sieve, but it's still used by everyone else around them - because the lazy didn't do it, and the smart are probably worried about other stuff.
It's a bane of all bureaucratic structures because such energetic/"gets things done" people tend to rise in the ranks (their self-confidence also helps) and then their stupidity allows them to inflict damage on truly impressive scale. No wonder there exists a Soviet-era saying "who's more dangerous than an idiot? An idiot with initiative" because they've been hit hard with that unpleasant truth.
You can't shoot the dumb and energetic in modern society, but assigning them to futile cycle tasks is an alternative solution. You don't want them involved anywhere they could do any real damage, but they're on your roster, and they need something to do. Have them continually move goods between several different warehouses, for example. Or, gather a group of them together and put them on an advisory committee that meets daily in a remote building, and task them with preparation of a 1,000 page report, which later goes into the recycler.
People can get smarter, too. If they recognize they're involved in a futile cycle, then that could mean they're ready to move on to doing something more useful.
I have lived this in contexts, it is absolutely true. Energetic dumb people get noticed and often promoted based on their energy and seeming ability to move fast. That quickness is usually due to the fact that they don’t do any proper due diligence or analysis, they just bull ahead.
The trick is to catch them early enough and get rid of them as quick as you can.
Seen this both in startups and big companies where a person was fired a year to the day they were hired (or whatever their contractual “safe period” was).
I have also seen orgs where they did not catch them in time. You do not want to work there.
Because it is unavoidable at the moment... but wouldn't (any) GPT/LLM be a candidate for "Dumb and Gets Things Done"?
In my experience, chatGPT tries so hard to write convincing and plausible answers that it has no problem to compromise on the correctness of the content. Well, I know, it has no sense of correctness at all. On the other hand, it could be useful as a foot soldier…
I'd consider myself dumb and lazy in this context. I'm lazy, so nothing I build is ever complicated. And I'm dumb, so it's never very clever either. The result is simple straightforward readable code, with very little indirection, and minimal modularization.
It drives the Architecture Astronauts crazy, but Grug no mind. Neither do PM. His code work, and feature done fast.
What that quote by Napoleon fails to account for is that "smart" vs "dumb" isn't innate. People start off dumb, and through experience, become smart over time.
If you fire your dumb and energetic people, you'll be hard-pressed to find any smart and energetic ones... pretty much only those whose current employers are dumb enough to lose them.
You go to war with the army you have, not the army you wish you had. Your "army" is going to include dumb and energetic people. Learn to manage them. Encourage their energy by giving them lots of work; insulate yourself from their inexperience by ensuring the work you're giving them is low-risk and reviewable, and mentor them through their "dumb" phase.
The question isn't whether you have enough low-risk and reviewable work (if you think you don't have any, believe me, you do), it's whether you have the luxury of budget to pay salaries to get it done.
I agree on having the luxury of budget being a thing, since only large companies have that.
I think though you're lumping together both the inexperienced and the stubornly dumb, and by that I mean those that aren't humble/flexible to learn from experience. It's crucial to filter out arrogance that can't be taught so you don't poison your workforce.
In my book, humility is a core cultural value. You should always be willing to learn from others, and not lose your shit when someone gives you constructive criticism.
I'm not saying "armies" should never fire anyone - bad cultural fit is certainly one legitimate reason.
> One time I heard someone praised as a good teacher. Not knowledgeable, but a good teacher. I objected that if someone is ignorant but a good teacher, does that mean they’re effective in conveying their ignorance? Wouldn’t that be a bad thing? No, all that mattered was that he was a good teacher.
Maybe the same isn't true of programmers, but for teachers, being knowledgeable and being a good teacher are different, independent qualities.
Sure, there's some base knowledge that should be present. But it's absolutely possible to be a good teacher without knowing much beyond the basics.
My best teachers weren't the most expert in their respective domain, they were the ones who let me see the world in a different way -- also in maths, and got me excited about the domain.
I teach ballet dancing and clarinet to my kids without knowing anything about either. But I know good when I see or hear it, and I steer them in the right direction.
I want to break a torch for the "Dumb and get things done" crowd.
With out them nothing would get finished.
Try developing a complex and large product with a team consisting only of "smart and getting things done" people.
Not going to happen. never. complete disaster from the start.
You need the "dagtd" people to do the essential but boring parts.
Attend customer meetings. Write requirements and documentation. etc.
NEED. THEM. BADLY. No way around it.
Luckily that is not as big a problem as it seems, because about 80% of "smart and getting things done" people are actually "dumb and getting things done".
They just don't know it. Which is perfectly fine. Just don't tell them.
> One time I heard someone praised as a good teacher. Not knowledgeable, but a good teacher. I objected that if someone is ignorant but a good teacher, does that mean they’re effective in conveying their ignorance? Wouldn’t that be a bad thing? No, all that mattered was that he was a good teacher.
I need more context. An elementary school teacher that is really great with students but doesn't know much beyond the books and other materials is probably a good part of the 6 or more teachers a student will have.
It doesn't say professor but even then it seems like an odd demand to me.
In this context, I think the term 'ignorant' seems likely to be employed to convey a repugnant belief rather than a state of overall lack of knowledge.
Replace 'ignorant' with 'climate change denialism' or whatever belief you might find abhorrent.
I liked the Napoleon joke, but I was not sure what the author’s point was until an HN user eloquently wrote a closer as a comment.
Going on a tangent, it was also hard to take his Ross Perot comment seriously. Perot had one political goal: reduce and end the deficit so that we can keep our debt level sane. His campaign is what caused GH Bush to lose a 2nd term to Bill Clinton. It’s also what drove the fleeting bipartisan obsession with minimizing the deficit until GW Bush’s ascension, where budgets ballooned for national security
Napoleon, of course, was smart and got things done. Until he made numerous catastrophic and boneheaded choices involving what to try to get done, and as a consequence spent his last few years pacing around in a little garden on the most remote island they could find for him. What if people aren't a steady state? What if people defy such easy categories? What if Napoleon's matrix itself was one of his bad choices?
I think we’ve all worked with people that fall into these when it comes to PR time.
Smart and energetic - "I think this covers everything functionally and I’ve added a couple of extra unit tests for the functions I had to refactor”
Smart and lazy - "This covers everything but I’ll add the unit tests in a follow up PR shortly" [never happens]
Dumb and energetic - "Can you review this ASAP please, it’s only small, shouldn’t have any bugs or issues. I just need to get this in because <manager> is looking for this feature ASAP. I will fix any issues in a follow up PR." [prod issue w/ feature after go-live]
Dumb and lazy - <Raises PR, fails CI tests, doesn’t respond to any feedback for a week> [feature 3 weeks late]
if programming language were human, what would dumb-smart and lazy-energetic be?
my take:
dumb languages would be ones that have few concepts, can be made smarter thru evolutionary iteration (committee adding new concepts)
energetic languages would be ones that require much typing (assume efforts = typing), can be made 'lazy' internally by macro (code that writes code) and externally by code generation (ai, ide etc)
Dumb and lazy make the best programmers. Lazy people are too lazy to write tens of thousands of lines of code, and dumb people are too dumb to understand overly complex code so they keep it simple. Short and simple code is the best.
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.