Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I hate having to ship features when I just want to work on improving reliability, doing upgrades, improving DX and clearing all the crap out of the way that's preventing us from otherwise shipping.


All that stuff is important, and I enjoy it more than most.

But I also keep in mind that the only point of it is to enable shipping more features faster and better.


For sure. For me it's about ratio's though. It never makes sense to me when I encounter situations where 100% of capacity is dedicated to features, features, features when sustained velocity is in the toilet when it feels like we're standing in an entire orchard of low-hanging fruit of productivity gains to be had. I usually find that after about a year or so in a company it starts to click for people that if they just let me be more self-directed then stuff starts to improve for everyone at a faster rate and it's win-win. I know there are other devs like me, but I feel like it's not widely recognized that we exist and should be enabled to just do our thing. I don't know if you can relate, but maybe you can?


In this context, a completed upgrade or cleanup would count as "shipping".

The article's author seems to primarily emphasize serializing processes so that incremental progress is readily evident to everyone and the organization can reap early wins from the first-shipped results.


Shipping an 80% solution is ok... it leaves a bad taste, but its "ok".

The problem becomes more-so when the next 80% solution is shipped on top of the previous 80% solution. And that just gets demoralizing after a time when one looks at the stack of 80% solutions on top of 80% solutions that needs to get fixed up (but "we don't have time to do that").


One thing I tell our developers (and POs) is that we can only tolerate 80% solutions so long as they also produce 120% solutions (or give us additional time/scope for them) at approximately the same rate.


I don't think it has to be even, but there is certainly a ratio.

Sometimes you have to let developers overengineer something or work on something a little too much so they don't go insane and take you with them. Or quit and go somewhere else.

Few things affect consistent delivery as much as bad employee retention and burnout.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: