4 ms·

There's a lot of talk about this subject as if the practicioners of coding long past the point of optimal productivity have a choice not to code when you are at

There's a lot of talk about this subject as if the practicioners of coding long past the point of optimal productivity have a choice not to code when you are at that point. I don't think most of us actually have a choice - it is often a case of ship or lose customer x. Promises are made that can't be kept by humane working hours. Things break days before a huge demo. Someone gets sick. You are in an arms race with a well-funded competitor. Something I would like the programming world to discuss is that it isn't the best coded product that wins - technical quality rarely matters. Usually, the first product to market wins, or the programmer who kicks out the most features as long as the features works. Shipping isn't just a feature. It is the only code quality metric that matters to anyone who isn't a coder. It also is easier to ask forgiveness for refactoring after the ship date than it is to ask for permission to push the date back. All-nighters are ingrained in the practice of programming for a living. The code may not always be robust or elegant, but in most cases what matters is that it works and gets done faster than the others guys' high quality code job.

wpietri 14y ago
I agree that when emergencies happen, we should rise to the occasion. But I think it's a business mistake to let emergencies become the new normal. I have seen a number of shops that rely on last-minute rushes and big drama. Indeed, I've made some spectacular money from pulling their nuts out of the fire. But the main reason that they had to do something dramatic was the accumulated weight of all their poor decisions. It's as if their technical debt was held by a loan shark, showing up smacking them around just for fun. It isn't the best product that always wins. But shipping a shitty product also doesn't guarantee winning either. All else equal, wasteful organizations lose out over time. That doesn't mean I'll never step away from the optimum path, but it does mean I'll only leave it when I think there's a strong business case for doing so.
adrianhoward 14y ago
Something I would like the programming world to discuss is that it isn't the best coded product that wins - technical quality rarely matters. Usually, the first product to market wins, or the programmer who kicks out the most features as long as the features works 1) The first product to market often doesn't win. In fact I'm hard pushed to think of many examples of that being true ;-) 2) Even taking that as true - I'm not sure I follow the argument. Working longer hours != shipping earlier. If you are working past the point of optimal productivity then, in anything but the very short term, you are slowing yourself down. I've seen multiple teams ship faster by working fewer hours. I know others have too. I find it freakishly bizarre that folk don't measure their productivity and optimise for going faster rather than working longer.
brazzy 14y ago
Yes, sometimes there are emergencies where working long hours isn necessary, and if you're well rested before, you can still be productive, if not optimally so. But these are rare exceptions. If they occur regularly, it's a sign of shitty management and a shitty company you need to get out of ASAP. Especilally if you're told it's normal and something to be proud of As for your examples >ship or lose customer x. shitty customer, will probably use low quality resulting from it as an excuse to withhold payment. Get a better customer. >Promises are made that can't be kept by humane working hours. Shitty management, no excuses >Things break days before a huge demo. Probaby because of bad code written by someone working late. >Someone gets sick. Nobody else can do their job? Shitty management > You are in an arms race with a well-funded competitor. You probably won't win it with code that breaks all the time.
dasil003 14y ago
> Something I would like the programming world to discuss is that it isn't the best coded product that wins - technical quality rarely matters That depends. If by code quality you mean living up to every aesthetic whim and being fiddly over inconsequential details, then no, it doesn't matter. On the other hand, for any code base that lives through a few pivots the conceptual integrity of the architecture starts to break down. At every juncture you can just power through with a quick hack to ship the feature, but over time you are weaving yourself a rat's nest of unmaintainable code. If you have to do this to win the customer, so be it, but at some point this does catch up to you, and you will fail oh so very hard.
jackcviers3 14y ago
All great points. As for shipping first, see Netscape and Dos. For heroic hours being the norm, see Facebook and Google. As for shitty management and someone getting sick and breakage before a big demo, not necessarily. I've been a part of small teams most of my professional career. So many times the only way to get big fish to bite be was to both overpromise and over-achieve, and with small teams this usually meant grinding through tough situations like those above. You don't always know with enough time to spare when you have a chance to demo new functionality for a really big fish. With sickness, it is the redundancy of skills and codebase knowledge that have led me to take one on the chin.
epochwolf 14y ago
As I said in a previous comment, I average a 6 hour workday with a third of it being administrative stuff like email and working wih QA. This is he norm for me. That doesn't mean I don't do crunch time. If my team needs someone to work the weekend to ship in an emergency, I will do it. But, that blows away the next week of productivity. It's fine to do this once in a while and I don't complain about doing it. But, if this the norm, you don't have priorities right. Not everything is really an emergency.

