Good engineers are right, a lot
seangoedecke.com
seangoedecke.com
Continue to learn and grow in knowledge while maintaining self-awareness about what you truly know and what you don't.
I never wanted to become a team lead or staff engineer but the older I get the more I feel like I should.
And the worst engineers are the ones who _really_ like specific things, like really liking a certain language or a certain library or a certain tool.
It baffles me because I usually have at least a mild dislike about all tech I work with (including systems of my own design), I think it keeps me honest about the flaws of the systems I work with.
You can literally just specialize in something and just do that for the rest of your career. In fact they have the opposite problem, sticking with very old "proven" techniques despite innovation happening.
The incentives are not to grab the latest thing because it's 5% "better" or to pick the shiny new thing because its more interesting. Instead, the engineer of record thinks to themself: "gosh if this fails on a snowy day and kills an assembly of school children, I'm personally liable for it. I've got a lot of experience in the design, construction and verification of this technology, that's the one I'm going to choose." Only when a new technology comes along that is MUCH better will they consider using it. Some may call this an excessively conservative approach, but failures in this regard are very rare as a result.
I don't understand what you DON'T get? Our profession is full of incompetent people that have done nothing but make things worse everywhere they go, and they all make more money than I do, and some of them have been deified as thought leaders.
Engineering doesn't have thought leaders.
Imagine asking a writer to switch dialects. "It's the same thing, but just Old English." While some would find it fun, if you randomly swapped out dialects for each process I bet authors would get really tired of it really quickly, especially once they figure out which ones jobs with their natural thought process.
It is not optimized. It is not the fastest. But it works everytime.
This is akin to using the arrow library in Python whenever I have to do the slightest date whatever. Display a date? arrow. Manipulate a date? arrow. Store a date? ISO. Yes this is a dependency, yes, there are edge cases but it mostly works - certainly better if I had to understand dumb vs full dates etc.
Unfortunately I am a curious and excited person and I keep changing this "ideal stack" twice a year but still.
Reluctant leaders are some of the best. They're there to get things done and rarely overstep their area of competence.
If you are a leading engineer and you are able to deliver on time and within budget constraints, that would be called a success, but I doubt even the leader themself looks back at what was done and thinks it was all done correctly.
It is often ambiguous when making the decision but a good engineer should absolutely be able to determine what were right and wrong decisions with hindsight. Yes, even with the benefit of hindsight there may be some ambiguity, but let's be real
If you are a leading engineer and you cannot do a postmortem on a project to determine what decisions were likely good and what ones were likely bad, then you shouldn't be a leading engineer
Why does it feel bad? Everyone wants to be right more often. All else equal, we'd like the people we work with to be right more often than wrong.
Here are some statements that don't feel as bad to say for some reason (not endorsing these per se, just they dont feel bad to say):
- good engineers are pleasant to work with
- good engineers are practical
- good engineers know a lot about engineering
Here are some statements that start to feel weirder to me:
- good engineers have high IQs
- good engineers are uncompromising
- good engineers know that lisp is the best language
- good engineers are right a lot
Maybe it has something to do with the ratio of how easy it is to verify the property, with how hard it is to embody the property once you hear about it.
Having a high IQ is kinda hard to verify directly. If that was a widely known phrase, everyone would just claim they had the high IQ. Same with being right: you can just claim you're right a lot. Being uncompromising is easy, just don't compromise.
Being practical is hard to do, but maybe is easy to claim? Maybe it's easier to verify if someone is practical than if someone is smart. Not sure. Being pleasant tonwork woth is hard work maybe? Maybe there's just a social confluence bias.
No it isn't. You literally just give them an IQ test. That costs at most 2 hours and maybe $150 at most.
Ironically, having a high IQ is a much more easily verifiable claim than any of the other claims on your list ("pleasant to work with", "practical" etc)
Because the whole thing of those tests is to test intelligence, not knowledge. And the older you are, the more knowledge you got.
When I was like 7, I passed an IQ test. I did it again, for fun, at 30yo. I then noticed things that I now know: for instance, XOR (as in the boolean operation).
When I did it at 7yo, I had to understand XOR. When I was 30yo, I had time to learn XOR.
Doing IQ tests for adult is how you have people with 165 IQ everywhere. What a joke.
I am still wondering over all these years if this is the test or if this is me :)
Good engineers know that readability counts.
Good design comes from good designers
(Fred Brooks)
It's also not about confidence. You can be confidently wrong.
Being silent is mostly useless. If you sit through a whole meeting without saying a word you didn't contribute at all. I don't want colleagues who don't contribute.
I want colleagues who respectfully chime in when they know something the rest of us don't, that's also the colleague I try to be. It happens quite frequently that I'm in a meeting where the consensus among my colleagues is gravitating towards something that isn't correct. So then I chime in explaining why I think this is the wrong thing to focus on or why this idea won't work or maybe I have an idea I think is more likely to achieve the result we want.
I'm not going to push it or argue, people are allowed to disagree with me. I really appreciate it when people explain how I'm wrong but if they just ignore my advice I won't make a stink about that either.
People who talk just to talk are not just useless, but drag for everyone else. There is nothing valuable about weighting into everything.
People who have strong opinions on stuff they know little about are also causing harm.
I used to be work with a software architect on a sizable team who spoke less than most others. But when he did speak, it was like the old commercial about E.F. Hutton- everyone listened. If one of us were having a personal conversation with him, he spent most of the time listening. Before he did speak, there would be frequently be some silence as he thoughtfully considered what to say and then he would respond with few words, carefully thought out, intelligent, and wise. He worked on the hardest problems we had, and he was one of the few oracles that the directors, seniors, and leads would go to for advice.
He has been a strong role model for the close to twenty years since I last worked with him, though I struggle and fail every day to come anywhere close.
I'm not saying people should blabber on about anything, I'm just saying they should speak up when they have something important to say.
And if you never have anything important to say then why are you there? Either you dont know anything your colleagues don't know which makes you the least useful person on the team or you just don't care which also makes you useless.
I can sympathize with people who get jaded from working in places where nobody listens and the people in charge are morons, but if that's you then why are you still there?
Good engineers are right a lot very specifically within their technical competency.
Simply saying "good engineers are right a lot" has pretty clearly resulted in a large group of people who think that because they're right a lot about things within their field, that quality of 'being right a lot' extends to things outside of their field, and that is terribly wrong as often as not. The hubris and entitlement that I've seen engendered in people who take this creed too seriously is really something to behold. It's part of what directly leads to the 'techbro' stereotype.
No, Kyle, just because you're right a lot about all things relating to Rust does NOT mean you know a fucking thing about economics, healthcare, or whatever the hell else it is you espouse your strongly held opinion on.
If someone is right a lot they are likely not making assertions about things that they know nothing about.
If they are making assertions about a domain and those assertions are correct then that domain is one of their competencies.
"Utterly useless" is a bit extreme but it's a reasonable observation to say it doesn't have predictive power.
It’s the whole circle jerk about STEM being the ultimate degree fields in university, while humanities and liberal arts are looked down upon and sneered at.
The humanities is a lot of nonsense. And any STEM student can read a humanity study and understand it and write a valid critique. The opposite is definitely not the case.
STEM students are just better at modelling than non-STEM (on a whole).
As for programmers. I’ve met several who only work in a specific industry for a few years. They have no problems moving to a new industry and within 6 months they understand the new domain and can model that accurately as well.
I have not once met a marketing or hr guy who was able to model anything, let alone a different domain.
Physicists are stereotypically famous for misjudging expertise decay. https://xkcd.com/793/ Some things, like deep intellectual humility, do seem to consistently transfer well between fields. Being "right, a lot", not so consistently.
On engineering matters perhaps, but not on all topics.
Perhaps we can refine the principle even more "Good engineers are good leaders" since many of the world's top companies' CEO are engineers [1].
As excellent examples Amazon's CEO and CTO for a very long time are engineers. Werner Vorgels was the PhD student of Prof. Tanembaum with that authored popular OS and Computer Networks textbooks.
[1] Top CEOs have this degree:
So in retrospect they’re “right a lot” because they actively seek to align themselves with reality and therefore are better able to predict the outcomes of their work.
That doesn't mean your code works the first time, just that it works eventually because you were right about the issue and how to deal with it.
The other 2-4% is the interesting stuff IMO. Being wrong is fun, that means you get to learn something.
How much am I deluding myself?
- forgetting wrong predictions
- tweaking your predictions after the fact to be more correct
- only making predictions you are relatively sure of
The real difference is whether you can do it on command, or only when you feel like it. In the second case, it's less of a prediction, and more of a roundabout way your brain tells you that you know something.
But a manager wouldn't know right vs wrong if they themselves are not skilled enough - and thus managers should not be spending time judging and evaluating people
The job of management is NOT to sit around and rate their reports. That much can be done by chatGPT.
I'm sort of reminded of steve jobs' technique of figuring out if an engineer is good or not. He says to the engineer's coworkers - I hear so-and-so is shit. If they don't say much, he might not be that bad, but if they vigorously defend him, he might actually be ok. It is hard to tease out strong opinions from quiet but decent people.
leaders might statistically be less quiet or unopinionated.
In the same way I wonder if you need to listen to engineers in the right way. like if they say something is "non-trivial" it might not be worth pursuing. And if you keep pushing for an idea and they get an uncomfortable looks in their eyes, you might want to take notice.
It is sad that such assholes attract similar people in their direct entourage and we end up with utterly toxic management teams.
uhhhh. You sure about that? I'm not entirely convinced that the ide and the colour scheme make the dev. Sure, some of the most productive devs extensively use hotkeys and certain ides but I know of many devs that do those things and have incredible draw backs. One guy I know is a great dev but often misses the performance forest for the trees. The poor lad super optimised a process that was still painfully slow because it was doing a stupid thing (loading way more data than it needed at that time). It was stupid and all he achieved was doing a stupid thing incredibly quickly.
I say tough shit, fire the less technical people, and do more with less. Qualifying your statements is absolutely vital to not being thrown under the bus by certain types of "bad leaders" who are smart despite being almost never right about anything. They know how to cover their ass and deflect blame. People who qualify what they say are the same people who write fewer bugs.
> do a high volume of work in a single area for a long time, so you gain deep familiarity
I agree that what matters most is having experience and most people don't seek it actively enough so we end up with this mess.
Someone is trying to learn something from you and you give them an answer so full of holes and caveats that it looks like fishnet stockings, you haven't imparted any confidence to them in your answer.
Also, caveats are valuable information. Yes, we can go live next week if the number of users remains under x until we complete z. Clear communication empowers decision makers. Intentionally omitting trade-offs and limitations that are relevant means you’re being misleading.
Of Have you ever kissed a girl? fame[0].
0. https://www.osnews.com/story/28261/have-you-ever-kissed-a-gi...