The perhaps most melodramatic thing I've ever written about software. Sat in my to publish folder for a while. But I realized I am just a bit melodramatic, no one will care :) > Theory creation, world-building, and crafting software are all one in the same activity. Removing any of these elements eliminates the very value you hired software engineers to provide. But it does more than that. It forces these software engineers to make a difficult choice: fight to create the world they believe in, or give up and live in a world they are no longer invested in. https://jimmyhmiller.github.io/stuck

I caught some flack on slack a while back when I argued that only people with a programming background should be allowed to lead programming teams or be product managers, but I believe that your blog post just made an excellent argument for my position. The people who impose theory damaging decisions upon a programming team usually do it because they don't understand the consequences of their decisions, and they don't understand the consequences because they don't know anything about computers or programming.

Does your conception of "theory" here include things like relative priority of new features vs bugs vs paying off tech debt? The big rewrite somebody is pushing? The theory of the codebase feels inseparable from the theory of the org.. Another thought this brings up for me is the saying, "if you have data let's discuss it, if you have an opinion let's go with mine." But of course data has its own limitations and secondary effects..

@Personal Dynamic Media I agree. I think all decisions in a tech org are technical decisions. Product decisions cannot be separated from their technical implementations. Even priority and roadmap are massive technical decisions. Implementing feature A -> B -> C can be 10 times faster than doing feature C -> B -> A (especially if you are blind to the end state of #{A B C})

That was so well-put. Thanks. I was a little confused by the mentions of “architect, engineering manager, project manager, VP of , C*”. I relate to the frustration of feeling alien in a code base built with theories that I don’t yet understand or simply disagree with, but I’ve never felt like I was put there by a project manager or CEO. Did I have the wrong idea of what you meant when you described an alien world, or do I not understand the relevant pressures that people in non-engineering roles apply to software?

Thanks @alltom 🙂 I could have even put "senior engineer, staff engineer, principle engineer" on that list so I don't think of it as non-engineering roles, but roles with more power than you. I definitely think you are right that it is an alien world. But I think the world can be made alien even in greenfield development by the pressures those with power impose on you. I can think of many examples in my career personally, but I admit it might not be the experience of everyone. For example, I worked on the reporting system for a small ad-tech company. The setup was a mess and no customers liked it. We had big plans that would have made it actually useful for our customers. Everyone time we presented them to the ceo, he told us as long as the customers wanted it, we could do it. But then when the roadmap was made, he replaced everything we wrote with his own plan. Working on those features was depressing.

What I meant by the data quote is the unfortunate tendency to think the only opposite of data is opinion. I think that's one reason any debate around competing theories gets shut down by incumbents.

Ahh, yeah, I definitely agree with that. I've never liked that quote for that very reason 🙂

I dug this; but I guess my 1 point of…frustration?…disagreement? is that maybe there is a way to reframe this that brings more people to the table, rather than excludes folks?

Our primary activity is not the making of things, but of thinking about how the thing ought to be made. We are building up this theory as an interested party, we are crafting the world into the way we want it to be. Or at least that’s what we want to do.

Could a more diverse group of folks build a theory together? Are the programming-intelligentsia the only ones allowed to contribute to a theory? In my work I’m tasked with making services folks are obligated by their government to interface with as accessible as possible…but I’m often locked out of the room until the very last minute, as such, the influence I can have on theory-building is left until after the theory has crystalized, and almost always without facets that include my purview and expertise. Could theory building be made more intentional and expansive, like an actual step in the process of building software, and in this way include more voices?

Could theory building be made more intentional and expansive, like an actual step in the process of building software, and in this way include more voices?

I would argue that including more people is exactly what is needed. The problem is that the management intelligenceia often believes that since they have an MBA they can manage anything and they don't need to include the perspective of programmers or other technical people. I have literally heard people say that technical issues should not be considered when making business decisions because the business should drive the technology and the technology should not drive the business. The result is invariably disastrous for both the technology and the business.

Ah, legit — in agreement on this 🫶

> Could a more diverse group of folks build a theory together? Are the programming-intelligentsia the only ones allowed to contribute to a theory? I've got so many thoughts on this that I'm afraid by me saying so much it will sound like a long winded no, so let me just start by saying yes, a diverse group should be involved in this 100% agreed. First, I definitely agree the framing doesn't talk about this. This post was very much written at a time a frustration and is a personal post for me. As for can folk build a theory together, I think this is an important question, but much easier said than done. In theory, this is what "cross functional" teams are supposed to do. by having qa, accessibility, legal, dev, product, etc involved it is supposed that we are now gaining the theories all these groups have into some mega theory. I don't think it is that easy. The key reason is that theories aren't articulable. They are know how's. Your knowledge of accessibility isn't something can simply be written down in a brief before the project. Certainly you can make recommendations and try to provide guidelines, but I'm sure much would be left out. If you are not directly involved in building the artifact, your know-how will be left out. > Are the programming-intelligentsia the only ones allowed to contribute to a theory? I definitely hope not! But I think we have to accept that there is a real bottleneck here. One that can't be easily worked around. The programmers will build the system, and along with that will implicitly instill their own values into the system. Their understanding of the world will infect the system. So, how can we fix this? Sadly it does involve changing those programmers. Part of this is of course by exposing programmers to those with other desires, perspectives, needs. (This is why I'm not a fan of "product", they filter everything a programmer sees). But I don't think process and requirements are the ultimate fix. We need the people building the system to internalize more. To for example, include in their world the importance of accessibility. We need to raise their consciousness. > Could theory building be made more intentional and expansive, like an actual step in the process of building software, and in this way include more voices? I sadly don't think a step in the process is enough. I think we have to inculcate the habits of taking others perspectives, of reaching out to folk who may be impacted by these decisions, of pausing and researching before making decisions, of taking a broader perspective. Should programmers be the only one to contribute to the theory? Of course not! But since at the end of the day they build the system, if we don't fix who they are, their habits of thought, their process of theory formation, we will always end up with these bad results. Finally, as for a shared theory, this is something I think is quite difficult and want to explore at some point on the podcast. Theories are know-hows, so wouldn't a shared theory simply be the collective know-how of a group? I don't think that's the case. But, I do think you can create the circumstances where this can be true. There's talk in HCI of "Distributed Cognition". Need to spend the time to find the right paper for it. But basic idea is that some groups can form distributed cognition where the know-how is spread out. Pilot, co-pilot, and the planes instrumentation are one classic example. But I don't think it applies to just any arbitrary set of people.