wpietri 14y ago

I agree that when emergencies happen, we should rise to the occasion. But I think it's a business mistake to let emergencies become the new normal. I have seen a number of shops that rely on last-minute rushes and big drama. Indeed, I've made some spectacular money from pulling their nuts out of the fire. But the main reason that they had to do something dramatic was the accumulated weight of all their poor decisions. It's as if their technical debt was held by a loan shark, showing up smacking them around just for fun. It isn't the best product that always wins. But shipping a shitty product also doesn't guarantee winning either. All else equal, wasteful organizations lose out over time. That doesn't mean I'll never step away from the optimum path, but it does mean I'll only leave it when I think there's a strong business case for doing so.

adrianhoward 14y ago

Something I would like the programming world to discuss is that it isn't the best coded product that wins - technical quality rarely matters. Usually, the first product to market wins, or the programmer who kicks out the most features as long as the features works 1) The first product to market often doesn't win. In fact I'm hard pushed to think of many examples of that being true ;-) 2) Even taking that as true - I'm not sure I follow the argument. Working longer hours != shipping earlier. If you are working past the point of optimal productivity then, in anything but the very short term, you are slowing yourself down. I've seen multiple teams ship faster by working fewer hours. I know others have too. I find it freakishly bizarre that folk don't measure their productivity and optimise for going faster rather than working longer.

brazzy 14y ago

Yes, sometimes there are emergencies where working long hours isn necessary, and if you're well rested before, you can still be productive, if not optimally so. But these are rare exceptions. If they occur regularly, it's a sign of shitty management and a shitty company you need to get out of ASAP. Especilally if you're told it's normal and something to be proud of As for your examples >ship or lose customer x. shitty customer, will probably use low quality resulting from it as an excuse to withhold payment. Get a better customer. >Promises are made that can't be kept by humane working hours. Shitty management, no excuses >Things break days before a huge demo. Probaby because of bad code written by someone working late. >Someone gets sick. Nobody else can do their job? Shitty management > You are in an arms race with a well-funded competitor. You probably won't win it with code that breaks all the time.

dasil003 14y ago

> Something I would like the programming world to discuss is that it isn't the best coded product that wins - technical quality rarely matters That depends. If by code quality you mean living up to every aesthetic whim and being fiddly over inconsequential details, then no, it doesn't matter. On the other hand, for any code base that lives through a few pivots the conceptual integrity of the architecture starts to break down. At every juncture you can just power through with a quick hack to ship the feature, but over time you are weaving yourself a rat's nest of unmaintainable code. If you have to do this to win the customer, so be it, but at some point this does catch up to you, and you will fail oh so very hard.

jackcviers3 14y ago

All great points. As for shipping first, see Netscape and Dos. For heroic hours being the norm, see Facebook and Google. As for shitty management and someone getting sick and breakage before a big demo, not necessarily. I've been a part of small teams most of my professional career. So many times the only way to get big fish to bite be was to both overpromise and over-achieve, and with small teams this usually meant grinding through tough situations like those above. You don't always know with enough time to spare when you have a chance to demo new functionality for a really big fish. With sickness, it is the redundancy of skills and codebase knowledge that have led me to take one on the chin.

epochwolf 14y ago

As I said in a previous comment, I average a 6 hour workday with a third of it being administrative stuff like email and working wih QA. This is he norm for me. That doesn't mean I don't do crunch time. If my team needs someone to work the weekend to ship in an emergency, I will do it. But, that blows away the next week of productivity. It's fine to do this once in a while and I don't complain about doing it. But, if this the norm, you don't have priorities right. Not everything is really an emergency.