[o_nate]

There's a lot of wisdom in this. In addition to reserving some capacity for when true high-value work comes along, I think software engineering is not the type of job that you can do well if you're constantly busy. Trying to write some code as quickly as possible seldom yields the best design. This article doesn't get into another important aspect of this, which is how to get away with working at 80% capacity without getting in trouble with your manager. This takes a bit of care around communication and estimation of work. One of the first good pieces of advice that I got from older seasoned developers when I started my first real programming job has stayed with me to this day: take your estimate of how long it will take to do something and double it before communicating to your manager/users. As you get more experienced that ratio can come down to maybe 1.5x instead of 2x, but the principle still applies.

[martin-uk-]

Kent Beck (maybe in Good News Factory but also in talks) that his team would never commit to more than half what they think they can get done. This is a good way to sustainability. And that's the optimization and precedent to set; that we are here for the long term, delivering steadily at a sustainable pace. It's a long game, and over promising only runs down trust, which is your biggest means too getting the space we need as Devs. Under promise, build trust that we can do what we say, earn the space we need to not burn out. Honestly the more senior I get (Lead), boundary setting and preserving my attention; not burning out, _is_ the job. Because there are myriad ways to do this to yourself.

[hilariously]

Yep, if you want to run a sustainable business you don't look to fire on all cylinders all the time, but that's the rub, almost no owners are looking to run a sustainable business anymore.

Most people either want hypergrowth idiocy or to be bought by the people doing hypergrowth idiocy.

Setting consistent expectations means you can plan, you can actually reasonably budget, you can have predictability in your business dealings - if you are trying to run a good business these are all real features instead of "puts out more code that might or might not make us money, but at least we were pulling all nighters and adding perceived meaning to our lives!"

[zem]

AI has made this way worse - now the thinking is "well, the agent is doing all the work, why can't the engineers make sure it is running on all cylinders all the time, churning out useful code"

[Sohcahtoa82]

> take your estimate of how long it will take to do something and double it before communicating to your manager/users.

Yeah, but did you take Hofstadter's Law into account?

It always takes longer than you expect, even when you take into account Hofstadter's law.

https://en.wikipedia.org/wiki/Hofstadter%27s_law