Live data from Hacker News

Domain expertise has always been the real moat

brethorsting.com

301–310 of 592 posts

Re: Domain expertise has always been the real moat

#301

Earlier quoted context omitted.

You are wrong. Writing programs (atleast efficiently) is not the easiest part. It just appears to be once you get accustomed. Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code. Domain expertise is valuable and hard but I don't get this "domain expertise is harder than disciplined coding" mentality.

> Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code "efficient scalable code" is just as vague as good code. How are you going to know your code is scalable if you don't understand your domain? Scalability is not something you sprinkle onto code.

Are you kidding me. What has domain got to do with efficiency and scalability.

Efficiency is about using minimum cpu cycles or minimum memory or minimum network round trip or more generically using minimum/optimum resources to get something done.

Scalability is about minimizing bottlenecks and linear scaling so one can just copy and execute by adding more nodes/resources and expect correctness and increased throughput.

Both of these have nothing to do with domain expertise.

Re: Domain expertise has always been the real moat

#302

Earlier quoted context omitted.

You are wrong. Writing programs (atleast efficiently) is not the easiest part. It just appears to be once you get accustomed. Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code. Domain expertise is valuable and hard but I don't get this "domain expertise is harder than disciplined coding" mentality.

Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code. Not all code has to be efficient scalable code. I know some domain experts that were not programmers. They picked up enough Python or Swift + UIKit (this was pre-LLMs) and their applications are now widely used in their domain. In some cases, they contracted some software companies in the pas…

[deleted]

Re: Domain expertise has always been the real moat

#303
post #43

My friend is an electrical engineer and just passed a FIDE chess rating of 2000. Has played for 30 years, started the chess club in high school. Knows a little programming from the stuff he had to do with microcontrollers in college. I'm an infra/admin jack of all trades with a comp sci degree and have been a hobby programmer for 30 years. I have a Lichess rating of 1000 on a good day. We tried doing a chess bot comp…

A terrible example, because chess is very, very simple - deterministic, rules fully specified in a few pages. We're talking about how you operate in a "games" which, among other complexities, involve the economy and human social dynamics. Billions of other agents. Find a plumber and try to beat them when someone calls you with a clogged toilet. Find a teacher and try to beat them when a student is repeatedly acting out.

Re: Domain expertise has always been the real moat

#304

Earlier quoted context omitted.

You are wrong. Writing programs (atleast efficiently) is not the easiest part. It just appears to be once you get accustomed. Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code. Domain expertise is valuable and hard but I don't get this "domain expertise is harder than disciplined coding" mentality.

Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code. Not all code has to be efficient scalable code. I know some domain experts that were not programmers. They picked up enough Python or Swift + UIKit (this was pre-LLMs) and their applications are now widely used in their domain. In some cases, they contracted some software companies in the pas…

A implies B doesn't mean B implies A. Not all programs have to be efficient and scalable.

But mental discipline required to write efficient and scalable code is insane that most domain expertise is feeble by comparison.

Re: Domain expertise has always been the real moat

#305
post #269

How much pontificating needs to be done before people acknowledge nobody has any idea what to do with AI on an individual level? First being good developer and learning how to use AI was sufficient, next it was being able to design architecture, then it was “taste” that made all the difference and now being an expert in the domain is the only thing that matters really. Until AI is basically in a stable, predictable,…

As software engineers we’ve now suddenly become a sort of “god of the gaps” - our existence is only justified in the (fewer and fewer) situations where the AI can’t do the job just as well on its own

[deleted]

Re: Domain expertise has always been the real moat

#306
post #290

Earlier quoted context omitted.

Nevermind syntax, what's a variable? function? class? What's the difference between int/float/boolean string? Nevermind more advanced concepts like O(1) vs O(n). But when the vibe coder just needs to prompt "the page loads really slowly. plz fix" and the LLM can go in, add an index to the right SQL table, add a limit and pagination, so what if I can tell you the difference between PostgreSQL's dialect of SQL vs MySQL…

Im not understanding why the discounting of your prior knowledge somehow slides over to a benefit for the non-technical vibe coder? wouldnt you still be in a better position when prompting “site slow, make fast”?

For now. But in a future where the non-technical vibecoder + AI can fix the slow site without the benefit of my expertise to thoroughly prompt it properly, why hire me?

The business goal is that the site is slow. That gets fixed by the non-technical vibecoder for the cost of however many tokens. Why look for outside help (aka me) if there's no need to and the AI can do it all?

Re: Domain expertise has always been the real moat

#307
I'm such a generalist. During all my career, from support to decades of C-level, I was equally challenged by domain and IT people for not being deep in everything. But whenever they couldn't come up with a compromise, I was the person who always offered it. Doing purely consulting work now, mostly implementation. And this "little bit of everything" can be strongly multiplied by AI tools, since I already know what exactly I want to achieve, I just need speed and a cross-check.

Re: Domain expertise has always been the real moat

#308
post #38

The software generalist described in this post has domain expertise as well. In software. If you’re a great generalist software engineer today, you aren’t jumping to some random domain to escape AI. Software is your domain. You’re sticking with it as it expands and transforms.

Exactly. The software engineering domain is huge. I could code just about anything when I was 16 years old after 2 years of intensive learning... It took me an additional 10 years to learn to design software that is secure, maintainable, efficient and scalable.

Re: Domain expertise has always been the real moat

#309
While I agree that domain expertise has always been a moat, I believe the author is missing something critical: there is a big difference between being able to verify the output of a system is correct, and being able to tell a system how to generate the correct output to begin with.

Personal example: I had a software engineering colleague who was the best coder of financial management systems I've ever encountered. He gained these skills through years of in-the-trenches development. One of the things he told me, and that I also observed, was that the vast majority of financial experts (basically, the people in the accounting department of companies) had an extremely difficult time just telling him what the rules of any particular transaction should be. But what they could do was tell him whether the handling of any particular transaction was right or wrong. So often times he would sit down with these accounting folks and go through lots of example transactions he came up with, and from there he essentially built up the requirements spec.

In my experience, that is the primary difference between people I've known who are good software engineers and those who aren't: people who can specify the detailed rules of any system, vs. folks who take a "well, I know it when I see it" approach.

I have a strong suspicion that folks who have a high degree of domain expertise in a particular area will fail as software builders even in an agentic world because they will struggle to elucidate clearly the rules in their head that they've learned over years. As an analogy, it's kind of like asking a native speaker for the grammar rules of their language. Often times they can't, but they'll just say "well, that sounds wrong." They may be "domain experts" in their language, but they'd have a hell of a time prompting an AI system on how to grade a test for grammar correctness.

Post reply on HN