5 ms·

A large part of the problem is that management doesn’t realize that writing software is a creative endeavor. You don’t get more creative output by working peopl

A large part of the problem is that management doesn’t realize that writing software is a creative endeavor. You don’t get more creative output by working people harder, you do it by giving them more freedom. I may create more value with one spark of insight than months if trudging along, yet almost all management is meant to optimize the trudge and not the spark. This also adds to the very low quality of most code (also cited in the study). We see a lot of VCs blog about how you can’t succeeded if you don’t work long, hard hours but the truth is the complete opposite. You can’t operate at peak coding performance if you’re not rested, motivated and feeling creative. 4 day work weeks (or less), 100% flexible schedules, wfh and far fewer meetings are some ways you can combat burnout.

sprafa 5y ago
So true. I see programming as very similar activity to making poetry. I’m a filmmaker by trade but I enjoy doing some code every once in a while, and it’s always felt to me to be very similar to poetry in the way you have to think about it and structure it.
soco 5y ago
Managers (MBA and the likes) will optimize only what can the tested and optimized. Can anyone define spark? We can all agree it's needed, but no regular management practice looks at it because everybody knows it can't be optimized. So this is what we are left with: optimizing butt time. Yes, there's also the discipline of engineering managers, but they seem to always be on the losing side when financial discussions time comes.
- luffapi 5y ago
  > So this is what we are left with: optimizing butt time. Hence low quality code bases and developer burnout. It’s up to us as developers to demand more from our employers. Thankfully the shift to wfh seems to have tipped the balance of power away from the MBA types, which is why you see all the pearl clutching blog posts about the return to the office and “working hard”.
- cloverich 5y ago
  Taking OP's "spark" comment at face value, if the reality is quality development isn't a steady curve but rather a nearly flat one followed by bursts of sharp peaks, then it does provide some rubric for how to manage the situation. Which is, manage it lightly, look only at very big milestones. Measuring and optimizing day to day incremental improvements might actually be counter productive.

sprafa 5y ago

So true. I see programming as very similar activity to making poetry. I’m a filmmaker by trade but I enjoy doing some code every once in a while, and it’s always felt to me to be very similar to poetry in the way you have to think about it and structure it.

soco 5y ago

Managers (MBA and the likes) will optimize only what can the tested and optimized. Can anyone define spark? We can all agree it's needed, but no regular management practice looks at it because everybody knows it can't be optimized. So this is what we are left with: optimizing butt time. Yes, there's also the discipline of engineering managers, but they seem to always be on the losing side when financial discussions time comes.

luffapi 5y ago
> So this is what we are left with: optimizing butt time. Hence low quality code bases and developer burnout. It’s up to us as developers to demand more from our employers. Thankfully the shift to wfh seems to have tipped the balance of power away from the MBA types, which is why you see all the pearl clutching blog posts about the return to the office and “working hard”.
cloverich 5y ago
Taking OP's "spark" comment at face value, if the reality is quality development isn't a steady curve but rather a nearly flat one followed by bursts of sharp peaks, then it does provide some rubric for how to manage the situation. Which is, manage it lightly, look only at very big milestones. Measuring and optimizing day to day incremental improvements might actually be counter productive.