<div dir="ltr">Maybe Doug's comment was too succinct.<div><br></div><div>This back-and-forth personal argument, laced with insults and disrespect, seems wildly inappropriate for TUHS.</div><div><br></div><div>Marc Rochkind</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Jul 20, 2025 at 4:22 PM G. Branden Robinson <<a href="mailto:g.branden.robinson@gmail.com">g.branden.robinson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Larry,<br>
<br>
At 2025-07-20T04:38:02-0700, Larry McVoy wrote:<br>
> On Sun, Jul 20, 2025 at 02:59:08AM -0500, G. Branden Robinson wrote:<br>
> > At 2025-07-19T20:16:33-0500, Will Senn wrote:<br>
> > > I've thought about the "if you worked for me", dig and it kind of<br>
> > > stung.<br>
> > <br>
> > Manure often does.<br>
> > <br>
> > Larry came up in the soil from which grew tech bro culture.<br>
> > <br>
> > A preoccupation with managing the preferences of others, as with<br>
> > Steve Jobs's "thought leadership", is consistent with the<br>
> > authoritarian style he advocates.<br>
> <br>
> Huh, you won't be surprised I have a different perspective.<br>
<br>
Indeed not. :)<br>
<br>
> Allow me to tell you how I describe managing engineers. Suppose we<br>
> were artists, there were 4 of us. Someone brought us a photograph and<br>
> said "I want a painting of that". OK, split it into quarters and go<br>
> do it. What do we get back?<br>
> <br>
> Well, artist #1 likes oil paints so that's what s/he did. Artist #2<br>
> likes charcoal so that's what they did. Artist #3 likes pen and ink.<br>
> Artist #4 likes water color.<br>
> <br>
> Is that a painting? Maybe if you like a mish mash of stuff that<br>
> doesn't go together. Most people would call it garbage and refuse to<br>
> pay.<br>
<br>
Yeah. I think your analogy is facile and superficial and therefore<br>
characteristic of of Silicon Valley executive culture. Here's why.<br>
<br>
First, text editors don't leave traces of themselves in the work<br>
product.[1]<br>
<br>
Second, _especially_ in a leadership position (although this is more<br>
specifically the role of "architect" if someone has it), you have to be<br>
conscious of the boundaries of your software modules.<br>
<br>
A software project of sufficient complexity to be worth commissioning on<br>
a professional basis is, despite its contractual representation at the<br>
executive level, not a unitary object like an individual painting or<br>
photograph or 2½-minute folk song. Such things are not (formally)<br>
complex, but "elemental": if you decompose them, they stop being what<br>
they are.<br>
<br>
Often, a first-order decomposition of a software system leaves you<br>
with...a collection of other software systems, plus, ideally, some<br>
ancillary documentation and/or an integration test suite.<br>
<br>
> My so called "authoritarian style" is nothing more than I was the<br>
> leader, I had to pick one style.<br>
<br>
Right. To hear you tell it, you preoccupied yourself with matters of<br>
style and let others worry about the harder problems of architecture and<br>
interfacing. Maybe that was the right choice given your skill set and<br>
those of your staff.<br>
<br>
If that characterization cuts, there is a remedy: share a leadership<br>
anecdote where you made (or mediated) a hard decision on a non-stylistic<br>
matter. Maybe two algorithms of the same order in big-O notation were<br>
pitched for a certain software module, but one was preferable on some<br>
non-obvious basis. You've spoken before of the high value of SCCS's<br>
"weave" to BitKeeper. Was there anything the weave made hard or was bad<br>
at? Were you ever on the verge of reconsidering it? If so, what, on an<br>
_engineering_ basis rather than one of style or personal admiration,<br>
mandated its retention?<br>
<br>
If you have stories like that, those would, to me, constitute examples<br>
of technical leadership. And, if all "stakeholders" (your client[s]<br>
_and_ your staff) were happy with the outcome, then they could be<br>
examples of _good_ technical leadership, too.<br>
<br>
> And, yes, it means if you have N people working you usually have N-1<br>
> pissed off people because they weren't getting to do things their way.<br>
<br>
I suspect you accurately perceived the presence of frustration. I also<br>
bet you assumed its cause rather than undertaking an earnest exploration<br>
thereof. A confounding factor here is that a project can have so many<br>
problems that the individual contributors themselves have trouble<br>
accurately identifying an "overall" problem or a single "worst" one that<br>
they have. Further, if they are experiencing deadline pressure, whether<br>
imposed by themselves or by leadership and are asked to identify<br>
"blockers", they're likely to name the obstacles that are easiest to<br>
articulate[2] or that they most recently struggled with.[3] One<br>
generally can't calendar the removal of as-yet-unarticulated problems.<br>
If the engineers have the same blocker day after day, then management is<br>
failing to remove them. If the engineers have NEW blockers every day or<br>
every week, and you have confidence in your recruitment/hiring, then<br>
the staff is not sandbagging you--the project has deep problems.<br>
<br>
My personal experience is that underspecification and otherwise<br>
unarticulated expectations are the root causes of nearly every problem<br>
that cause anguish among staff. And behind that problem is the worse<br>
one that managers climb into contractual beds with their counterparties<br>
without having done their necessary homework first. The client never<br>
wants to admit that they haven't really though through what it is<br>
they're asking for. They've already made promises to a director, VP, or<br>
someone in the C suite. So they yell at you and you yell at your staff.<br>
<br>
The manure, as it were, rolls downhill.<br>
<br>
> Letting them do things their way means there is no overall picture you<br>
> are driving towards.<br>
<br>
In engineering, we do not implement an "overall picture", but to a<br>
detailed specification.<br>
<br>
If you lack a detailed specification to implement, what you are doing is<br>
not (solely) engineering. That's not necessarily a bad thing; you are<br>
engaged in design and possibly in research. Charge more. Develop your<br>
staff by helping them get conference papers out of the work.<br>
<br>
> And I'm not above being overridden. I personally hate GNU make for<br>
> all the similar reasons you are advocating for a smaller vi.<br>
<br>
That wasn't me, but I'll freely admit that Vim has many features I don't<br>
use. I have found that time spent seeking mastery of one tool is good<br>
practice in judging the "right-sizing" of another. If nothing else, it<br>
helps one learn which hills aren't worth dying on. ;-)<br>
<br>
Regarding make(1), POSIX 2024 has made it _much_ better. I still think<br>
the BSDs' snarling adherence to old-style suffix rules, which are<br>
inflexible and ambiguous, and restrictions on $< are counterproductive,<br>
but a lot of stuff that used to not be portable, is portable now.<br>
<br>
> But my team convinced me it was less work to move to that than<br>
> maintain all the scripts we were using to use a simple make.<br>
> <br>
> But yeah, when people work for me, I lead. I set the tone. It wasn't<br>
> tech bro nonsense, it was about herding people towards the same<br>
> picture.<br>
<br>
I have a slender hope that I can persuade you that these things are<br>
actually the same in every way that matters. As implied above, this<br>
doesn't make you a tech bro yourself, necessarily, it might mean you're<br>
emphasizing the wrong elements of your experience for an audience of<br>
salty old engineers, contrast with venture capitalists.<br>
<br>
In martial arts training, there are "degrees" of black belt. Only the<br>
first few degrees have anything to do with one's own ability or<br>
perfection of form. After that, your advancement is determined by how<br>
many black belts you _train_. To become a master, you must train many<br>
black belts. To become a grand master, you must train many masters.<br>
While I'm sure there are perverse incentives in martial arts instruction<br>
(hello, capitalism), this approach of making your own advancement beyond<br>
a certain point dependent on the development of people no longer<br>
accountable to you strikes me as a worthwhile corrective to the<br>
narcissistic orientation of leadership in software development.<br>
<br>
Being a good example is a different phenomenon than being an object of<br>
emulation. One phenomenon is deep, the other shallow. Steve Jobs was<br>
good at producing a lot of fawning emulators with black turtlenecks and<br>
glib proclamations about the future of technology. Steve Wozniak has in<br>
substantial measure dedicated himself to producing more good engineers.<br>
<br>
> I wasn't trying to tell Will he can't use whatever editor he wants, I<br>
> was trying to tell Will I wouldn't tolerate this much back and forth<br>
> about his personal preferences distracting us from shipping product.<br>
<br>
That's not how I read what you said, but fine. I agree that bickering<br>
over tool choice can be a distraction from satisfying the contract and<br>
getting the final payment. But the sword of opportunity cost cuts both<br>
ways. You can't always be sure that the most readily available<br>
substitute good for an editor argument is a laser-focused coding<br>
session[4] on implementing an element of a deliverable.<br>
<br>
If your engineers are motivated, you will find that they don't distract<br>
themselves with nonsense _when they have a better alternative_. A good<br>
engineering manager deeply understands the XKCD concept of "nerd<br>
sniping" and knows how to adapt it to the benefit of the individual<br>
contributor, their team, the client, and consequently themselves.[5]<br>
<br>
> My team had emacs people and vi people, nobody cared so long as you<br>
> got your job done.<br>
<br>
That's a salutary attitude. But engineers also need time and vehicles<br>
for decompression, and one of the things they can use their downtime for<br>
is playful practice at evaluating tradeoffs between competing designs or<br>
systems.<br>
<br>
If you have an engineer who's going around harassing their peers for<br>
choosing the "wrong" editor, the problem is not their choice of editor,<br>
which might be "correct" in your opinion. The problem is that they're<br>
interfering unjustifiably with the work of their colleagues. Addressing<br>
that problem "sets the tone" much better than expressing, let alone<br>
mandating, your own preferences. It's what _I_ expect of a manager, at<br>
any rate.<br>
<br>
> What we didn't have is editor arguments clogging up our thinking.<br>
<br>
Done well--and this might happen only in a minority of cases--editor<br>
arguments can _enhance_ people's thinking; see "playful practice" above.<br>
<br>
And even if they don't, if they're no more destructive than a dispute<br>
over whether the coach of the local sportsball team was an idiot for<br>
benching player X in the Big Game last weekend, or than knocking off 30<br>
minutes early for beers together at the end of a frustrating day, then<br>
good leadership can mean leaving some rough spots unsanded.<br>
<br>
Regards,<br>
Branden<br>
<br>
[1] _Programmers_ might so do, with vi "modelines" or Emacs "local<br>
variables" in text constitutive of a comment in the program source<br>
code. Different matter.<br>
<br>
[2] another instance of our old friend the "streetlight effect"<br>
<a href="https://en.wikipedia.org/wiki/Streetlight_effect" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Streetlight_effect</a><br>
<br>
[3] <a href="https://en.wikipedia.org/wiki/Recency_bias" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Recency_bias</a><br>
<br>
[4] or automated test construction, or documentation revision--wait, why<br>
is everybody laughing?<br>
<br>
[5] <a href="https://xkcd.com/356/" rel="noreferrer" target="_blank">https://xkcd.com/356/</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Subscribe to my Photo-of-the-Week emails at my website <a href="http://mrochkind.com" target="_blank">mrochkind.com</a>.</div></div>