@Jimmy Miller firstly, loving this answer. Thank you for taking the time to share it!

But I think we have to accept that there is a real bottleneck here. One that can’t be easily worked around. The programmers will build the system, and along with that will implicitly instill their own values into the system. Their understanding of the world will infect the system.

I wonder if this bit points back to the future of coding, and the role tools play in helping to reveal, craft, and make “real” theories? Especially the last bit,

Their understanding of the world will infect the system.

What if a tool could be inoculated with different understandings of the world; Marshal McLuhan style, the medium is the message, wherein the tool could be configured with parameters that help guid theory making?

But I don’t think process and requirements are the ultimate fix. We need the people building the system to internalize more.

HUGE agree here — one of the major differences in the space where I’m at now versus other places I’ve worked in the past is that teams often include, or are sometimes almost all made up of researchers — sometimes with diverse backgrounds of previous experience. The skillset and insights these folks are able to synthesize is wild and often times remarkable.

Should programmers be the only one to contribute to the theory? Of course not! But sense at the end of the day they build the system, if we don’t fix who they are, their habits of thought, their process of theory formation, we will always end up with these bad results.

I read this (and agree) that this is because the the programmers often have the responsibility of making the theory “manifest.” The shared theory thing is defo my personal point-of-interest with the whole future of coding thing. I don’t have much cogent to say about it, but am starting to think that a big bit of tension (especially when looking to Naur) is, perhaps, the specificity of a theory — like “real” theories are diffuse and a bit more ephemeral than the word’s more general usage lets on.

Zooming out a bit, I've spent a lot of time in my career reflecting on why some of the authors whose work I most respect have values so antithetical to mine. Some candidate answers (warning, not very uplifting): • Life in small groups is better than life in large ones precisely because of impositions like this -- except for the fact that large groups have a way of outcompeting small ones. Feels a bit analogous to large cities conquering their smaller neighbors, though the consequences aren't quite as drastic these days as they were for say the Helots that competed with Sparta[1]. Not that larger is always better, just that sizes larger than some threshold seem correlated with success. Maybe small groups have to get lucky to attract a great programmer, but the odds favor large groups to do so. Every hire is a gamble, worst case is usually bounded, but best case you hire Jeff Dean. (I don't really believe this. Even Jeff Dean requires the right culture to become. But I worry. Is it possible I'm on the wrong side of history here? Here, I'll see and raise your melodrama.) • Similarly, perhaps it makes sense to have such rules because the time of a good architect maintaining a coherent vision is on balance more valuable than the cost to morale of most of the team. Having any theory is better than descending to cacophony. Again, I don't really think so, but I worry. The common thread between such thoughts is the observation that morale problems seldom seem to sink orgs. Is it just the "market" staying irrational longer than I can perceive but eventually returning to reality? Or does everyone else know something I don't? [1] https://en.wikipedia.org/wiki/Sparta#Helots

this is beautiful, thanks for sharing