3 ms·

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 ha

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.

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.