I watched the first half hour of this earlier this week. I was surprised at just how differently two people can view the world. I'm not sure I would be as dogmatic as him, but just using the first few points, I think you can make strong cases against:

1. Everything is exposed as an API with little no insight to inner workings (black box)

2. Everything should be broken down into modules at a level where one person works on that module

3. He shows a video of his video editor, saying it supports multiple inputs (like two keyboards or two mice), then says no platform supports it, but if they ever do, it will work

4. Don't implement 'good enough apis'

I hope that anybody who has ever worked on software understands that there are virtues to doing exactly the opposite of what is described in each of these points. Even if you can make an argument for any of these, you would have to qualify them with so many exceptions that you would effectively negate the entire argument.

I spent a lot of evenings early in my career watching similar videos, hoping to find some magic bullet in how people better than me do what I do. People make a living doing this on the conference circuit. Maybe it is a fools errand to try to distill something as complex and situationally dependent as software into a video, but I'm having a hard time finding any major insights in all of the videos I watched.

> Don't ever implement good-enough-for-now APIs

Agree in theory, in practice this is impossible. Even if you're an absolute domain expert in whatever you're doing, software and requirements will evolve and you will end up needing to implement something for which your current API is not suitable. Just ask S3:ListObjectsV2 or golangs' `encoding/json/v2` etc.

I push back hard on this one because a lot of developers will try to be "clever" and basically turn their api into

    def my_api(parameters: dict[str, str]) -> dict[str, str]:

It's better to accept that your API will change at some point and have a versioning and deprecation strategy in place. With well-architected software this usually isn't hard.

Started watching, but "C89 is the safe option for long lived software" kind of turned me off. There are plenty of safe long lived stable languages out there where you dont have to manually manipulate memory. At the very least, this guy should be advocating for Java.

But even that's too far really. Like it or not, "shiny fad" languages like Python & Javascript have been around forever, support for them isn't going away, this should be a non-concern at the architectural level. (Bigger language concerns: is it performant enough for my expected use? Does it have strong types to help with correctness? Can I hire programmers who know it? etc)

Ages ago, before I had any real professional experience, I was blown away by Steenberg’s demos and enamored by his tech talks. The demos still impress me and have aged well, but today I’m glad I didn’t fall into the trap of taking his development advice as scripture.

His name has been popping up a lot more recently. I would be worried about the impact he might be having on young programmers, but honestly I doubt his worst advice would survive in industry anyway. I didn’t watch this particular video but his recent talk at Better Software Conference was illuminating, in a bad way.

I've seen relational database schemas degenerating into untyped free-for-all key-values because they weren't expressive enough. I've seen massive code duplication (and massive amounts of bugs) because no one invested into a quality core set of libraries to address basic use-cases of a given platform. I've seen systems crumbling under tech debt because of chronic prioritization of features over maintenance.

I've worked on large software projects. The only ones I've met that weren't dreadful to work on had engineering and management working together with a shared, coherent vision.

I'm about 4 years into my career (mostly self-taught and learned-on-the-job), and I actually found Eskil's talk inspiring. The part that hit me hardest (in the good sense) was "don’t implement good-enough APIs."

As someone still figuring out my footing, I often feel pretty torn: should I train myself to always push for the cleanest (or near-perfect) design I can manage (as books like "The Pragmatic Programmer" and talks like this suggest), or is that just setting myself up for frustration in industry where pragmatism and deadlines usually win?

What worries me is exactly what some people here are saying – that "temporary" APIs usually last forever. I’ve already seen that on my team. So part of me wants to internalize Eskil's idealism early, even if it means clashing with more pragmatic coworkers.

For those of you with decades of experience: if you were mentoring someone at my stage, would you tell them to lean toward ideals (aiming high, then compromising when needed), or to embrace trade-offs and "good enough" thinking from the start?

The "one module should be written by only one person" dogma is kind of interesting.

But I got to the "my wrapper around SDL supports multiple simultaneous mouse inputs, even though no operating system does" and noped out. YAGNI, even in a large project

I feel like a lot of his takes -- like c89 being the best -- may be true in the context of the kind of complex desktop applications he seems to develop, but not universally applicable.

Still, he gives a lot of good advice and fundamental engineering rules.

6:55> "C98"

7:05> "It's faster to write five lines of code today, than to write one line today, and have to edit it in the future"

This is my experience writing C as well, which is why I now avoid it.

There are plenty of times where writing something in C seems like it would be simpler and more reliable than in other languages. But I found I couldn't edit it. Too many of my assumptions get baked into the code and I can't see them later.

IMHO there are a lot of problems with the advice from Eskil.

His ideas about abstraction of the platform made a lot of sense in the past decades, but IMHO are not that applicable nowadays: It is well understood to separate domain logic from UI and storage, and a desktop application has a very different UI from a mobile app or even a web app.

My next critic point is, that Eskil assumes all domain knowledge is there from the beginning and will not change over time (his idea of having perfect APIs from the beginning).

No mention about error handling, reliability, response times, atomic operations etc.

To make it very clear: I believe Eskil gives his advice in good faith and his advice served him well in his own projects. In my opinion most of his advice is just not good advice in general.

(Besides having modules as black box building blocks if possible).

So I watched about 15 minutes. I'm not already aware of this person, and their website isn't too illuminating, and there is an hour left. So I have to confess I closed the tab.

His ideas feel, frankly, like catnip for developers. Each dev writes there own modules, so you get to do whatever you want without having to deal with other people's coding styles or philosophies (or better ideas), and no meetings, and you also spend the "right" amount of time building everything.

But it doesn't sound like it would work on "LARGE" (his capitals) software projects, at least none that I've worked on. In those, creating modules small enough to be built once by one dev would just push all discussion (and dreaded meetings) into the API layer, with double the meetings because you should get it right first time, actually double them again because the strategy if someone leaves and their modules aren't right is to just reimplement them so you have to be even more sure they are thoughtfully designed.

It actually sounds like a pitch for agentic coding: if you define your APIs small enough and correctly enough, you don't need to worry about implementation quality, so just let the api do it. I think it's a good way of thinking about it, and thinking about all the ways in which you might not be comfortable with that.

Anyway, what do I know? Maybe he's a super expert on this stuff. I would gentle suggest, if he redid the talk, to open with a) what he means by LARGE software projects, and b) an example where this strategy he is about to explain has been implemented.

Aside - Why do we need the word "architecting" anyway? Why not just use designing?

Obligatory mention of A Philosophy of Software Design by John Ousterhout as the arguably the most important book every developer should read to understand proper modularization and complexity management.

[dead]

[dead]