I've enjoyed their blog, especially "Speeding Up Your Engineering Org, Part I: Beyond the Cost Center Mentality".
If the author(s) are reading this, when will Part II come out???
Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
21–30 of 66 posts
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#22It's an excellent article, at least three different times I caught myself shaking my head in agreement. I really liked, "Congratulations, you’ve just invented Waterfall.".
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#23I've been developing for 30 years. When asked for an estimate I spend time thinking about it and then when I come up with a number I multiply it by 3. Usually this works but sometimes I can be off. My typical process is to score stuff from "totally get it" to "don't have it all in my head". I then guess on hours and in the end multiply by this 3 factor. When my clients complain about the estimate I often say we "writ…
It's exactly the same thing I have been doing. This is a common project management practice. If you translate this practice in the terms of the original article. This is a kind of double thinking. You know the time it's going to take you, but you also know that you need to multiply it by 3 for it to be correct.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#24One unaddressed problem with estimates is: if the developers finish before the project is due according to the estimate, there is no motivation to start doing new work.
How to solve this?
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#25One of the best things you can do in your organization is create a culture that treats obstacle discovery as forward progress. There is nothing more disheartening for an engineer than banging her head against the wall trying to debug some race condition only to get flak from management about why it isn't fixed and why it's holding up some milestone. The root of this problem is management that doesn't understand the p…
Are you hiring? Can I work for you?
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#26It is possible to become better calibrated for long-term predictions. This takes a longer amount of time, but is still doable. It's an intuitive process, and the way I do it relies on discovering the true probabilities associated with various feelings of confidence I have in a given domain.
The best tool I've yet found to do this is PredictionBook.com. It could use things like tags support (so you could see your accuracy for sports separately from your accuracy for development), but it's still useful overall. I've gotten much better at being accurate, especially for 90% predictions, which is a useful benchmark.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#27One of the best things you can do in your organization is create a culture that treats obstacle discovery as forward progress. There is nothing more disheartening for an engineer than banging her head against the wall trying to debug some race condition only to get flak from management about why it isn't fixed and why it's holding up some milestone. The root of this problem is management that doesn't understand the p…
forward progress means learning.
if our colleague gets into an unexpected issue and he takes time to solve, we pat him for it. however it's important that the learnings have to be shared. they should be tangible enough to be reapplied if we get into a similar situation in future.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#28One unaddressed problem with estimates is: if the developers finish before the project is due according to the estimate, there is no motivation to start doing new work. How to solve this?
While it only happens on a rare occasion, whenever I finish my projects early I'm always excited to show the client/management that we've been able to make better progress. However, I'm extremely cautious not to let their excitement alter their perspective about future estimates being completed early.
Another issue is that often clients/management will jump the gun into the next phase after an early completion without allowing the devs a much needed break. Perhaps this is one of the fears that keeps devs silent when (if ever) they finish early, or stretching their work till the end of the original estimate.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#29One unaddressed problem with estimates is: if the developers finish before the project is due according to the estimate, there is no motivation to start doing new work. How to solve this?
Add more tests.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#30I've been developing for 30 years. When asked for an estimate I spend time thinking about it and then when I come up with a number I multiply it by 3. Usually this works but sometimes I can be off. My typical process is to score stuff from "totally get it" to "don't have it all in my head". I then guess on hours and in the end multiply by this 3 factor. When my clients complain about the estimate I often say we "writ…
But you risk your manager (if you have one) telling you you are "sandbagging." And you might see others on your team tell your manager "it's no big deal - an hour or so of work". And they slap some crap in there that whacks the mole down long enough for the manager to make a mental note to give your team mate a bigger raise than you.