5 ms·

If you are a contractor, you need to read, understand, and practice this. I am about to fire a contractor who is extremely productive because he is completely u

If you are a contractor, you need to read, understand, and practice this. I am about to fire a contractor who is extremely productive because he is completely unable/unwilling to take the feedback that he needs to move slower and check his work now that the product is in production with many real users, and this is not the first (nor likely the last) I've fired for this reason. He's incredibly smart, fast, and gets a ton done, but the fact that he cannot figure out how to turn his speed dial further towards correctness means that he is literally useless to me at this point. That goes the other way as well: I've had to cut FAANG hires from startup projects because they couldn't agree on any corners to cut in the name of getting an MVP out quickly. As a senior person you need to be able to make that tradeoff effectively, and figure out what level of quality/testing is appropriate to the business situation. It's a tricky skill to learn, and it's a big reason why a lot of engineers that thrive in startups can't survive the transition to "real business" and vice versa.

tenaciousDaniel 5y ago
Agreed. I don’t know how this would work in practice, but it would be great if dev education/bootcamping explicitly incorporated these kind of tight-rope walks. Most difficult things in life turn out to be balancing acts between two opposing forces, yet junior devs always seem surprised about that fact.
cpach 5y ago
Very interesting! I guess the good old iron triangle is still relevant. https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle
- ultrablack 5y ago
  Choose one…
josephg 5y ago
Yes! This is such an important quality in a senior engineer: Can you tune your work based on the appropriate values for the project? Building a weekend prototype? Move fast. Just get it working. Building an MVP? Move fast but keep an eye on which areas will need to be redesigned in 6 months. Pay down tech debt as the code matures and you know which features will stick around. Adding features to software with an established user base? Move slowly and test. If you can’t adjust your workflow based on the needs of the product, you will only be able to add value in a single niche.
andi999 5y ago
I met some people who do not know how to write correct code (maybe because they do not have a correct model of how computation works all the way down). So the 'trick' of one guy was just to work as fast as possible so at least they looked productive. Slowing down wouldnt have helped.
- im3w1l 5y ago
  Sounds like a guy worth training.
  - andi999 5y ago
    Are you hiring?
  - cornel_io 5y ago
    Training has limited value that depends critically on the personality traits of the person being trained. Someone who's fresh to the field and is eager to take feedback and act on it, great! They'll learn quickly and you can mold them, they'll slurp up all the feedback they can get and end up fantastic after very little time. But someone who already has 20 years of experience and is bitter that YOU, a young'n with just 10 years under your belt has the AUDACITY to condescend to THEM about how they could improve THEIR PERFECT CODE? You might as well just fire this person unless you're happy with their output, they are going to be locked in their ways and while it's possible to "break" a person like this and get them to bend a bit, it's going to be your full-time job which you'd damn well better have political cover for within the org because it can get nasty.
- CraigJPerry 5y ago
  >> I met some people who do not know how to write correct code I have never met a single developer who knew how to write correct code. There is always a bug somewhere.
onion2k 5y ago
"Why do it right when you can do it twice." is one of my favorite lines to developers who insist on going fast.
- marcosdumay 5y ago
  Doing it right takes too much time. It's better to do it twice and have your clients give up and throw it away because they can't use either result.
- forgotmypw17 5y ago
  I think there's something to be said for doing it twice, or several more times. I've read many well-accomplshed devs say that they don't get it figured out until several prototypes in, and a "good" version doesn't come until the seventh rewrite.
  - onion2k 5y ago
    Iterating to a correct solution to a problem works well as a strategy for projects, but very poorly for smaller units of work like a feature or a bug fix. Often, doing the quick hacky solution for a feature won't show the problems it has for a while, by which time you've built things on top of it. Having to go back and fix that impacts far more than if you'd spent a little more time in the first place. It's particularly important when you're designing data structure changes more than than code. Getting an API or a database table design right first time (or even just 'more right') is worth the time invested.
ljm 5y ago
This is the difference between productivity and efficacy.

tenaciousDaniel 5y ago

Agreed. I don’t know how this would work in practice, but it would be great if dev education/bootcamping explicitly incorporated these kind of tight-rope walks. Most difficult things in life turn out to be balancing acts between two opposing forces, yet junior devs always seem surprised about that fact.

cpach 5y ago

Very interesting! I guess the good old iron triangle is still relevant. https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle

ultrablack 5y ago
Choose one…

josephg 5y ago

Yes! This is such an important quality in a senior engineer: Can you tune your work based on the appropriate values for the project? Building a weekend prototype? Move fast. Just get it working. Building an MVP? Move fast but keep an eye on which areas will need to be redesigned in 6 months. Pay down tech debt as the code matures and you know which features will stick around. Adding features to software with an established user base? Move slowly and test. If you can’t adjust your workflow based on the needs of the product, you will only be able to add value in a single niche.

andi999 5y ago

I met some people who do not know how to write correct code (maybe because they do not have a correct model of how computation works all the way down). So the 'trick' of one guy was just to work as fast as possible so at least they looked productive. Slowing down wouldnt have helped.

im3w1l 5y ago
Sounds like a guy worth training.
- andi999 5y ago
  Are you hiring?
- cornel_io 5y ago
  Training has limited value that depends critically on the personality traits of the person being trained. Someone who's fresh to the field and is eager to take feedback and act on it, great! They'll learn quickly and you can mold them, they'll slurp up all the feedback they can get and end up fantastic after very little time. But someone who already has 20 years of experience and is bitter that YOU, a young'n with just 10 years under your belt has the AUDACITY to condescend to THEM about how they could improve THEIR PERFECT CODE? You might as well just fire this person unless you're happy with their output, they are going to be locked in their ways and while it's possible to "break" a person like this and get them to bend a bit, it's going to be your full-time job which you'd damn well better have political cover for within the org because it can get nasty.
CraigJPerry 5y ago
>> I met some people who do not know how to write correct code I have never met a single developer who knew how to write correct code. There is always a bug somewhere.

onion2k 5y ago

"Why do it right when you can do it twice." is one of my favorite lines to developers who insist on going fast.

marcosdumay 5y ago
Doing it right takes too much time. It's better to do it twice and have your clients give up and throw it away because they can't use either result.
forgotmypw17 5y ago
I think there's something to be said for doing it twice, or several more times. I've read many well-accomplshed devs say that they don't get it figured out until several prototypes in, and a "good" version doesn't come until the seventh rewrite.
- onion2k 5y ago
  Iterating to a correct solution to a problem works well as a strategy for projects, but very poorly for smaller units of work like a feature or a bug fix. Often, doing the quick hacky solution for a feature won't show the problems it has for a while, by which time you've built things on top of it. Having to go back and fix that impacts far more than if you'd spent a little more time in the first place. It's particularly important when you're designing data structure changes more than than code. Getting an API or a database table design right first time (or even just 'more right') is worth the time invested.

ljm 5y ago

This is the difference between productivity and efficacy.