3 ms·

I have an issue with number 4, promoting the most prolific engineers. Lets take two new engineers. One just cranks out code and it looks like he is the most p

by rmason 4y ago

I have an issue with number 4, promoting the most prolific engineers. Lets take two new engineers. One just cranks out code and it looks like he is the most productive employee. Even if he does a lot of cutting and pasting. The other engineer takes his time but when he releases something there are never any bugs. Plus his UI's are a thing of absolute beauty. The other programmers are always asking him for help which slows his production further. Management rarely considers the true cost of bugs, not just the cost of fixing them but higher customer churn. Funny how the first engineer gets the promotion and now he also becomes a sub-par leader. Suddenly the startup starts losing programmers as well because they don't respect their bosses decisions. Now the guy hires more coders just like him. The startup stalls and management is befuddled because so many lines of code are being written.

brador 4y ago
Commits is measurable, beauty and bug freeness is subjective.
- ploppyploppy 4y ago
  > bug freeness is subjective No.
api 4y ago
This problem isn't new either: https://en.wiktionary.org/wiki/KLOC https://en.wiktionary.org/wiki/KLOC
lofatdairy 4y ago
I think the point doesn't stand up to close scrutiny, but taking into consideration that the actual implementation of this action-reward feedback loop is probably more nuanced, it makes a bit more sense[^1]. Obviously, you don't want someone pumping out nothing but garbage commits and forcing it onto the production branch, but at the same time you really can't afford perfectionists who spend all their time stressing about a fractal infinity of possibilities containing other possibilities. Furthermore, in a startup environment a dev moving slowly because they're busy helping other devs can lead to the obfuscation of management issues. If a dev looks more 2X capable than they actually are because they're using up half the time of a 10X dev, then you really should be assigning the less capable dev a lighter workload where they're less likely to block things. Bugs obviously can spiral into more time and time spent early can avoid timesinks and various issues down the line. I completely agree that spending a day to prevent an issue causing weeks to months of headaches is completely worth it (and to add to your point, I lost all respect for management when perfectly foreseeable issues weren't addressed, especially when I requested resources to address the issue). This is probably where the nuance is lost, where you need to have checks and balances in place to ensure that critical decisions are being made by the right people, and that guardrails exist so that devs can move quickly without stepping on anyone's toes. [^1]: While Dan Luu's statement that nuance doesn't scale isn't entirely applicable, there's a similar effect here where nuance is sacrificed for a punchy, memorable aphorism. I personally don't agree with sacrificing nuance for more base appeal, but we can maybe also take for granted that readers have some capacity for critical thought (and the ones that blindly accept this advice won't hurt too many people when they inevitably fail spectacularly).
ransom1538 4y ago
"The other engineer takes his time but when he releases something there are never any bugs." Ah yes that guy. The person super worried about quality at a startup doing "uber for cats". Avoiding bugs at all costs, meetings, deep unit testing, always rolling their eyes at "bad code". "Funny how the first engineer gets the promotion and now he also becomes a sub-par leader." Not really at a startup. You are testing if an idea even "works" - why in god would you start worrying about quality. Bring the product to life, get feed back fast. Your quality slow churning code could be in the wrong direction. People that write deep quality code generally protect it, shine it, rub it. Good luck explaining to this guy this isn't 'what we want'. What is worse than bad code? Good code never used.
- winrid 4y ago
  You don't have to be a startup to follow this philosophy! Seems like every app I use is riddled with bugs :) Come on Asana, let me change task dates and sort correctly. What kind of TODO app doesn't reliably save dates...
deleted 4y ago
[deleted]
renewiltord 4y ago
This kind of story is the pulp romance novel of the engineering audience.
andrewjl 4y ago
> The other engineer takes his time but when he releases something there are never any bugs. In fairness a good portion of startups do not benefit from this in the beginning. Releasing the right albeit buggy thing is far more important than vice versa. Later on or if operating in a less forgiving industry this becomes a different story obviously.
amboo7 4y ago
The forgotten Fibonacci law of hiring: only 1st class people hire 1st class people (but also some 2nd class people), 2nd class people only hire 3rd class people, etc.

by rmason 4y ago

brador 4y ago

Commits is measurable, beauty and bug freeness is subjective.

ploppyploppy 4y ago
> bug freeness is subjective No.

api 4y ago

This problem isn't new either: https://en.wiktionary.org/wiki/KLOC https://en.wiktionary.org/wiki/KLOC

lofatdairy 4y ago

I think the point doesn't stand up to close scrutiny, but taking into consideration that the actual implementation of this action-reward feedback loop is probably more nuanced, it makes a bit more sense[^1]. Obviously, you don't want someone pumping out nothing but garbage commits and forcing it onto the production branch, but at the same time you really can't afford perfectionists who spend all their time stressing about a fractal infinity of possibilities containing other possibilities. Furthermore, in a startup environment a dev moving slowly because they're busy helping other devs can lead to the obfuscation of management issues. If a dev looks more 2X capable than they actually are because they're using up half the time of a 10X dev, then you really should be assigning the less capable dev a lighter workload where they're less likely to block things. Bugs obviously can spiral into more time and time spent early can avoid timesinks and various issues down the line. I completely agree that spending a day to prevent an issue causing weeks to months of headaches is completely worth it (and to add to your point, I lost all respect for management when perfectly foreseeable issues weren't addressed, especially when I requested resources to address the issue). This is probably where the nuance is lost, where you need to have checks and balances in place to ensure that critical decisions are being made by the right people, and that guardrails exist so that devs can move quickly without stepping on anyone's toes. [^1]: While Dan Luu's statement that nuance doesn't scale isn't entirely applicable, there's a similar effect here where nuance is sacrificed for a punchy, memorable aphorism. I personally don't agree with sacrificing nuance for more base appeal, but we can maybe also take for granted that readers have some capacity for critical thought (and the ones that blindly accept this advice won't hurt too many people when they inevitably fail spectacularly).

ransom1538 4y ago

"The other engineer takes his time but when he releases something there are never any bugs." Ah yes that guy. The person super worried about quality at a startup doing "uber for cats". Avoiding bugs at all costs, meetings, deep unit testing, always rolling their eyes at "bad code". "Funny how the first engineer gets the promotion and now he also becomes a sub-par leader." Not really at a startup. You are testing if an idea even "works" - why in god would you start worrying about quality. Bring the product to life, get feed back fast. Your quality slow churning code could be in the wrong direction. People that write deep quality code generally protect it, shine it, rub it. Good luck explaining to this guy this isn't 'what we want'. What is worse than bad code? Good code never used.

winrid 4y ago
You don't have to be a startup to follow this philosophy! Seems like every app I use is riddled with bugs :) Come on Asana, let me change task dates and sort correctly. What kind of TODO app doesn't reliably save dates...

deleted 4y ago

[deleted]

renewiltord 4y ago

This kind of story is the pulp romance novel of the engineering audience.

andrewjl 4y ago

> The other engineer takes his time but when he releases something there are never any bugs. In fairness a good portion of startups do not benefit from this in the beginning. Releasing the right albeit buggy thing is far more important than vice versa. Later on or if operating in a less forgiving industry this becomes a different story obviously.

amboo7 4y ago

The forgotten Fibonacci law of hiring: only 1st class people hire 1st class people (but also some 2nd class people), 2nd class people only hire 3rd class people, etc.