This is a good take. All of programming is ultimately just tools to solve a problem, and if we don’t have domain knowledge, we can’t effectively solve the problems that we set out to in the first place.

Really hit the nail on the head about the “invisible decisions” which happen like the quality vs quantity with sails.

I’ve worked on a commercial project that started with nothing but domain knowledge and perseverance. The end result was hideous and inefficient, but it was enough to get a successful company started. It’s the ugliest code I’ve ever seen, but it’s hard to argue with results. At least in this case, domain knowledge was more important than any software engineering ability would have been.

Domain knowledge is a force multiplier. Ideally you would have both lots of domain knowledge and a strong engineering team, but lack of one can be substituted with a lot of effort.

The caveat being that if you have the engineering side, the end result of the effort will probably be a bunch of domain knowledge 😅

This is a great read.

I would bring up something like this in some of my junior interviews from being self taught. I would call it “unknown unknowns” but never made the jump to Domain knowledge which I’ve heard now