4 ms·
Something like this should be part of every engineering curriculum. As a small anecdote, I've several times ran into engineers who spent inordinate amounts of t
by tziki 5y ago
Something like this should be part of every engineering curriculum. As a small anecdote, I've several times ran into engineers who spent inordinate amounts of time to make the system just a tiny bit more type safer, and when I ask how many bugs would this have fixed during the last year they don't know. When I do the work and send them the single, low-impact bug their efforts would've fixed, they still go through mental gynastics to justify their efforts.
- iib 5y agoA thing to keep in mind in these situations is that making the system a bit more type safe may be more personally satisfying for the engineers. They may see that as a more worthy goal than fixing `n` additional bugs. Same thing with premature, or otherwise unnecessary, optimization. Sometimes it's just fun!
- harterrt 5y agoAuthor here. I fully support prioritizing a project because it's fun! We need to own that rationale though. In OP's situation, it sounds like their counterpart is trying to argue that this project is a "good thing to do" for the user/system. In reality, it's a bit of code hygiene that makes it more fun to do work (still important [1]). That dissonance hides the true value of the work and makes it difficult to reason about. [1] https://blog.harterrt.com/bad-tools https://blog.harterrt.com/bad-tools
- harterrt 5y agoThanks for the note! Doing opportunity sizing early in the product life-cycle definitely helps with this type of situation. Though, I've found it only really helps when it's a forward looking analysis or (rarely) when part of a no-blame retrospective.