In 2016 I wrote "Programming Beyond Practices" for O'Reilly.
It deliberately includes *no code samples* -- only discussions, design decisions, analysis, etc in story form.
Many of its ideas are still relevant. You can find the PDF here (free, no signup needed):
@simeon A decade later my focus is now on trying to teach code reading to a level of proficiency that people can hold a very clear mental model in their head of how systems work.
Two (very different) sides of the same coin, and it was fun to go deep on the opposite end back then.
@skillstopractice Iām almost finished with your book and I love it because it shows that developing software is much, much more than producing code. Itās a shining light amidst all the āgenAI will replace you pesky developerā doom and gloom.
As for the other side of the coin: I feel weāll be needing these skills a lot in the not too distant future.
@simeon If you haven't read the last chapter yet I don't want to spoil it for you but I had a spot-on prediction of the development trends a decade ago but I can tell you my reaction has been... "No! No! Not like that!"
Because what has happened, has only similarities at the surface level to what I was trying to express. And fundamental incompatibilities with what I think will make things genuinely human-centric.
(That said, I still believe we can get there)
@simeon Will attempt to collect my thoughts in a more complete way and send a link when I do, but the short story is I thought the only probabilistic element of that kind of workflow would have been matching natural language to corresponding APIs, and I had hoped we would have built high level enough tools in all other ways that stacked like Lego bricks all the way up to the surface.
By contrast, GenAI drags us deep down into the Turing tarpit, especially for those who don't know how to code.
@simeon As a side note, there is a tiny but complete programming language embedded in the puzzles I put in the book to hammer that point home in the most obscure way.
Proper writeup on the rest soon enough!
@simeon I am not sure anyone ever solved those!
They're very cryptic and were meant as a sort of hidden subtheme to contrast the rest of the book and my editor hated the idea but I insisted upon it.
I may eventually post solutions to those as well because they're easy once you know how it works but quite challenging to solve by hand (the last one, at least)
@skillstopractice On that note: are you aware of an interface/system that (visually) deals with higher order software artifacts? For instance, instead of typing programming language constructs weāre (visually) manipulating e.g. architecture layers, entities, relationships, events, etc.
Ideally Iād like to navigate application components instead of files on disk when working with larger code bases.
@simeon That's what I want to work on or see others build.
It would be important for it to still gracefully decompose down to code, but it's kind of wild that we haven't built UIs to represent units of code-backed components outside of flowchart like languages like labview or block syntax like scratch.
There are other possibilities!
@skillstopractice Yeah, exactly. Iāve wanted such a thing for a while but need it even more now that weāre, apparently, generating code. I mean, how are you supposed to understand and build a mental model of code you havenāt touched.
Maybe we wonāt need to, though, and simply working with the result will be enough. I think a lot of folks using Lovable, for instance, never see the code.
@simeon I agree 100% about coding being how we currently build mental models. I think the LLM flow emerged because of the limitations of working at that low level. The problems is unless you're writing in a formal enough language where every word can map 1:1 with a code construct, prompts are not a mental model either.
That's the subtle thing about the last chapter of my book, every "prompt" was a closed form reference to something that could be modeled by a component or function.
@skillstopractice I can imagine a Figma-like interface that shows application layers, components, entities and their relationships (also with the outside world), and allows you to quickly navigate between and manipulate all of them at different levels of detail (including the pure code level).
I guess something like https://github.com/samuelmtimbo/unit but for manipulating higher-order concepts.
@simeon I will need to look at Unit closer because the idea of representing a program as a graph feels right to me.
As I teach code reading I emphasize that aspect of things, but you really need to squint when organizing code around source files.
@skillstopractice Squint till it starts hurting, haha.
BTW look what just landed in my RSS reader: https://www.chrbutler.com/the-best-interfaces-we-never-built
@skillstopractice I recently remembered chapter 8 as I was describing a programming experience I had - I was delighted to see that you had posted the pdf.
I wonder if you have any reflections on that vision of future software development nearly 10 years on? There would seem to be some obvious comparisons to draw between your imagined future and what actually happened.
@hughrawlinson Working on an essay on exactly that!
Will let you know once it's up.
@M0tfy More or less stand by all ideas expressed in that (very weird) book to this day, glad you are enjoying it!
Feel free to reach out with thoughts or questions to share.
Rye š
Gregory Brown
Simeon Nedkov
Jamie
Other-worldly Hugh
m0tfy