Hacker News Reader

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

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.

>> That way, it's not a "me vs them" dynamic.

Yes - definitely helps in scenarios where an engineer starts talking directly to a product manager/non technical management and starts accepting feature requests and cranks them out with little thought about the long term supportability of their code by the rest of the team (and perhaps builds in a little extra job security intentionally or unintentionally via code obfuscation) and is reward by looking like a 10x engineer to the non-technical side of the company.

Rows of red next to their name will organically slow the engineer down and encourages less code that feels like "job security through obfuscation/abstraction" and long term will guide them toward soliciting more feedback from the team early on in the design cycle to ensure their code is grok-able enough to get green marks. Then they can truly by identified as a legit 10x'er.

> This is a great exercise because it gets into the practicalities of engineering being a /team sport/ not a /solo sport/.

The problem there is that, for many teams, there are 1 or 2 engineers holding water for a couple dozen people. the other ~20 people have no incentive to get better or take on more work because "Bob will just fix it". In this case, for Bob, it really is a solo sport.

That sounds like an interesting exercise. I would like to know about the 'red cell' scenario. Could you give examples of when someone would color a cell red?

My trouble is, a month is a super long time. So long as we are talking features, how messy does something have to be for someone to be unwilling to touch it (after a month)?

Could it make sense to simplify this and merge yellow and red together? Or change the definition of yellow to be 4 hours of code grokking (which would mean if I were paged, i could resolve the issue, but it'll take all night rather than knowing exactly where the problem is within 20 minutes)

Thanks! Definitely just made all of this spreadsheet up so feel free to modify to suit your team specifics.

As the generator of the spreadsheet I may have marked up the spreadsheet for myself as red for stuff I didn't understand but wanted/needed to understand - to reduce team bus factor - in order to show non-technical management what I wanted to spend time on to close the gaps. I also filled out some other team members' column and based on discussions would mark theirs as red.

I think the context of a month for yellow was "it would take a month to proactively grok the code (prior to any systems down/bug triage) as a 20% activity on top of other ongoing activities (stand-ups, your existing OKRs, support requests)" - so like 1 day a week dedicated to sitting down to grok Other People's Projects.

And now that you mention it - I might have said 2 weeks when I original shared the spreadsheet - so 16 hours to go from yellow->green.

Also important is to take snapshots periodically to encourage/reward improvements to making the spreadsheet red -> green.

A good work output to demonstrate a red->green transition is 1-2 small feature/bug fixes to a feature and/or a documentation update.

Well, i can think of at least one previous situation in which i'd not be confident in changing anything about it even after a month.

It happens when you're uncertain if what you're changing is going to break something that doesn't have explicit coverage or is mocked to a degree that the proposed changeset wouldn't cause the tests to fail.

I remember a company that had a spelling mistake in a central location of their code. When this spelling mistake was corrected, errors started to pop up days, weeks and months later forcing a revert of this correction several times.

So yeah, these things exist

> 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).

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.

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

"Don't remove Bob, he is a load bearing engineer"

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.

don’t confuse smart with experienced

interviews do not currently optimize for hiring experienced people but rather people willing to grind leetcode

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.

> 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.

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.

> 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.

What have you accomplished in your 20 years in the industry, out of curiosity?

I have written the fastest network transmission implementation for Node.js and made the front page of HN (under a different account) for creating an original diff algorithm among various other things. While I was doing that I was also holding a part time job in middle management in an unrelated industry. This original software wasn’t written by whining and blaming people for my sadness.

Note that my advice, if followed, has the effect of giving the OP's engineers more space to develop efficient implementations than they would probably get if OP acts on their instincts.

This is not a coincidence. If you look at my own public work at e.g. https://github.com/chrchang/plink-ng/tree/master/2.0/ and https://github.com/grailbio/base/tree/master/simd , you can see that I play the role of the "not yet smart enough" engineer, not the manager.