matfil

To an extent, yes, but I'm pretty confident that it's not actually the coding that's the issue, in that I can work solo on something (even something exciting and all-consuming) and context-switch into social or family mode with only a few minutes of transition time. The "software is a team sport" aspect of a lot of professional programming is much more wearing, though.

My model for this is that I seem to have a fixed budget of sociability that I can either spend on meeting at work or on friends and family. It's pretty frustrating.

Software development scales poorly. This was noted a long time ago, an I’ve not seen anything that fundamentally falsifies the Fred Brooks view. So to make the expected cost of software lower, shouldn’t we be looking to smaller-scale, more individualistic ways of working?

Yes, I've encountered them. It seems really hard to do them in a way that doesn't touch heavily on style. To the extent that the preferred solution to trying to shift the focus back to deeper issues is to go one step further and mandate auto-formatting tools. So individuality-of-style has been dismissed out of hand.

Can they be helpful? In some cases, perhaps yes. But they're definitely pushing a collective-ownership, try-to-smooth-away-individual-differences agenda.

I might agree with you in the sense that sometimes there's a worthwhile discussion to be had and of course in such cases it's good to talk to someone who's opinion you trust.

That's different from mandatory code review, which almost inevitably will end up covering style and process considerations.

It's certainly a filter, but depending on your perspective I'd be a little cautious about "won't affect the good people".

I suspect this may not be too well received, but I've thus far managed to avoid regular formal reviews, and I'd advise others to think twice before imposing them. They seem like a big step towards treating programmers like cogs in a machine rather than competent individuals, and for me that's a direction I don't want to be headed.

The “software is a team sport” mentality.

At the start of a project, people saying “this needs a team”, even if you can already see a clear path to getting the thing working.

In the middle, “stakeholders” who want to set schedules and define how things are done without adding value.

Once something’s working, others presenting it as incomplete or untrustworthy purely because it’s the work of a lone developer and doesn’t tick some process boxes (and completely regardless of demonstrated capability/stability/etc.)

(This isn’t to say collaboration isn’t the right answer some of the time. But in my experience when it works out, it’s usually arises pretty organically and often has clear boundaries rather than “working on a shared backlog”).

I’ve seen them become unfashionable over the past few years. Is it the implied individualism that gives these words “terrible company” associations?

Is there a good word for an experienced person who is better at shutting the door and working through problems rather that doing things in a team?

It's real. Not so much online, but within organizations. Goes hand in hand with insisting that all successes and failures are down to "the team", and being reluctant to give much thought to what individuals can and do achieve.

Yes to both of these, but there are other options as well.

The frustrating ones are those who talk a good talk about "doing things right" (and, generally, talk a lot...), but then work on something for an age and come back with a solution that's objectively worse than the "RIGHT NOW" solution we've been using in the interim.

"The Soul of a New Machine", by Tracy Kidder. Solving hard problems, dealing with (and balancing) both technical and business concerns, but with emphasis on getting things done over process and organisational concerns.

In terms of books to (gently) influence colleagues... I generally find myself looking for pretty-much the opposite. Something that emphasises the joy of stealing fire from heaven.

Old-school sci-fi (lots to choose from) could be pretty good in that regard. Newer stuff often leans a bit too much in the morality tale direction.

It's certainly an interesting read. But very oriented towards big, conservative organisations.

To me, the message was just how operations-focussed and, above all, anti-individualistic big chunks of our field have become.

20 year programmers fairly often get to "lead teams of programmers".

In some ways, it's staying hands-on that can be difficult. At least if you want to be recognised and valued as someone who's experienced and can take on challenging problems without a lot of support.

It's unfortunate that we try to measure this kind of thing on a single dimension. There's certainly a type of developer/mentor who does do a good job of setting helpful directions in a large-team setting. At the other extreme, there are people who don't necessarily thrive in a "team setting" at all, but on the other hand can build big things (or, better yet, small things than solve big problems) remarkably quickly. Both "high multiples", but quite different skills.

(There does seem to have been a fair amount of devaluation of solo-working over the last few years, which perhaps leads to less appreciation of the second kind of high-multiple than was once the case).

Any idea why the expectation of autonomy for professional programmers seems to be so much lower than for professional novelists?

I find joy in solving problems with computers. Sometimes a lot. The frustration around dealing with core tools (like your semicolon example) has never particularly bothered me. After all, the rules are learnable, and are usually there for a reason. I like working on my own problems, but doing stuff for someone else is good too. Even if I'm being asked to solve not-quite-the-right problem (I'll speak up about this, but at the end of the day: paid to hide in a corner and program? Hell yeah.)

That said, if you see me in the office, "confused, frustrated, or angry" is a real possibility, and I do something find myself seriously wondering whether it's a career where I have much of a future. Thing is, it's never the programming that's the issue. Rather, it's management approaches which downplay the one-on-one person-versus-computer aspect, and instead maintain that software should be the result of a team following a somewhat-defined process. Collective ownership, pairing, and big piles of standards to follow completely destroy the individual, almost-artisanal side of programming. That's when it starts to look like a slog.