[TUHS] how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference))

Hi Larry, At 2025-07-20T04:38:02-0700, Larry McVoy wrote: Indeed not. :) Yeah. I think your analogy is facile and superficial and therefore characteristic of of Silicon Valley executive culture. Here's why. First, text editors don't leave traces of themselves in the work product.[1] Second, _especially_ in a leadership position (although this is more specifically the role of "architect" if someone has it), you have to be conscious of the boundaries of your software modules. A software project of sufficient complexity to be worth commissioning on a professional basis is, despite its contractual representation at the executive level, not a unitary object like an individual painting or photograph or 2½-minute folk song. Such things are not (formally) complex, but "elemental": if you decompose them, they stop being what they are. Often, a first-order decomposition of a software system leaves you with...a collection of other software systems, plus, ideally, some ancillary documentation and/or an integration test suite. Right. To hear you tell it, you preoccupied yourself with matters of style and let others worry about the harder problems of architecture and interfacing. Maybe that was the right choice given your skill set and those of your staff. If that characterization cuts, there is a remedy: share a leadership anecdote where you made (or mediated) a hard decision on a non-stylistic matter. Maybe two algorithms of the same order in big-O notation were pitched for a certain software module, but one was preferable on some non-obvious basis. You've spoken before of the high value of SCCS's "weave" to BitKeeper. Was there anything the weave made hard or was bad at? Were you ever on the verge of reconsidering it? If so, what, on an _engineering_ basis rather than one of style or personal admiration, mandated its retention? If you have stories like that, those would, to me, constitute examples of technical leadership. And, if all "stakeholders" (your client[s] _and_ your staff) were happy with the outcome, then they could be examples of _good_ technical leadership, too. I suspect you accurately perceived the presence of frustration. I also bet you assumed its cause rather than undertaking an earnest exploration thereof. A confounding factor here is that a project can have so many problems that the individual contributors themselves have trouble accurately identifying an "overall" problem or a single "worst" one that they have. Further, if they are experiencing deadline pressure, whether imposed by themselves or by leadership and are asked to identify "blockers", they're likely to name the obstacles that are easiest to articulate[2] or that they most recently struggled with.[3] One generally can't calendar the removal of as-yet-unarticulated problems. If the engineers have the same blocker day after day, then management is failing to remove them. If the engineers have NEW blockers every day or every week, and you have confidence in your recruitment/hiring, then the staff is not sandbagging you--the project has deep problems. My personal experience is that underspecification and otherwise unarticulated expectations are the root causes of nearly every problem that cause anguish among staff. And behind that problem is the worse one that managers climb into contractual beds with their counterparties without having done their necessary homework first. The client never wants to admit that they haven't really though through what it is they're asking for. They've already made promises to a director, VP, or someone in the C suite. So they yell at you and you yell at your staff. The manure, as it were, rolls downhill. In engineering, we do not implement an "overall picture", but to a detailed specification. If you lack a detailed specification to implement, what you are doing is not (solely) engineering. That's not necessarily a bad thing; you are engaged in design and possibly in research. Charge more. Develop your staff by helping them get conference papers out of the work. That wasn't me, but I'll freely admit that Vim has many features I don't use. I have found that time spent seeking mastery of one tool is good practice in judging the "right-sizing" of another. If nothing else, it helps one learn which hills aren't worth dying on. ;-) Regarding make(1), POSIX 2024 has made it _much_ better. I still think the BSDs' snarling adherence to old-style suffix rules, which are inflexible and ambiguous, and restrictions on $< are counterproductive, but a lot of stuff that used to not be portable, is portable now. I have a slender hope that I can persuade you that these things are actually the same in every way that matters. As implied above, this doesn't make you a tech bro yourself, necessarily, it might mean you're emphasizing the wrong elements of your experience for an audience of salty old engineers, contrast with venture capitalists. In martial arts training, there are "degrees" of black belt. Only the first few degrees have anything to do with one's own ability or perfection of form. After that, your advancement is determined by how many black belts you _train_. To become a master, you must train many black belts. To become a grand master, you must train many masters. While I'm sure there are perverse incentives in martial arts instruction (hello, capitalism), this approach of making your own advancement beyond a certain point dependent on the development of people no longer accountable to you strikes me as a worthwhile corrective to the narcissistic orientation of leadership in software development. Being a good example is a different phenomenon than being an object of emulation. One phenomenon is deep, the other shallow. Steve Jobs was good at producing a lot of fawning emulators with black turtlenecks and glib proclamations about the future of technology. Steve Wozniak has in substantial measure dedicated himself to producing more good engineers. That's not how I read what you said, but fine. I agree that bickering over tool choice can be a distraction from satisfying the contract and getting the final payment. But the sword of opportunity cost cuts both ways. You can't always be sure that the most readily available substitute good for an editor argument is a laser-focused coding session[4] on implementing an element of a deliverable. If your engineers are motivated, you will find that they don't distract themselves with nonsense _when they have a better alternative_. A good engineering manager deeply understands the XKCD concept of "nerd sniping" and knows how to adapt it to the benefit of the individual contributor, their team, the client, and consequently themselves.[5] That's a salutary attitude. But engineers also need time and vehicles for decompression, and one of the things they can use their downtime for is playful practice at evaluating tradeoffs between competing designs or systems. If you have an engineer who's going around harassing their peers for choosing the "wrong" editor, the problem is not their choice of editor, which might be "correct" in your opinion. The problem is that they're interfering unjustifiably with the work of their colleagues. Addressing that problem "sets the tone" much better than expressing, let alone mandating, your own preferences. It's what _I_ expect of a manager, at any rate. Done well--and this might happen only in a minority of cases--editor arguments can _enhance_ people's thinking; see "playful practice" above. And even if they don't, if they're no more destructive than a dispute over whether the coach of the local sportsball team was an idiot for benching player X in the Big Game last weekend, or than knocking off 30 minutes early for beers together at the end of a frustrating day, then good leadership can mean leaving some rough spots unsanded. Regards, Branden [1] _Programmers_ might so do, with vi "modelines" or Emacs "local variables" in text constitutive of a comment in the program source code. Different matter. [2] another instance of our old friend the "streetlight effect" https://en.wikipedia.org/wiki/Streetlight_effect [3] https://en.wikipedia.org/wiki/Recency_bias [4] or automated test construction, or documentation revision--wait, why is everybody laughing? [5] https://xkcd.com/356/