5 ms·
My biggest regret is not shipping more. Sometimes the cause of that is management, and I long to be on that side defining the missing specs, building out the a
by buro9 11y ago
My biggest regret is not shipping more.
Sometimes the cause of that is management, and I long to be on that side defining the missing specs, building out the absent project plans, speaking to customers, allocating resource, championing it all and pushing it forward. At those times I despise being a programmer because being a programmer isn't enough to get product shipped.
Other times (but it feels less frequently) the cause is the programmer. And we all know well enough how frustrating it can be to watch someone not do what you think is easy, and how quickly we want to stop managing, stop designing, stop everything and just code our way out of whatever mess a project is in. A sole programmer is not usually enough though, and I stray back into wanting to manage so that we can ship.
Either way, just having that desire to ship, to make a difference, I feel has kept me in a limbo where I straddle both and am frustrated and hampered by both, and never quite shining at either.
Still I regret not shipping more, and rush into the areas that I hope will help product be shipped.
My greatest career joy was running my own company. I know I failed at the sales and marketing, but we did ship. We shipped a lot, and made a lot of people happy. A massive achievement in a short amount of time, and a good mix of both management and programming. A joyful time even though it was hard work for little pay.
It's a shame positions that really blend these skills seem quite thin on the ground or that they don't really value those who can move from one to the other.
- daxfohl 11y agoSo true. I think a lot of programmers (myself included) fall into the pit of wanting to perfect their code too much. As you look back on your career, you realize ten shipped projects with decent code would've been better than three shipped projects with perfect code. (This is probably true of more than just programmers and code too).
- wainstead 11y agoSeventeen years ago a programmer much senior to me told me: "Don't let the best be the enemy of the good." It's probably the best programming advice I ever got, and I should look him up and thank him. More formally: https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
- StavrosK 11y agoI think this discontent stems from wanting to fix the problems that you see on the other side, and you make a good point. If you're a programmer, you look at the bad manager and say "I could fix this if I were in his shoes". If you're the manager, you look at the bad programmer and say the same. Maybe there is a way to just fix problems where you see them?
- buro9 11y agoI take the constructive approach, I really only care about the problems that are holding up shipping, that impact critical path... however you want to define that. It's the set of problems on the "other side" that are causing delays that are the ones I care about. The ones that don't cause delay I don't mind. It's only constructive to focus on that which holds us up, slows us down. Then I want to fix those. The frustrations stem really from the wedge that we collectively seem to shove between engineering and other parts of a company, including middle-management (or worse, that we destroy middle-management and lack well-seasoned processes that actually help). The walls we've built within companies, between skill sets, leads to a powerlessness to get things done faster, better.