By complete coincidence, yesterday I came across this link to an article Peter Naur wrote in 1985 (https://pages.cs.wisc.edu/~remzi/Naur.pdf) which I haven't been able to stop thinking about.
I've been doing this for coming up on thirty years now, mostly at one large company, and I spent a significant number of hours every week fielding questions from people who are newer at it who are having trouble with one thing or another. Often I can tell immediately from the question that the root of the problem is that their world model (Naur would call it their Theory) is incomplete or distorted in some way that makes it difficult for them to reason about fixing the problem. Often they will complain that documentation is inadequate or missing, or that we don't do it the way everyone else does, or whatever, and there's almost always some truth to that.
The challenge then is to find a way to represent your own theory of whatever the thing is into some kind of symbolic representation, usually some combination of text and diagrams which, shown to a person of reasonable experience and intelligence, would conjure up a mental model in the reader which is similar to your own. In other words you want to install your theory into the mind of another person.
A theory of the type Naur describes can't be transplanted directly, but I think my job as a senior developer is to draw upon my experience, whether it was in the lecture hall or on the job, to figure out a way of reproducing those theories. That's one of the reasons why communication skills are so critical, but its not just that; a person also needs to experience this process of receiving a theory of operation from another person many times over to develop instincts about how to do it effectively. Then we have to refine those intuitions into repeatable processes, whether its writing documents, holding classes, etc.
This has become the most rewarding part of my work, and a large part of why I'm not eager to retire yet as long as I feel I'm performing this function in a meaningful way. I still have a great deal to learn about it, but I think that Naur's conception of what is actually going on here makes it a lot more clear the role that senior engineers can play in the long term function of software companies if its something they enjoy doing.
Isn't that interesting? The job of exploring a theory or model to such an extent that it can be expressed in computer code always seems to fall on the shoulders of a software developer. Other people can write specifications and requirements all day long, but until a software developer has tackled the problem, the theory probably hasn't been explored well enough yet to express clearly in computer code. It feels like software developers are scientists who study their customers' knowledge domains.
> It feels like software developers are scientists who study their customers' knowledge domains.
I agree so much with this. It's why I feel so stifled when an e.g. product manager tries to insulate and isolate me from the people who I'm trying to serve -- you (or a collective of yous) need to have access to both expertise in the domain you're serving, and expertise in the method of service, in order to develop an appropriate and satisfactory solution. Unnecessary games of telephone make it much harder for anyone to build an internal theory of the domain, which is absolutely essential for applying your engineering skills appropriately.
Another facet of this is my annoyance at other developers when they persistently incurious about the domain. (Thankfully, this has not been too common.)
I don't just mean when there are tight deadlines, or there's a customer-from-heck who insists they always know best, but as their default mode of operation. I imagine it's like a gardener who cares only about the catalogue of tools, and just wants the bare-minimum knowledge to deal with any particular set of green thingies in the dirt.
This is why at my current place we are not supposed to do any dev without an SME on the call. We do the development and share the screen and get immediate feedback as we are working in real time! It's great.
This might be an indicator that PM isn't doing their job; PM should be able to answer you questions regarding what the business wants (= people who you're trying to serve). Developers, by the nature of interacting with domain, do become experts in the domain, but really it should be up to PM what the domain should be doing business-wise.
If that is what a PM needs then there aren't enough good PM to warrant a PM role for most products, so just make software engineers do that in most cases.
Edit: The main role of PM is to decide which features to build, not how those features should be built or how they should work. Someone has to decide what to build, that is the PM, but most PM are not very good at figuring out the best way for those features to work so its better if the programmers can talk to users directly there. Of course a PM could do that work if they are skilled at it, but most PM wont be.
So that we're on the same page, what I think should be PM responsibilities:
If I have a user story: "As a customer I want to purchase a product so that I can receive it at my address" - PM defines this user story as they have insight to decide if such feature is needed.
PM should then define acceptance criteria: "Given customer is logged in When they view Product page Then 'Add product to basket' button should appear", "Given 'Add product to basket' button When customers click on it Then Product information modal should appear" etc - PM should know what users actually want, ie whether modals should appears, or not; whether this feature should be available for logged users only, or not.
How this will work shouldn't matter to PM; these are AC they've defined.
Of course the process of defining AC should involve developers (and QA), because AC should be exhaustive to delivering given feature
The problem, in my experience, is that most PMs don't add anything when it comes to drawing up the acceptance criteria.
In your example of an order placement - the PM has no special knowledge of what is a good customer order flow. Developers are usually way better at coming up with those by the dint of experience and technical knowledge of the current codebase and make the appropriate speed/polish trade-off.
PMs acts as an imperfect proxy for what the customer wants, making judgements off nothing more than their own taste. And though there are many great PMs, the taste of a PM is usually worse than that of developers and designers on average.
IMO the main business reason they exist is for organization accountability and ownership, despite the often negative value they bring.
Even the most verbose specifications too often have glaring ambiguities that are only found during implementation (or worse, interoperability testing!)
Sorry this is just the interior trapped nonsense that engineers find themselves in. Please touch grass
Product designers have to intuit the entire world model of the customer. Product managers have to intuit the business model that bridges both. And on and on.
Why do engineers constantly have these laughably mind blowing moments where they think they are the center of the universe.
I agree so much with the both of you, to the point it's difficult to avoid cognitive dissonance one way or the other.
Software people do what they do better than anyone else. I mean obviously! Just listening to a non-software person discuss software is embarrassing. As it should be.
There's something close to mathematics that SWEs do, and yet it's so much more useful and economically relevant than mathematics, and I believe that's the bulk of how the "center of the universe" mindset develops. But they don't care that they're outclassed by mathematicians in matters of abstract reasoning, because they're doers and builders, and they don't care that they're outclassed by people in effective but less intellectual careers, because they're decoding the fundamental invariants of the universe.
I don't know. I guess I care so much because I can feel myself infected by the same arrogance when I finally succeed in getting my silicon golems to carry out my whims. It's exhilarating.
We keep seeing things like cryptic error messages shown to end users simply because of the disconnect between the programmer and the end user.
If the programmer gets to intimately understand the user's experience software would be easier to use. That's why I support the idea of engineers taking support calls on rotation to understand the user.
Both can be true at the same time, a product manager who retains the big picture of the business and product, and engineers who understand tiny but important details of how the product is being used.
If there were indeed perfect product managers, there would no need for product support.
>We keep seeing things like cryptic error messages shown to end users simply because of the disconnect between the programmer and the end user.
A lot of the error messages I'd write were for me, especially those errors I never expected to see.
The typical feedback I'd get from end users is "your software doesn't work". If they can send me a screenshot of the error I'm halfway to solving the problem.
I actually agree with this. Product designers and product managers are often essential and sometimes they do up to 99% of the work of figuring out how something should work. To accomplish that, they often do things well outside the role of a software developer. On the other hand, in my experience, only someone with a software development mindset seems to be able to complete the last 1% (or 10%, or whatever) that reveals and resolves certain kinds of logic issues.
You seem to be assuming a certain org structure with very clear, specialized roles. Many teams do not have this, and engineers are already Product Engineers. It sometimes even makes sense (whenever engineers dogfood their product, startups, or if it is a product targeting other engineers) and is not just a budget/capacity issue.
Similarly, by siloing the world model in one or two heads, you disable the team dynamics from contributing to building a better solution: eg. a product manager/designer might think the right solution is an "offline mode" for a privacy need without communicating the need, the engineering might decide to build it with an eventual consistency model — sync-when-reconnected — as that might be easier in the incumbent architecture, and the whole privacy angle goes out the window. As with everything, assuming non-perfection from anyone leads to better outcomes.
Finally, many of the software engineers are the creative type who like solving customer problems in innovative ways, and taking it away in a very specialized org actually demotivates them. Many have worked in environments where this was not just accepted, but appreciated, and I've it seen it lead to better products built _faster_.
It's interesting that the way you describe it, the world model itself is _not_ just a collection of words in our minds, and I have a small theory of my own that "thoughts" in our brains aren't actually words at all (otherwise animals which don't talk wouldn't be able to make complex decisions?), and the words that we "hear" in our heads and which we perceive as our thoughts are just a rough translation of these thoughts into words, they aren't thoughts themselves. It is also why it's sometimes really hard to put complex (but correct) thoughts into words, and especially hard to adequately compare complex ideas during a regular conversation: on the surface a lot of ideas (especially in software engineering) "sound" good, but they're actually terrible. And there's no better way to communicate ideas than to put them into words, which is probably what makes good software engineering extremely difficult.
Regarding the tension between symbolic representation and Naur "theory", I'd actually say they come from two different traditions, each providing two different theses. When writing them out I think it becomes a bit clearer how they interact and that they're not actually contradictory.
Thesis A is something like: the value of the programmer comes from their practical ability to keep developing the codebase. This ability is specific to the codebase. It can only be obtained through practice with that codebase, and can't be transferred through artefacts, for the same reason you can't learn to play tennis by reading about it (a "Mary's Room" argument).
This ability is what Naur calls "theory". I think the term is a bit confusing (to me, the word is associated with "theoretical" and therefore to things that can be written down). I feel like in modern discourse we would usually refer to this as a "mental model", a "capability", or "tacit knowledge".
Then there's Thesis B, which comes more from a DDD lineage, and which is something like: the development of a codebase requires accumulation of specific insights, specific clarifying perspectives about problem-domain knowledge. The ability for programmers to build understanding is tied to how well these insights are expressed as artefacts (codebase structure, documentation, communication documents).
I feel like some disagreements in SWE discourse come from not balancing these two perspectives. They're actually not contradictory at all and the result of them is pretty common-sensical. Thesis A explains the actual mechanism for Thesis B, which is that providing scaffolding for someone learning the codebase obviously helps, and vice-versa, because the learned mental model is an internally structured representation that can, with work, be externalised (this work is what "communication skills" are).
>their world model (Naur would call it their Theory) is incomplete or distorted in some way that makes it difficult for them to reason about fixing the problem
Of course the model is incomplete compared to reality. That's in the definition of a model, isn't it? And what is deemed a problem in one perspective might be conceived as a non problem in an other, and be unrepresentable in an other.
Everyone should subscribe to the Future of Coding (recently renamed to the Feeling of Computing) podcast if you haven't already: https://feelingof.com/
I keep saying this is the single most important article to consider when talking about AI assisted software building. Everyone should read it. The question should always be: is a human building a theory of the software, or is does only AI understand it? If it's the latter, it is certainly slop.
(Second, albeit more theoretical, would be A Critique of Cybernetics by Jonas)
I haven't actively looked into it, but on a couple of occasions after google began inserting gemini results at the top of the list, I decided to try using some of the generated code samples when then search didn't turn up anything useful. The results were a mixed bag- the libraries that I'd been searching for examples from were not very broadly used and their interfaces volatile enough that in some cases the model was returning results for obsolete versions. Not a huge deal since the canonical docs had some recommendations. In at least a couple of cases though, the results included references to functions that had never been in the library at all, even though they sounded not only plausible but would have been useful if they did in fact exist.
In the end, I am generally using the search engine to find examples because I am too lazy to look at the source for the library I'm using, but if the choice is between an LLM that fabricates stuff some percentage of the time and just reading the fucking code like I've been doing for decades, I'd rather just take my chances with the search engine. If I'm unable to understand the code I'm reading enough to make it work, it's a good signal that maybe I shouldn't be using it at all since ultimately I'm going to be on the hook to straighten things out if stuff goes sideways.
Ultimately that's what this is all about- writing code is a big part of my career but the thing that has kept me employed is being able to figure out what to do when some code that I assembled (through some combination of experimentation, documentation, or duplication) is not behaving the way I had hoped. If I don't understand my own code chances are I'll have zero intuition about why it's not working correctly, and so the idea of introducing a bunch of random shit thrown together by some service which may or may not be able to explain it to me would be a disservice to my employers who trust me on the basis of my history of being careful.
I listened to an interview with the woman who was at the time I believe overseeing the efforts of the Audio Engineering Society to address the problem of the countless recordings made on proprietary digital audio tape machines like the Sony PCM-3348. The total number of those machines that were ever built was small since so few studios could afford them, but they were major studios and thus the masters of many of the most culturally significant albums are on tapes in that format.
She mentioned that even if you could find one of the machines that was working, keeping it running required routine maintenance and that they were down to essentially one guy who was nearing the age of retirement who had the skill and parts to keep one running. So they were in a race against time to figure out which masters to convert.
The problem gets even more thorny for sessions that were recorded using software like ProTools, which has been around in some form or another for almost 40 years, has gone through countless revisions of project file formats, and has a complicated relationship with specialty audio hardware and software plugins.
It seems like there's a general awareness of the problem now and good studios are taking some measures to archive sessions in ways that allow them to be imported in the future, but in the meantime there are two decade's worth of recordings at risk, even if their media hasn't been lost or corrupted. I guess if nothing else its a cool opportunity for people who like to hack on systems of this type though.
All of the recording I did for my friends back in college is stuck in Nuendo/Cubase projects with a bunch of long-obsolete plugins used for mixing and mastering. Going forward I'm going to print every individual track to PCM so that I have a "digital tape" of the entire session to avoid this problem.
I learned of Michael Levin via Sally Adee's "We Are Electric", one of the more interesting pop-sci titles I've read in a while, the section on Levin's lab was definitely the highlight.
i'm also an audio nerd and although I do everything in the box when i'm recording, i agree completely that it's way easier to use outboard stuff for this case. i had an analog channel strip but decided to try one of the very inexpensive behringer uv1 strips with an integrated usb interface and it's been great, the gate and compressor work well, and i have a rolls audio parametric eq in the effects loop to high pass and de-essing.
since it's convenient to use the headphone out on the uv1 for the headset, i do use a limiter plugin in Rogue Amoeba Soundsource to compress the output from the conferencing software we use, it's nice being able to do that per-application since i listen to music through the headset a lot and don't want to have to take the limiter in and out.
analog headsets are so much less annoying and flexible, huge fan
I've struggled to teach this to jazz students, I know when I was a kid I read the same kind of advice in guitar magazines, and while I don't think that the theory-first advocates are malevolent, I think most of them were not serious jazz players and were getting paid to deliver a monthly column.
The analogy I've tried to use in teaching is that learning to play jazz is like being a comedian; when your skills are at their peak you're going to be inventing jokes regularly, but in the decades before you get there, you're going to be delivering other people's jokes putting a little of your own spin on them. The delivery matters a lot, and like good jazz playing it's pretty much impossible to write a book called "How to be Funny" that wouldn't just be an academic analysis rather than an instructional guide.
I struggled with jazz for the reasons I've alluded to above, and it wasn't until I started studying with a teacher who just had me memorize hundreds of standards that I got my playing together. We definitely talked about the technical bits of what was happening in the tunes, but those were really just interesting observations; repeatedly playing them in a group setting after woodshedding them at home between lessons, then taking a lot of solos was really what made it happen.
It really makes me happy to see up-and-coming killer players like Patrick Bartley espousing this same approach. Yeah it means you're going to spend thousands of hours memorizing tunes, but if that's not fun then playing jazz isn't going to be fun either.
As I alluded to in another comment, you are fighting upstream against the dominant Western conception of learning. But any musician I have ever met worth their salt knows the importance of learning songs and transcribing their favorite artists.
I think one of the causes is that some people struggle for years with music and then one day they learn a bit of theory and they experience a moment of enlightenment. Suddenly, all of their confusion is dispelled and what was once difficult is clear as day. They then think "if I had only know this years ago I wouldn't have struggled!". But they are wrong. It was the years of struggle that helped them understand the theory, not the other way around.
It's the "wax on, wax off" of Karate Kid and the wise old Mr. Miyagi.
I read a music theory book from the 1800s and in the first chapter the author stated that while he endeavored to write useful theory to help students they must realize that if some composition they write follows all of his rules but sounds bad, it is bad. And if they write a composition that breaks his rules but it sounds good then it is good. These are old, old ideas that we re-learn over and over.
I’ve played mostly hard rock and metal, and am often the only band member with actual music theory knowledge (as the drummer, no less!). I’ve watched a number of bandmates resist learning any music theory because, “I don’t want to have to play by the rules” - as if they were some 16th century court composer.
Inevitably, they end up reinventing the wheel, in order to understand music they learn or write and then share with other musicians.
I think one thing that gets lost is that beyond being rules (more like observations these days) about how to write music, music theory is also a language that allows you to communicate with other musicians.
Good analogy. There's a flip side to it though. You can be a great comedian on the level of individual jokes, or short bits, but be unable to write a story. And you can be a great jazz musician when it comes to soloing, but be unable to write a song. Stan Getz was a famous example. So yeah, learning jazz by imitation and immersion (as one learns a language) is very cool: learning these hundreds of songs will most certainly teach you how to solo. But it won't teach you how to make a song. Not nearly as reliably. It needs something else, I don't know what.
I don't know quite what it is either, but I do know with certainty because it was my own experience that the act of inventing songs doesn't require any kind of experience at all, as some of my earliest memories as a child were riding in a car with a radio playing in the background, having some melody occur to me, and then being unable to get it out of my head. They weren't novel because they wouldn't have come to me had I not been idly listening to a lot of music, but neither were they just a slight variation on what I had been listening to.
I am by no means a prolific or genius songwriter, nobody would know any of my music, and I don't believe that any of it is particularly impressive. However I've always found the fact that it happened spontaneously way to be a source of wonder, and as I've aged as a musician its delightful to see the endless stream of new songs and that it doesn't seem to matter whether you're a prodigy when it comes to writing songs that impact listeners. It seems to be a fundamental aspect of the human experience.
I grew up in this area of West Virginia, it's such a crazy thing that a community of really amazing scientists are nestled in the middle of this incredibly rural area. It's really neat to see the old blue trucks if you take the tour, and the Cass Scenic Railroad is just nearby and gives a really beautiful view of the telescope array. The National Youth Science Academy Camp is also surprisingly located nearby, it was wild as a kid knowing that this batch of future scientists were flying in from all over the country and once I learned of it I wished I'd studied a bit harder. Such a beautiful, strange place.
I've been doing this for coming up on thirty years now, mostly at one large company, and I spent a significant number of hours every week fielding questions from people who are newer at it who are having trouble with one thing or another. Often I can tell immediately from the question that the root of the problem is that their world model (Naur would call it their Theory) is incomplete or distorted in some way that makes it difficult for them to reason about fixing the problem. Often they will complain that documentation is inadequate or missing, or that we don't do it the way everyone else does, or whatever, and there's almost always some truth to that.
The challenge then is to find a way to represent your own theory of whatever the thing is into some kind of symbolic representation, usually some combination of text and diagrams which, shown to a person of reasonable experience and intelligence, would conjure up a mental model in the reader which is similar to your own. In other words you want to install your theory into the mind of another person.
A theory of the type Naur describes can't be transplanted directly, but I think my job as a senior developer is to draw upon my experience, whether it was in the lecture hall or on the job, to figure out a way of reproducing those theories. That's one of the reasons why communication skills are so critical, but its not just that; a person also needs to experience this process of receiving a theory of operation from another person many times over to develop instincts about how to do it effectively. Then we have to refine those intuitions into repeatable processes, whether its writing documents, holding classes, etc.
This has become the most rewarding part of my work, and a large part of why I'm not eager to retire yet as long as I feel I'm performing this function in a meaningful way. I still have a great deal to learn about it, but I think that Naur's conception of what is actually going on here makes it a lot more clear the role that senior engineers can play in the long term function of software companies if its something they enjoy doing.