I feel like so much of the process was un-learning things that I've learned. The restraint of not reaching for the complex tools I'm used to - the ones that I want, but slow me down, and make things worse.

Maybe this should have been a #thinking-together

I’m glad there were whole sections on the slippiness of val town. :) I wanted to know your analysis! I was kind of expecting PHP or CGI or something.

Love it! I've had similar experiences putting aside "my default web tooling" and start from scratch. If it’s interesting in any way, I've been documenting some optional/light weight frontend patterns that have helped me

github.com/ChrisShank/progressive-element

Cool to see val town used this way! 🙂

(Also the repo i linked has a pretty vanilla TodoMVC implemented, if your looking for “classic examples” it could be easy to port it. Also 7 GUIs is a classic eugenkiss.github.io/7guis)

Tom Lieber thanks! hopefully the takeaway is why I think val town helps me be slippy. many other things can be too! i don't know php very well and i don't know what cgi stands for. (actually i don't know what php stands for either, come to think of it) so maybe other people will be able to share how to use those in a slippy way too some day :)

Christopher Shank nice! i recently made a todo app too, so we can compare notes. (try it here).

maybe you saw my other examples.

i didn't know about these 7 challenges!!! thank you, that's very helpful. I'll give them a go RIGHT NOW

3 done so far! will do the rest later :)

todepond.com/wikiblogarden/tadi-web/hello-world/seven

view source to see the code. if it seems like there's nothing special or clever happening, that's the point!

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})

Kartik Agaram Yeah our theory includes how the program relates to the world broadly, so it definitely includes things like the relative priority of new features, bugs etc.

I'm not sure I see the connection to the data quote. But of course you know I have issues with quantitative measures 🙂

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 Tom Lieber 🙂

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 :heart_hands:

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.

And if a theory is diffuse, I wonder if it could be transmitted like a curriculum, where, in order to be brought in on the theory after it was made you could be presented with something like “take this online course, watch these youtube videos, listen to this song, read this book, talk to Gessel from accounting about December 1984. ”

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] en.wikipedia.org/wiki/Sparta#Helots

this is beautiful, thanks for sharing

As usual, most of the action is in the show notes

• MUMPS (the medical thing, not to be confused with mumps the medical thing) is used by Epic (the software company, not to be confused with Epic the software company).

MUMPS is the only old school programming system I’ve ever learned that’s actually come in useful at work!

A mythconception that chaps my bottom: I think programming, software engineering, and computer science are three different things, but people insist on using the terms interchangeably. 😞

Yeah. I see the distinction, and I'm guilty of sloppily using the terms. Good reminder.

I see distinctions but am not sure I’m landing at a similar set of distinctions as other folks — do you all feel that there is a sort of “happy path” or “right meaning” to each term?

Just finished the paper, looking forward to this monster of an episode. Thinking about the diff between vernacular and professional, and how one might move between those roles and the contexts in which that would happen.

Jack Rusher together we are unstoppable. the coding trinity

@Eli Mellen there’s definitely a specific way that I think about them, but it doesn’t conform to any standard understanding, so… 🤷‍♂️

programming, software engineering, and computer science are three different things

Yeah that is a good myth 😉

Well, I was listening to the episode and then I went and watched the Cell Pond talk and during the questions I learned about the game Baba is you which I then spent a lot of time figuring out how to give to some younger people I know.

Eventually I will pop the stack and finish the episode, but it's been fun so far!

In my field there is a language called Catala, written in a functional language, designed so that one step of the transpilation process from Catala to other languages can be proved correct. One step. Why? As far as I can tell, academic novelty. It doesn't solve any real world problem in the domain it is supposed to serve, and the downsides of encoding laws this way are considerable. That is an example of mathematical tractibility for its own sake. The language was designed by a person getting a PhD in formal methods. There are levels of formality, but that level just isn't helping. Do they believe the myths? No, probably not. But they might benefit from reading the paper anyway.

Perhaps worth noting that there are a few small subdomains where formal methods are both important and helpful. Two that come to mind are cryptography and synchronization primitives.

On an adjacent topic, this talk by John Regehr about the economic aspects of correctness in compilers is a nice twist and generally pretty impressive. youtu.be/tMYYrR-hazI?si=Lt6who6-xv1ZVPBe

I haven’t finished the podcast yet (3 hrs = multiple sessions!), but while listening I was wondering about bringing fuzzing to vernacular programming.

At its heart it is a simple technique—list some things that ought to be true and then let the computer burn cycles double-checking your work—and one that systematically saves time and catches bugs for professional programmers (or at least for those who bother to use it).

And fuzzing is almost an anti-formal-method: just throw lots of stuff at a program and see what breaks, practical engineering trade-offs everywhere you look. :)

My take on CS vs SE vs programming: reddit.com/r/AskComputerScience/s/Vf7q3tWBPc

The distinctions between them are rarely discussed, but they're deeply orthogonal

Quasi-related and illustrative: I find being able to type really fast is helpful in my career. It's almost never load-bearing but sometimes I know it helps a lot that I can get stuff out "on paper" very quickly

Alan Kay once said science is what's real, math is what's true, and engineering is what's possible.

I'm not convinced that computer science is science. Here's one amusing discussion about this.

wiki.c2.com/?IsComputerScience

I also love the first minute or two of this SICP lecture where Hal Abelson talks about the term computer science. (This was before he sold his soul in the Aaron Swartz investigation, so I like to believe that the person giving this lecture was a good man at the time.)

m.youtube.com/watch?v=-J_xL4IGhJA&list=PLE18841CABEA24090&index=1&pp=iAQB

