Good engineers are right, a lot(seangoedecke.com)
seangoedecke.com
Good engineers are right, a lot
https://www.seangoedecke.com/being-right-a-lot/
65 comments
The main problem I see is that the people who get those leadership positions are usually the ones who like to overcomplicate/over-abstract things a lot.
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.
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.
I don’t get why our profession is so prone to this. From what I’ve seen, actual engineers and people working in the trades have a “pick the right tool for the job” approach. At least the ones that haven’t been co-opted into becoming vendors for some large company.
Because software engineering isn't engineering, isn't taught like engineering, doesn't come with the responsibility that engineers have, doesn't come with the barriers that engineering does, refuses to take itself seriously as an engineering discipline, refuses to organize in any way that would be required if we WANTED to enforce engineering best practices, etc.
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.
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.
From what I hear in other engineering industries (software engineering is engineering) it is more like people just stick with what they know because it can take 5-50 years for a new technique/tool that is significantly better to show up.
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.
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.
Yeah. Structural engineering is probably a good example of this. For any one component (a beam, an anchor, etc.) There might be a dozen or more solutions that would work. The engineer of record (the one in responsible charge) absolutely SHOULD pick the one they are most familiar with. (Different options may have totally different analysis methods) This reduces the cognitive overhead allowing them to focus on other aspects of the design, and reduces the likelihood of making analysis errors.
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.
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.
Programming is basically expressing your thoughts in extreme detail. The medium you do it through matters to you. Very few other professions are encoding their actual thoughts.
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.
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.
I am an amateur developer (my own stuff and open source) and I always pick the same stack when writing something. This is because I found the optimal, third-best stack that pretty much fits everywhere with minimal friction.
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.
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.
Lack of official standards, lack of certifications (not everywhere thankfully), and the relative youth of software as a profession all lead to a bit of a "will wild west" industry. I don't fault the developers themselves mind you, but it will take time (probably a few decades) for things to settle.
I couldn't agree more.
The good ol' "fine, I'll do it myself".
Reluctant leaders are some of the best. They're there to get things done and rarely overstep their area of competence.
Reluctant leaders are some of the best. They're there to get things done and rarely overstep their area of competence.
This implies that you can look back at a product with all its nuance and say "that was done right" or "that was done wrong". Most of the time it is ambiguous as far as if the chosen approach was the right one. You can't tell if you faced more hurdles and unseen challenges with the chosen path then if you had gone with a different approach, because it is impossible to predict unknown challenges.
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.
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.
> This implies that you can look back at a product with all its nuance and say "that was done right" or "that was done wrong". Most of the time it is ambiguous as far as if the chosen approach was the right one
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
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
The "good engineers are right a lot" is true, but it feels bad to say.
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.
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.
> Having a high IQ is kinda hard to verify directly.
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)
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)
The older you are, the more useless are IQ tests
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.
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.
[deleted]
I worked in two companies who did IQ tests for hiring, the people in those companies were very knowledgeable engineers. Not necessarily good engineers, but they knew their shit. Being cracked at something doesn't make you a good engineer by itself, but it did skew the average up.
That is -- it's hard for one to directly verify the IQ of a peer besides submitting them to an IQ test, since we're trying to assess whether an engineering peer is good by means of some proxy.
All my IQ tests show results between a chair and a fly. The testers were horrified, and so I was.
I am still wondering over all these years if this is the test or if this is me :)
I am still wondering over all these years if this is the test or if this is me :)
> good engineers know that lisp is the best language
Good engineers know that readability counts.
Good engineers know that readability counts.
Don’t forget:
Good design comes from good designers
(Fred Brooks)
Good design comes from good designers
(Fred Brooks)
It irks me to no end when developers assume that staying silent or non-committal is a sin. Wise developers are often silent, as they know what they don’t know. And I’d much rather work with someone I like who is willing to say they’re wrong than with someone highly confident that must win arguments.
It's clearly not about that. You can win an argument without being right, the phrase is not win lots of arguments.
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.
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.
> If you sit through a whole meeting without saying a word you didn't contribute at all.
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 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.
Sounds like a great guy. I'm definitely not saying people should talk more than necessary. I generally don't talk much in meetings either unless I'm leading them or if I'm some kind of authority on the given subject like if it's a meeting about an app I am responsible for.
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?
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?
> 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.
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.
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.
Completely agree.
This sentiment is so incomplete as to be utterly useless outside of a very narrow scope.
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.
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.
I don't think that is incompatible at all. It's a restatement of the same thing:
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.
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.
I suggest people badly underestimate how very rapidly expertise falls of as one moves away from a specific tightly-scoped feedback-intensive area of skill. Ask a wizzy quantum chemist a protein chemistry question, and don't be surprised to get the answer of a grad or undergrad student. There's a news genre of "Harvard MBA's don't understand seasons!"-like stories - if someone last saw something years ago in middle school, don't be surprised now by a middle schooler's understanding. A person can both be a highly-regarded <model organism> researcher, and have gone rather nutter on <diet thing> that very isn't their research area.
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.
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.
That’s never been my observation. Tech people are some of the most arrogant people I’ve encountered, often asserting things outside of their domain. The delusion that being right in one area makes them right in other areas is real.
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.
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.
I’ve studied both STEM and humanities.
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.
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.
I assume you meant this is a rebuttal of the parent comment. It's interesting that it could just as well be seen as confirmation.
Funnely enough I was nodding to parent post until I read your answer and was abit emberrased. I got a bad case of STEM hubris too. The STM can go home though.
How you see it depends on how highly you think of non-STEM work, I guess - but I will say anecdotally that the folks who were good at math/science when I was in school also seemed to be solidly above average at English.
I wish those sorts of people would realize that they are showing their whole ass when they act like that. Only the deeply insecure mask their ignorance with arrogance. We can hear your thoughts and feel your motivations.
It is actually very easy to correctly assert certain statements outside of your domain as long as the domain you are butting in on is obviously fraudulent, pseudoscientific, full of charlatans, practitioners don't have any skin in the game, is almost entirely funded by political money (and wouldn't be funded otherwise), or is heavily based on some sort of mysticism, and I'm sure this isn't an exhaustive list. Turns out that is a lot of domains of human activity.
I'm reminded of the quote "he knows everything, but that is also all he knows".
[deleted]
> Good engineers are right, a lot.
On engineering matters perhaps, but not on all topics.
On engineering matters perhaps, but not on all topics.
>Amazon infamously has a leadership principle where they say “good leaders are right, a lot”.
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:
https://news.ycombinator.com/item?id=39680308
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:
https://news.ycombinator.com/item?id=39680308
The way it was explained to me when I was at Amazon is that the intent of that principle is that good leaders should “make themselves correct” by gathering the data they need to have well informed judgement.
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.
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.
SWAG: you should be right > 96%-98% of the time if you're good.
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.
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.
This kindles a thought I've harbored for a long time: that I should be tracking my predictions. About everything. Because I feel I'm pretty good about predictions.
How much am I deluding myself?
How much am I deluding myself?
Probably the normal amount, by:
- 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.
- 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.
Try it. I predict you'll be right less often than you'd like, but probably more often than the median popular, it's just you need some way to track how often _other_ people are right as well.
Aren't that just design docs ;D
In some ways yes! I frequently update design docs to include what I learned.
> Good engineers are right, a lot
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
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
That is literally the entirety of a manager’s job: judging and evaluating people they manage.
No. The job of a manager is being aligned with the company, identifying the right initiatives to work on, allocating resources to said initiatives, and relentlessly working to unblock their reports.
The job of management is NOT to sit around and rate their reports. That much can be done by chatGPT.
The job of management is NOT to sit around and rate their reports. That much can be done by chatGPT.
more like the least important part of a manager's job
...if you listen.
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.
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.
Looks like he was a manipulative asshole. The kind of boss I despise so much that even if was in the process of inventing a universal cure for cancer I could not work with him.
It is sad that such assholes attract similar people in their direct entourage and we end up with utterly toxic management teams.
It is sad that such assholes attract similar people in their direct entourage and we end up with utterly toxic management teams.
> You can assess an engineer based on how smart they sound in conversation, whether they use light mode VSCode or dark mode vim
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.
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.
The point the author is trying to make is that those are indeed not the right traits to judge an engineer by.
> qualifying all your statements makes it very hard for less technical people to work with you
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.
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.
Less technical here doesn't neccesarily mean "worse engineers". It can also mean lawyers, marketing, sales, product, and leadership.
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.
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.
When someone asks you if you can commit to delivery in the upcoming sprint, they aren’t trying to learn from you.
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.
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.
Their confidence is not my concern to babysit. You're essentially asking engineers to lie and take blame.
Yeah, it’s one of my favourite Amazon principles. It’s not enough to always be learning. At some point, you’re at the Olympics and it doesn’t help to be learning.
>Bryan Cantrill
Of Have you ever kissed a girl? fame[0].
0. https://www.osnews.com/story/28261/have-you-ever-kissed-a-gi...
Of Have you ever kissed a girl? fame[0].
0. https://www.osnews.com/story/28261/have-you-ever-kissed-a-gi...
Continue to learn and grow in knowledge while maintaining self-awareness about what you truly know and what you don't.