4 ms·

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 descri

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.
- somethoughts 4y ago
  >> 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.
- bigfishrunning 4y ago
  > 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.
seadan83 4y ago
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)
- somethoughts 4y ago
  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.
- 411111111111111 4y ago
  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

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.

somethoughts 4y ago
>> 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.
bigfishrunning 4y ago
> 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.

seadan83 4y ago

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)

somethoughts 4y ago
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.
411111111111111 4y ago
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