I'm also not convinced that software engineering is engineering. Here's another good read from C2.

wiki.c2.com/?SoftwareEngineering

Personally, I just use whatever words the people around me are using. They probably aren't working from a rigorous definition anyways.

If you haven't watched/read it yet Hillel Wayne has been doing great work exploring the question of real engineering vs. bullshit software engineering (my preferred term for what I do 😉) ... in part by interviewing quite a few real engineers who also write software:

• blog post 1/3 (2021): hillelwayne.com/post/are-we-really-engineers
• talk (2023): youtube.com/watch?v=CmIGPGPdxTI&ab_channel=GOTOConferences

• slides: onedrive.live.com/view.aspx?resid=7E5188E64FF71F3A%21457159&authkey=!ABog_uhJFm6grFk

A wonderful paper by Mary Shaw, one of my great inspirations. Looking forward to your insights.

One of the really puzzling things about her earlier software architecture work was the insistence that although connectors deserve first class status, programming languages and architecture description languages were considered completely different . Though they are clearly analogous and the architecture side a generalization of the programming side.

And then the whole CMU gang went off the SEI end…

To me, this paper and the talk were Mary coming back to true form, a tour de force with many crucial insights.

My favorite one of course was the one about the myth that programming is writing procedures. The Gentle Tyranny of Call/Return one might call it 🙂.

My favorite one of course was the one about the myth that programming is writing

procedures. The Gentle Tyranny of Call/Return one might call it

Oh it's not gentle! Tail calls enable entire architectures that are impossible when everything needs to be hierarchical.

On the idea of measuring "good enough", I think we need to look to design for advice. We need to empathize with the users, and design toward improving their subjective experience. A user told me once that my tool made him feel like he had super powers. The tool was (and remains) buggy as hell (a block-based visual DSL), but it was good enough, because that feeling motivates use. Use generates feedback, and feedback will help you find and fix incorrectness. So the software doesn't need to even be good enough right away. The process just needs to be self-sustaining and tend toward good enough. So I would argue new ways of measuring good enough may still be too correct a goal. The real thing is fuzzier. Have a user you care about. Fuzzy. Try to make them feel something good. Fuzzy. Learn with them. Fuzzy. Repeat. Correct is a myth, but do the fuzzy thing, and good enough will eventually emerge.

Well, I'm 2 hours into the podcast and I've read a smattering of pages from different parts of the paper.

My sense is that the author is actually criticizing modern academic programming language researchers, but falsely generalizing her criticisms to all programming language researchers and implementers in all parts of history.

This paper seems to have been written in a world full of languages like Pascal, ML, and Haskell where all professional programmers work top down from a specification through a process of stepwise refinement as advocated by folks like Wirth and Dijkstra.

It seems to completely ignore the massive amounts of casual, exploratory, and bottom up program design that have been a major force within the Lisp, Logo, Smalltalk, Forth, SNOBOL, Perl, Python, Ruby, Unix, Emacs, and awk communities for decades. (And I almost certainly missed at least a few others.)

It also ignores older academic and industry work focused on writing programs that are easy to modify in the face of changing specifications (Parnas, SICP, Dijkstra, Brodie, etc.).

It also ignores the long history of Unix programmers saying "the environment IS the IDE." During the editor wars, it was common for the Emacs fans to point out that VI was very limited by comparison unless it was calling out to external programs. The VI fans would counter that calling out to external programs was the proper Unix way to do things rather than reinventing the world within your editor. Unix programmers have been hyper aware of their development and execution ecosystem, and not just their programming language, for the better part of 50 years.

It also ignores escape hatches within vernacular programming systems. Does someone stop being a vernacular programmer when they decide that Excel formulas are no longer enough and they need to use some VBA?

I think there may be some validity to this paper as a criticism of mathematical naval gazing within the ivory tower, but I'm not sure it says much about the industry as a whole or even programming language designers in general.

[The Gentle Tyranny of Call/Return] …is not gentle! Tail calls enable …

Maybe I should have titled the paper “The Subtle Tyranny of Call/Return” instead? As in you are trapped by it even when you think you’ve escaped…

falsely generalizing her criticisms to all programming language researchers and implementers in all parts of history.

I don’t think that is warranted. She is always clear that what she describes and criticizes is “typical”, not “all”. For example: “Traditional general-purpose programming languages, or at any rate the ones of most interest to programming language researchers…“. Next: “Mainstream languages are usually designed…“. And so on and so forth.

don't think that is warranted. She is always clear that what she describes and criticizes is "typical", not "all". For example:

"Traditional general-purpose programming languages, or at any rate the ones of most interest to programming

language researchers..." Next: "Mainstream languages are

usually designed...". And so on and so forth.

Perhaps I should have said "most," but I think my point still holds. The most popular programming languages among programmers are not of much interest to today's academic programming language researchers, and are not particularly mathematically tractable.

Well, I finished the episode and when Jimmy started asking "who actually believes these myths?" I was right there with him. I'm not even sure that most academic language researchers believe them. I think they might just act like they believe them because their attention is naturally drawn to things that they can write mathematical looking papers about because mathematical looking papers appear to be more "serious" research.

An anecdote on that front: I'm not on the Go team, but I contributed very heavily to the toolchain and have a fair amount of visibility. When Go was adding generics, it went through multiple years of deliberation over clarity, usability, usefulness, and compile time. Everything was focused on the developer experience, with lots of concern given to approachability for less experienced programmers. Only once the team was reasonably happy on that front did they go find some type theorists to double-check that what they'd created wasn't going to blow up on them later. It felt (from the outside) more like a box-ticking exercise.