Dumb and Gets Things Done (2010)
johndcook.com
johndcook.com
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.
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.
Similar: https://pages.cpsc.ucalgary.ca/~robin/class/449/Evolution.ht...
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.
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.
Go reread what I wrote: I never made that assertion.
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.
>> 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.
Complexity is the enemy.
Code that is easy to understand - for others, and for yourself in six months - pays huge dividends.
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
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.
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.
Sounds like "Advanced 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.
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 ;-)
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...
https://media.licdn.com/dms/image/C5622AQFrWvMGA7E7bA/feedsh...
Resume Driven Development.
The canny valley.
Aka just learned enough to be dangerous.
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.
> 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?
Doesn't matter. This still happens in the middle of the career and way more often than it should.
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 :)
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.
https://scaledagileframework.com/continuous-learning-culture...
https://scaledagileframework.com/iteration-retrospective/
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.
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.
Doesn't mean they aren't the most challenging group to manage.
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.
> 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
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.
I wonder what do people gain from calling people dumb or treating them as dumb?
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.
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 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.
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.
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.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.
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.
From management's perspective, maybe it looks like the customers love them so much they keep asking for them to personally come and work with them.
“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.”
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".
Source: been there, done that, works great.
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).
Always fun later reducing a 400+ LOC ball of mud to under 100 lines :)
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.
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.
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.
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 )
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.
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.
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
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.
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.
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.
It's much easier to talk than it is to change people's minds.
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.
Teaching is a whole skill on it's own.
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 think this post might be useful for those people – a way to suggest "but what if not?"
(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).
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.
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.
It’s deliberately empty so that people put in stupid, smart, lazy, energetic whoever they deem belongs there.
It's about the fixation on "gets things done" without seeming to care about what it is that gets done.
https://steve-yegge.blogspot.com/2008/06/done-and-gets-thing...
> 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.
He's there to help us when we mortals get stuck. I tried to poach him once, let's just say people got upset.
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.
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.
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.
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.
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…
The articles sounds like it was written by LLaMA, and injects detractors to dissuade critical content evaluation.
https://www.youtube.com/watch?v=wvVPdyYeaQU
Personally, 40% of our income is from cleaning up what competitive “ignorant” people created.
Have a glorious day =)
It drives the Architecture Astronauts crazy, but Grug no mind. Neither do PM. His code work, and feature done fast.
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 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.
I'm not saying "armies" should never fire anyone - bad cultural fit is certainly one legitimate reason.
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.
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.
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.
Replace 'ignorant' with 'climate change denialism' or whatever belief you might find abhorrent.
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
Dumb and gets things done - https://news.ycombinator.com/item?id=2042759 - Dec 2010 (24 comments)
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]
I guess pick your poison on the last 2?
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)