Habits of Expert Software Designers (2019)

They can iterate designs rapidly in their head or on paper, evaluate the cost or value of a design, know when a design has promise or when it won't work, and where the bottlenecks or low-hanging fruit might be, because they have a good feel for the performance/scaling cost of all the resources involved along the axes of things like branch mispredicts, main memory references, per core memory bandwidth, disk seeks, disk bandwidth, network latency, network bandwidth, expensive memory vs inexpensive storage tradeoffs. Numbers that programmers should know [1] but often don't.

In other words, before they even write specifications or start coding, they've probably done tens to hundreds of back-of-the-envelope calculations to put their design in the "roughly right" ballpark. This drastically increase the chances that the design is going to work, and work really really well. And I think this habit is also what tends to set them apart.

[1] https://colin-scott.github.io/personal_website/research/inte...

1) Experts involve the user.

Also, experts do not let the user design the software. The user will frequently want to tell you what the software "must" be doing. An expert will disregard this and will want to first understand the domain and then work with the user to find a good mapping to a useful interface.

2) Experts design elegant abstractions

I don't agree on this. Oftentimes, I have seen "experts" use solutions because they seemed elegant, intelligent, "nifty". I did that myself.

An expert will design simple abstractions that let the job done with little fuss. The software needs to be as simple as possible but not simpler than is needed.

Replace "elegant" with "simple", and it sounds about right.

An expert software looks dumb and simple, not necessarily super elegant and intelligent. Also, bad software can look dumb and simple.

3) Experts focus on the essence

Experts start by focusing on the essence. Then verify by testing how the distilled essence is useful at solving entirety of the problem.

1. Don't assume anything. Go in with an open mind and blank canvas. I can't tell you how many times I've been in design meetings where engineers assume they know how things are gonna work, before clients even open their mouths. I can't tell you how many times clients assume they know how technology works before we explain to them.

2. Iterate and validate as fast as you can within reason. Don't do waterfall, at least not at the beginning. Design, build and validate, or even just do napkin design and validate. It'll save you a lot of headaches.

3. Perfect is the enemy of good. When you reach a certain comfort level with your software, ship it. You'll never be able to clean out your tech backlog or bug list.

Immediately lost interest in the article.

Being said, I'd rather get deep into the weeds with some technical summer reading. I'd love to get some recommendations from everyone here if possible.

Reaching out to other people - generally true that staff w. greater expertise are more likely and comfortable doing so;

Form elegant abstractions - also true: experts more likely than newbies to be able to find a simple way to describe something that is built on sufficient complexity to cause at least some bafflement.

Also, for staff of a similar degree of experience and role, I have a greater degree of confidence in the outputs produced by those who can answer more searching questions, showing they have drilled down to the fundamentals. I suspect that this type of person is more likely to develop into a real expert than those who adopt the how without caring about the why. Experts may be better at ensuring that the substance of an objective is delivered rather than just the form.

I find there's a lot of informal folk-lore when it comes to "solid" software design. Asking experts is likely to surface answers as numerous as the stars in the visible universe. There may be common threads in popular discourse but it seems only to be buoyed by personality: a popular project lead or evangelist discusses their methodology and a constellation of developers grab on to it in order to emulate their success. Others find harbour elsewhere.

And yet very few of them formally state how their approach works to solve real engineering problems. The gang of four book is a book of patterns. The book itself doesn't contain any formal analysis of these patterns. Even among these patterns there is a world of contention about which ones work, which ones are less useful, etc, etc. A beginner into this world, typically an intermediate to advanced programmer with a few years experience under their belt, hits this wall and is left to flounder and find their tribe.

I liken it to beliefs about the efficacy of software engineering practices. There's far too little evidence about them to make any strong claims to their effectiveness. And yet people have built careers around evangelizing certain ones.

(And often when you ask people to be more forthcoming and give their formal definitions they wave their hands and say that software development is art not engineering and that it's about craftsmanship and beauty not cold, hard, unfeeling things like calculi, categories, or algebras)

I have little faith these days. Unless someone can formally describe their abstraction it's neither simple nor elegant to me. Such terms are qualitative in the absence of formal definitions. What is simple to you might be a hodge-podge to me. Code sans sensible abstractions is procedural spaghetti in my opinion: simple to understand in small, local parts, but impossible to comprehend as a whole. But if you can explain to me what the objects are, the operations on them and what they mean, and the algebraic properties of those operations then I'm much more certain about what we're discussing and can agree that given such definitions whether something is simple or elegant. What programming language the system is ultimately implemented in rarely matters as much as getting the design right.

Update: I'm curious because while I find these tools useful I often feel like they're under-appreciated and perhaps hardly used outside of certain small circles in practice.