6 ms·

As others have noted, part of the problem here is that the engineers in question are actually not yet smart enough. It usually takes substantial experience to

As others have noted, part of the problem here is that the engineers in question are actually not yet smart enough. It usually takes substantial experience to identify simpler, more-maintainable ways to meet challenging performance goals. If you are not fortunate enough to have a veteran engineer who can lead the way in pushing back against unnecessary complexity, you'll want to try to grow your own. This requires some luck, but there definitely are things you can do to help the process along. In particular, I recommend allowing some probably-unnecessary complexity -- I'd expect your engineers to innovate less and learn at a slower rate if you try too hard to stamp this out -- but be strategic in where you allow it. Software that is already load-bearing for your business should be subject to higher standards. Set an expectation that stable functionality becomes easier rather than harder to work with over time. When the backend has to become more complex to achieve performance goals, ask your engineers to do their best to encapsulate that complexity, and keep the higher-level interfaces simple.

neilv 4y ago
> As others have noted, part of the problem here is that the engineers in question are actually not yet smart enough. Yes, and more a matter of experience. CS departments might not introduce this well, and the current Leetcode interview prep demands send mostly the wrong messages to students about what's important to learn about team software engineering. One good way to learn this is to stay on a project long enough for the chickens to come home to roost. A better way is mentoring from people with battle scars. Or at least peer feedback from people who've heard not to climb the ladder to get the bananas (even if they don't have firsthand experience with why, nor an intuition for when the rules should be broken).
alexchantavy 4y ago
I like the word “load bearing” here applied to software and business; it’s a good metaphor
- atoav 4y ago
  "Don't remove Bob, he is a load bearing engineer"
somethoughts 4y ago
I'd advocate that you make a bus factor [1] spreadsheet. In the first column list every feature of your system - row by row - with a fairly identifiable description. List the current owner of the code supporting each feature next to the description Then create columns with each engineers name on it. Then ask each engineer to color code each cell in their column based on their ability to support the feature. Green - Understand the code and could support 24/7 pager duty on it Yellow - Could probably grok the code after a month and then start supporting 24/7 pager duty on it Red - Won't ever support that part of the code cuz its a mess The presumption is that each engineer will be marking green for their features - so they will get 1 point. If an engineer signs up for another persons feature, they get 2 points for marking it green, 1 point for marking it yellow and 0 points for marking it red. Tally up the points in each column and let the engineers compare themselves. Ideally each row will have at least 2 cells marked in green. Such a spreadsheet will definitely help guide the engineers to write more supportable code as if they don't it will be apparent that their rows are visibly red. It also gives the engineers a reason/reward for delving into Other People's Projects/code (I like to call it OPP). Share the spreadsheet with the product management teams and engineering management - particularly as they are proposing new features as it can help show that their fancy new feature requests of the month are generating a high amount of bus factor. [1] https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor
- yowlingcat 4y ago
  This is a great exercise because it gets into the practicalities of engineering being a /team sport/ not a /solo sport/. Many otherwise strong engineers who have developed strong muscles for solo engineering get into trouble when those "big muscles" aren't trained to the same degree the "stabilizer muscles" are. And so when they need to optimize for flexibility or applied "mental strength" they can do things that hurt themselves or those around them. It's important to give them the tools to understand the additional constraints on the problems they are trying to solve, and moreover, to empower them to take responsibility for the struggles of the team, and not just their own struggles. That way, it's not a "me vs them" dynamic. Additionally and more critically, if they struggle with this exercise, it will make it very clear where they need more mentorship. For what it's worth, having these strong "stabilizer" muscles alongside "big" muscles instead of just "big" muscles in and of themselves is, in my book, what separates a strong mid level engineer from a strong senior engineer and beyond.
throwaway0asd 4y ago
> As others have noted, part of the problem here is that the engineers in question are actually not yet smart enough. That is highly subjective and purely a result of both perspective and bias. While you can point fingers to say that someone is not yet smart enough they are likely pointing a finger back at you and claiming the same. The only solution for something like Dunning-Kruger is humility. The only solution to find the best solution (objectively) to any criteria is by comparing measurements. The actual problem is that almost nobody measures things, because the effort is too great. Instead most people will compensate for their lack of measures with a hearty dose of confidence. There are people who sell confidence for a living, such as salesmen and pundits. That is highly appealing to people who lack the necessary critical nature to ask the right questions or apply the smallest amount of doubt.
- yowlingcat 4y ago
  Hard disagree. Perhaps "not smart enough" is too strong a statement but "not capable enough" is certainly correct. Spend enough time in this industry and you'll find plenty of folks who can work well in a vacuum but cannot actually be strong both independently and working in a group setting. The latter has a lot of concrete details attached to it which has nothing to do with either perspective or bias. Ironically, you're applying an accusation of "perspective and bias" with a very sloppy brush of perspective and bias.
  - throwaway0asd 4y ago
    > Spend enough time in this industry… I have 20 years in this industry. It’s full of stupid people pointing fingers somewhere else. Any time this is pointed out developers play the special snowflake game and pretend that software is something special or unique, but it isn’t. Everything is measurable just like any other industry.
    - deleted 4y ago
      [deleted]
    - yowlingcat 4y ago
b20000 4y ago
don’t confuse smart with experienced interviews do not currently optimize for hiring experienced people but rather people willing to grind leetcode
jl2718 4y ago
You don’t know that. It was my initial thought too, but further reading suggests possibility of good reasons for changes. OP may be missing something.
atoav 4y ago
I don't think this is necessarily a sign of them not being smart. I mean it could be, but it could also not be. What it is a sign of is that their incentive structures (their motivation) do not align 100% with those of the project. They might be more interested to learn and try new stuff, than to find the most maintainable, simple and elegant solution for example. This does not make them less smart. And just because the participant's goals do not align with the project goals does not mean that this is bad. Such a project just needs someone who is aware of those individual goals and tries to defend the project against them while offering them sufficent opportunities to stay motivated.
deterministic 4y ago
You are absolutely correct. Being “smart” is not enough. The way I think about it is: Competency = IQ * Experience This is why you will often see less intelligent but more experienced developers outperform higher IQ less experienced developers. And why high IQ developers with 30 years of experience in many different software development areas are so valuable to a company/team.

neilv 4y ago

> As others have noted, part of the problem here is that the engineers in question are actually not yet smart enough. Yes, and more a matter of experience. CS departments might not introduce this well, and the current Leetcode interview prep demands send mostly the wrong messages to students about what's important to learn about team software engineering. One good way to learn this is to stay on a project long enough for the chickens to come home to roost. A better way is mentoring from people with battle scars. Or at least peer feedback from people who've heard not to climb the ladder to get the bananas (even if they don't have firsthand experience with why, nor an intuition for when the rules should be broken).

alexchantavy 4y ago

I like the word “load bearing” here applied to software and business; it’s a good metaphor

atoav 4y ago
"Don't remove Bob, he is a load bearing engineer"

somethoughts 4y ago

I'd advocate that you make a bus factor [1] spreadsheet. In the first column list every feature of your system - row by row - with a fairly identifiable description. List the current owner of the code supporting each feature next to the description Then create columns with each engineers name on it. Then ask each engineer to color code each cell in their column based on their ability to support the feature. Green - Understand the code and could support 24/7 pager duty on it Yellow - Could probably grok the code after a month and then start supporting 24/7 pager duty on it Red - Won't ever support that part of the code cuz its a mess The presumption is that each engineer will be marking green for their features - so they will get 1 point. If an engineer signs up for another persons feature, they get 2 points for marking it green, 1 point for marking it yellow and 0 points for marking it red. Tally up the points in each column and let the engineers compare themselves. Ideally each row will have at least 2 cells marked in green. Such a spreadsheet will definitely help guide the engineers to write more supportable code as if they don't it will be apparent that their rows are visibly red. It also gives the engineers a reason/reward for delving into Other People's Projects/code (I like to call it OPP). Share the spreadsheet with the product management teams and engineering management - particularly as they are proposing new features as it can help show that their fancy new feature requests of the month are generating a high amount of bus factor. [1] https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor

yowlingcat 4y ago
This is a great exercise because it gets into the practicalities of engineering being a /team sport/ not a /solo sport/. Many otherwise strong engineers who have developed strong muscles for solo engineering get into trouble when those "big muscles" aren't trained to the same degree the "stabilizer muscles" are. And so when they need to optimize for flexibility or applied "mental strength" they can do things that hurt themselves or those around them. It's important to give them the tools to understand the additional constraints on the problems they are trying to solve, and moreover, to empower them to take responsibility for the struggles of the team, and not just their own struggles. That way, it's not a "me vs them" dynamic. Additionally and more critically, if they struggle with this exercise, it will make it very clear where they need more mentorship. For what it's worth, having these strong "stabilizer" muscles alongside "big" muscles instead of just "big" muscles in and of themselves is, in my book, what separates a strong mid level engineer from a strong senior engineer and beyond.

throwaway0asd 4y ago

> As others have noted, part of the problem here is that the engineers in question are actually not yet smart enough. That is highly subjective and purely a result of both perspective and bias. While you can point fingers to say that someone is not yet smart enough they are likely pointing a finger back at you and claiming the same. The only solution for something like Dunning-Kruger is humility. The only solution to find the best solution (objectively) to any criteria is by comparing measurements. The actual problem is that almost nobody measures things, because the effort is too great. Instead most people will compensate for their lack of measures with a hearty dose of confidence. There are people who sell confidence for a living, such as salesmen and pundits. That is highly appealing to people who lack the necessary critical nature to ask the right questions or apply the smallest amount of doubt.

yowlingcat 4y ago
Hard disagree. Perhaps "not smart enough" is too strong a statement but "not capable enough" is certainly correct. Spend enough time in this industry and you'll find plenty of folks who can work well in a vacuum but cannot actually be strong both independently and working in a group setting. The latter has a lot of concrete details attached to it which has nothing to do with either perspective or bias. Ironically, you're applying an accusation of "perspective and bias" with a very sloppy brush of perspective and bias.
- throwaway0asd 4y ago
  > Spend enough time in this industry… I have 20 years in this industry. It’s full of stupid people pointing fingers somewhere else. Any time this is pointed out developers play the special snowflake game and pretend that software is something special or unique, but it isn’t. Everything is measurable just like any other industry.
  - deleted 4y ago
    [deleted]
  - yowlingcat 4y ago

b20000 4y ago

don’t confuse smart with experienced interviews do not currently optimize for hiring experienced people but rather people willing to grind leetcode

jl2718 4y ago

You don’t know that. It was my initial thought too, but further reading suggests possibility of good reasons for changes. OP may be missing something.

atoav 4y ago

I don't think this is necessarily a sign of them not being smart. I mean it could be, but it could also not be. What it is a sign of is that their incentive structures (their motivation) do not align 100% with those of the project. They might be more interested to learn and try new stuff, than to find the most maintainable, simple and elegant solution for example. This does not make them less smart. And just because the participant's goals do not align with the project goals does not mean that this is bad. Such a project just needs someone who is aware of those individual goals and tries to defend the project against them while offering them sufficent opportunities to stay motivated.

deterministic 4y ago

You are absolutely correct. Being “smart” is not enough. The way I think about it is: Competency = IQ * Experience This is why you will often see less intelligent but more experienced developers outperform higher IQ less experienced developers. And why high IQ developers with 30 years of experience in many different software development areas are so valuable to a company/team.