3 ms·

>> If developers are your company's most constraining resource, the key question is how to increase their productivity. > "Increasing productivity" typically p

by jlebar 8y ago

>> If developers are your company's most constraining resource, the key question is how to increase their productivity. > "Increasing productivity" typically puts pressure on developers. I agree frequently -- perhaps typically -- when managers put pressure on developers, they often explain their behavior as, they are trying to increase productivity. And indeed, this is probably genuine. I'd also agree to the converse: That applying pressure in one form or another may be the most common thing that managers try to do to increase developer productivity. Finally, I agree that applying pressure to developers is not a good way to increase their productivity. Nonetheless, I'd respectfully disagree that attempting to increase developers' productivity is a fool's errand. Indeed, we often talk about the giant variance in individual developer productivity. If we agree that it's naive and ultimately self-defeating to pressure developers into increasing their productivity, I'd hope we could also agree that it's naive and ultimately self-defeating for managers to make no serious attempt to increase developer productivity. There are lots of things that can be done to this end that reduce pressure on individual developers. Establishing good processes and tools, both hardware and software. Having quiet workspaces. Ensuring that managers don't suck the souls out of their reports. Establishing protocols that allow developers to work on a maker's schedule. Establishing coaching processes. Building a respectful work environment, where people aren't constantly worried about backstabbing, harassment, or being called an idiot. You get the idea.

dunpeal 8y ago
> Nonetheless, I'd respectfully disagree that attempting to increase developers' productivity is a fool's errand. I never claimed that increasing developer productivity is a fool's errand. Quite the contrary: earlier in my career, my supervisor improved my productivity by carefully observing my development strategies and finding areas where I could work more efficiently. He managed to do that because he was a very senior engineer (over 20 years of experience at the time) and knew exactly what was going on in my development and the way I approached it back then. The guy was incredibly expensive, but thankfully I worked in a place where paying engineers like him exceedingly well was the norm, so he and others stuck around. This isn't the norm in the industry and as you yourself observed, the typical way to "increase productivity" is get some fresh-faced MBA to apply some banal "productivity improving" tips from the article he read on the latest "CIO Today", which typically boil down to "apply pressure" and "make them work longer hours". It often just makes work more stressful and makes the engineers feel worse, but it's the easiest and cheapest way to try to "increase productivity", so that's what's being used. Reality is that clueless managers who could never cut it as devs themselves are rampant in the industry. Remember the Pointy-Haired Boss? That guy wasn't some outlandish joke - he and his ilk used to rule this industry! In fact they still do in many places. Somehow engineers got cowed into accepting that their direct supervisor is someone who never did what they do, probably never could, and doesn't really understand it. I know of no other profession like this. So yeah, improving engineer productivity is possible. But no, most engineering managers reading this article would not do what it takes to establish an engineering culture, pay for Tribe Elders to stick around, and do all the other complex and subtle and expensive things that actually improve productivity. In fact, why pay the Tribe Elder at all when we can just fire him and hire 3 fresh-faced graduates instead?! They'd tell their PHBs to whip engineers harder and get them to stay in the office longer, or worse: introduce bogus metrics like "LoC written" as a performance measure (I've seen this happen THIS IS NOT A JOKE).
- jakobegger 8y ago
  The article suggests to increase developer productivity by focusing on the core part of your business, outsource stuff that doesn't make you unique, and hire technical leaders. Quite different from your claim that managers just want to make developers work longer.
andromedavision 8y ago
> Having quiet workspaces Severely underestimated. I for instance sometimes work from a shared space where most colleagues are not devs. It isn't apparent to them why a quiet environment with little to no interruption is necessary for my kind of work as a dev. Luckily, I can work from home so unless I have a client meeting or presentation, I don't bother going in.

by jlebar 8y ago

dunpeal 8y ago

> Nonetheless, I'd respectfully disagree that attempting to increase developers' productivity is a fool's errand. I never claimed that increasing developer productivity is a fool's errand. Quite the contrary: earlier in my career, my supervisor improved my productivity by carefully observing my development strategies and finding areas where I could work more efficiently. He managed to do that because he was a very senior engineer (over 20 years of experience at the time) and knew exactly what was going on in my development and the way I approached it back then. The guy was incredibly expensive, but thankfully I worked in a place where paying engineers like him exceedingly well was the norm, so he and others stuck around. This isn't the norm in the industry and as you yourself observed, the typical way to "increase productivity" is get some fresh-faced MBA to apply some banal "productivity improving" tips from the article he read on the latest "CIO Today", which typically boil down to "apply pressure" and "make them work longer hours". It often just makes work more stressful and makes the engineers feel worse, but it's the easiest and cheapest way to try to "increase productivity", so that's what's being used. Reality is that clueless managers who could never cut it as devs themselves are rampant in the industry. Remember the Pointy-Haired Boss? That guy wasn't some outlandish joke - he and his ilk used to rule this industry! In fact they still do in many places. Somehow engineers got cowed into accepting that their direct supervisor is someone who never did what they do, probably never could, and doesn't really understand it. I know of no other profession like this. So yeah, improving engineer productivity is possible. But no, most engineering managers reading this article would not do what it takes to establish an engineering culture, pay for Tribe Elders to stick around, and do all the other complex and subtle and expensive things that actually improve productivity. In fact, why pay the Tribe Elder at all when we can just fire him and hire 3 fresh-faced graduates instead?! They'd tell their PHBs to whip engineers harder and get them to stay in the office longer, or worse: introduce bogus metrics like "LoC written" as a performance measure (I've seen this happen THIS IS NOT A JOKE).

jakobegger 8y ago
The article suggests to increase developer productivity by focusing on the core part of your business, outsource stuff that doesn't make you unique, and hire technical leaders. Quite different from your claim that managers just want to make developers work longer.

andromedavision 8y ago

> Having quiet workspaces Severely underestimated. I for instance sometimes work from a shared space where most colleagues are not devs. It isn't apparent to them why a quiet environment with little to no interruption is necessary for my kind of work as a dev. Luckily, I can work from home so unless I have a client meeting or presentation, I don't bother going in.