Live data from Hacker News

Domain expertise has always been the real moat

brethorsting.com

211–220 of 592 posts

Re: Domain expertise has always been the real moat

#211

I work as an analyst, and our group has roughly 20% analysts with strong technical (software engineering) skills, and the rest are more traditional analysts / domain experts. In the past year we've seen these non-technical analysts become more productive when it comes to developing internal tools, by leveraging AI models for the dev part. Prior to this, pretty much everything was developed in Tableau. It was the most…

Our group is slowly replacing tableau with self built tools, with HUGE performance gains. I think these BI companies are in deep trouble, especially ones like tableau that make drawing something simple, like a histogram, near impossible.

Re: Domain expertise has always been the real moat

#212

Earlier quoted context omitted.

developers now are expected to randomly jump around projects and ship without friction. For employers it means they can move us around like pawns. Lot of companies have not reorged themselves to this new type of workforce thats much more malleable. it used to be that i pay your due at some enterpise and learn some corner of codebase really well and become go to person. that would give you job security.

Working in silos like this has always been an anti pattern though. You end up being employed for 10 years but only have 1 year of actual development experience. Just turning-the-crank and going home was always risky because one day you get laid off and realize you’re 10 years behind the competition.

What I found comfort it in was turning the crank and then using extra time to upskill in various other things (including non software dev domains). Things that weren’t immediately useful to my employer and I never would have been directly assigned, but did pay off after sometime.

Now I’m basically expected to do what my boss wants me to do every minute of the day, it’s gotten much more micromanaged.

Re: Domain expertise has always been the real moat

#213

Earlier quoted context omitted.

And there's nothing "wrong" with the GoF Patterns per-se. The issue was always people applying them blindly without understanding why (or more to the point, "if") they were needed. Once writing code filled with patterns became "the thing you do"... all bets were off. :-(

I remember putting stuff like this on my resume "developed X using visitor pattern" . ppl would ask "what is your favourite design pattern" in interviews. lmao.

Lol the worst pattern

Re: Domain expertise has always been the real moat

#214

Earlier quoted context omitted.

Thank you for this addition to the conversation. Perhaps you wish to also contribute your own response to the question posed by GP.

I am GP, reading comprehension and such.

Thank you for your topical pontification in response to my input.

Re: Domain expertise has always been the real moat

#215
post #128

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,…

An idea that's beginning to solidify for me is that AI tools make software development harder . It's harder because they dramatically raise the bar for what's possible to do. An individual developer can take on significantly more challenging projects now, because the ultimate constraint has always been time and AI can help you get more done in the time available. But the stuff you can get done with that time is a who…

That's a roundabout way of saying it makes software development easier. Perhaps even a 180.

But yes - once it's that easy you have to step up your ambitions.

Re: Domain expertise has always been the real moat

#216

Earlier quoted context omitted.

developers now are expected to randomly jump around projects and ship without friction. For employers it means they can move us around like pawns. Lot of companies have not reorged themselves to this new type of workforce thats much more malleable. it used to be that i pay your due at some enterpise and learn some corner of codebase really well and become go to person. that would give you job security.

So what enables job security now?

Let them attempt to use ai to build business critical systems and when they waste tens amd hundreds of millions they can rehire master builders who know what they're doing

Re: Domain expertise has always been the real moat

#217
Maximal Point of View that is harder and harder to disagree with: Sharing your domain expertise is asking to get yourself automated away. Already, if any company hasn't begun trying to maximally collect data on every aspect of their employee's work, they are asking to get wiped by future automated competition from companies that learned everything they could from their employees, then replaced them. Open Science? Open Source Code? Shared your art online? We were all suckers, and might be the first to go.

Re: Domain expertise has always been the real moat

#219

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,…

I write software that makes money and AI helps me write software that makes more money.

That's a rare niche; the vast majority of software makes no money whatsoever.

What type of software do you produce?

Re: Domain expertise has always been the real moat

#220

Earlier quoted context omitted.

Basically IDE free since May 2025. I actually reinstalled vscode when setting up a new machine and I think I've launched it twice? cc -> local automated testing -> github -> PR -> heavy integration tests -> review (github ui, +/-) -> manual test locally -> merge -> deploy -> manual test remotely -> synthetic user testing -> repeat

But what about navigating the code by the call stack? I didn't know that GitHub has a way to do that. Or maybe I'm probably coming across as being dumb enough to be talking about still trying to have a mental model of what calls what.

Personally, I use a debug agent for that.

I've never used breakpoint debugging, was always a printf debugger. And now an agent can do that loop for me.

Prompt is usually something along the lines of:

>I would expect the behavior of this to be [X] - instead I'm observing [Y]

And the agent will form hypothesis, place printf statements, compile, and scrape logs on loop - each loop ruling out hypothesis or narrowing down what portion of the code is responsible for the unexpected behavior.

It has been able to pin-point the exact line(s) of code responsible every time I've reached for it so far.

Post reply on HN