[mactavish88]

Doesn't seem like this dynamic's changed much since 2009 when the article was originally published.

Taking the maker's schedule into consideration in small companies seems relatively easy - especially when the CEO's coding alongside you. But I'd be interested to know if there are any medium- to large-sized companies who actively think about this and deal with this problem successfully as opposed to just always giving in to the manager's schedule.

[vegetablepotpie]

I work at a large company, and the answer is no. We programers are a naive and innocent bunch that take things at face value. When business people say they want to increase productivity, we take that literally and work accordingly.

The dynamic hasn’t changed because managers do not actually want productivity from their developers. They want legibility and alignment. They want to see what their programmers are doing and they want to know they aren’t doing anything extraneous because they want to see that their schedule is on track. Productivity is a developer problem. If there is a problem with getting things done, it’s a problem with individual developers and not the environment.

The real solution to this problem is to give developers control over their work environment. If developers are in a position to reject meetings and avoid interruptions they are more productive. We’ve seen this happen with WFH and hybrid work environments. This has increased productivity and worker satisfaction. This has also taken away management legibility and alignment and is driving companies to require workers to return to the office despite the benefits.

[gymbeaux]

The status quo as you describe it has persisted, it seems, for about as long as the role of “software engineer” has existed. I’ve often said that management treats software engineering as an assembly line and software engineers as assembly line workers- for example, most seem to expect us to be typing, and not typing == not working. Working remote helps this, but we only have these companies being full-remote because a global event literally forced them to give it a try. It wasn’t all the studies that proved the fruitful outcome of remote work that had any of them consider or adopt it, it was a pandemic. So of course now the same issue lies with the 4-day workweek. They won’t do it unless they’re somehow forced to, either by law (unlikely) or something that’s even outside of lawmakers’ control (strikes?). Anyway, for this reason, I pose that the 4-day workweek is even less likely to gain mass adoption than remote work. To be brash, today’s American workers are pussies, ever-placated by material things and the conveniences of modern society so as to never be too upset with the “arrangement” with Bossman to do something as bold as strike or attempt to form a union.

So I guess my point is that many seem to focus discussion on remote work, when really we should be aiming higher. Working remote is the shit, doing laundry during the day is nice, but we all know we can’t go yellow on Teams or lose our green bubble on Slack lest there be hell to pay.

[ryandrake]

Software company managers want assembly-line-like predictability out of a process that is more like artwork: Good programming output requires discipline and process, but it also relies on creativity, inspiration, luck, the ability to explore and dabble, following roads down dead ends, and so on.

If you ask most high-ups in your software company whether they would rather a 100% guaranteed release date of Sept. 1, 2023 or a 75% confidence sometime between July and October, if they are honest with themselves, they will admit they would rather have the 100% date. So much other stuff needs to happen on fixed dates. Marketing campaigns need to ramp up, sales teams need to get started, maybe your project is part of a bigger product which has a known release date, maybe your project gets flashed onto hardware that goes on a boat on some fixed date.

It would be so much easier for software companies if making software was like making a bolt or a screw: Raw material go in -> machines do their machining -> product come out a known time later, at a known rate, with a known yield.

[gymbeaux]

That lends itself to the notion that they think writing software is akin to an assembly line, which is quite predictable by comparison. But we aren't writing the same thing over and over and over again. It's like they see the stakeholders describe what they want to the BA and the BA gives the requirements to the SWE and then the QA tests it... and they just envision an assembly line.

[sokoloff]

As a now-manager/ex-maker, when I’m setting a meeting with an engineer, I will always try to make mine adjacent to an existing meeting on their calendar, meaning their interruption is longer but at least it’s not an additional interruption. (This isn’t always possible, especially for group/team meetings, but is usually possible for 1:1s.)