Live data from Hacker News

Domain expertise has always been the real moat

brethorsting.com

511–520 of 592 posts

Re: Domain expertise has always been the real moat

#511

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 have been thinking about this sort of progression too. One thing I wonder about is network effects. Are they even important? Now, for sure. Will they be so in a year? I don't know. I'm thinking about tooling centralizing on common primitives. Like, for my own situation, does it matter that everyone is using the same libraries?

If AI becomes the interface, then we will a layer of abstraction above programming languages themselves. Which is kind of wild.

(I don't pretend this is a novel idea. I'm just not that plugged into AI discourse.)

Re: Domain expertise has always been the real moat

#512
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…

There's a difference between having built up intuition through experience about how to play chess, and figuring out how to encode that information in a program. In other words, the amazing chess player can probably provide valuable insight into any given board position, but they may struggle to generalize that insight.

Re: Domain expertise has always been the real moat

#513
post #457

Earlier quoted context omitted.

You described reasoning by analogy, which two thirds of the population does.

Please explain explicitly what you are implying, because I don't get it Who are the 1/3 of the population that does not reason by analogy?

Instead of needing a familiar metaphor to understand a new system (reasoning by analogy), they grasp the core conceptual mechanics directly.

It’s not that the 2/3 can't think abstractly, it’s just that they use analogies as a temporary processing step to get there, while the 1/3 starts there.

Re: Domain expertise has always been the real moat

#514
post #340

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. H…

This is the exasperating part about learning to speak Spanish using a textbook; you must guess the grammar rules because the textbook won't tell you. So, you use the English rule and hope and pray that it is the same in Spanish, and you'll be right the majority of the time but often wrong. Spanish textbooks written 100 years ago tell you the grammar rules and are more useful than recent textbooks.

I’ve noticed this too. Any idea why modern language books get this so wrong?

Re: Domain expertise has always been the real moat

#515
post #455

Earlier quoted context omitted.

I'm this person, and I do find AI to be quite helpful, though I'm mostly just playing around at this point. I'm the daughter and granddaughter of programmers, and I learned the basics of how to code as a kid. I'm good at it and have a knack for it, but I didn't want to do it for 8+ hours a day and then spend my nights on it as well, so I didn't pursue it as a career. I did an undergraduate degree in Linguistics, whic…

Having descended from a humanities social background and blundered into professional programming rather incidentally, a lot of this resonates with me. I've frequently been credited as a person who can really string all the disparate elements of tacit knowledge together into a unified fabric in our particular subdomain, and helped a lot of people plug Swiss cheese gaps in their knowledge that way and come away with th…

In theory, it's because we're going to be better at steering an LLM in some ways. A lot of the friction and hold up in building comes in the communication between people/departments/organization. If you eliminate that by holding the knowledge in one person/department, you see an efficiency gain.

What they're not saying is that they think we're more valuable because they think we'll be cheaper. They think they can have us do 2 jobs and pay us for 1: probably less than a decent SDE made in 2019.

Personally, I think it's likely to be a shitshow and backfire if that's how companies decide to try to go that route (especially the largest ones). First, if we wanted to be devs, we would be (like you). Most people with the knack for programming and thinking in systems know they have that knack, and if they haven't jumped ship to SDE before now, there's a reason. I could definitely hack a junior SDE role, skill wise, but I don't want to. Second, finding people like us is difficult. The hiring process (which is becoming more and more Gilliamesque by the day) is really bad at identifying us. There aren't credentials, and this sort of work tends to reside in the gaps, as you identified. It's harder for it to show up on a resume. Hiring is optimizing for exact matches and experience, and that's the opposite of how this skill set actually functions. I've found these skills are best developed by being placed in a room where you know very little about what's going on and forcing you to develop heuristics and approaches over time for getting that context. Thirdly, I can't speak for you, but I've developed this perspective over decades and if people want it, they're going to pay appropriately. If they think I'm going to do any of this at my current salary level, they're deranged. And lastly, while most people in our position might roll our eyes at some techie discussions and culture, we do fundamentally like techies/devs and we tend towards placing a greater value on things like relationships than a pure SDE does. (Just speaking in generalities). So 'is willing to replace and/or toss out a category of people I like and respect' is a hint to us to start out assuming this is a hostile negotiation. (Whereas SDEs as a cohort over the last 20 years extended a lot of goodwill at first). We're far more likely to work somewhere, get enough domain knowledge, and then bounce to start our own thing, especially since as a population we're more likely to have devs who will work with us as non-technical founders. Someone who's decent at marketing/sales/the stupid 'people stuff', understands a domain, and understands when a proper dev tells them what is and isn't possible and can even help with some of the most boring, rote parts of the technical side if needed/in crunch is an excellent non-technical founder, and as a group we're also more likely to have access to the technical connections that we'd need if we wanted to build something beyond our ability.

Re: Domain expertise has always been the real moat

#516

Earlier quoted context omitted.

>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 We have internalized more knowledge than we can explain sounds like the textbook definition of Polanyi's paradox:"Polanyi's paradox, named in hon…

having worked on automation of accounting process, it has been a combination of ever evolving ruleset/edge scenarios for 10% cases plus standardised rules for 90% of the cases. i think the problem is that it is an evolving field. alot of times it borders law, which makes it murky and vague too.

[dead]

Re: Domain expertise has always been the real moat

#517
post #490

It's funny how out of touch AI is with seeing the big picture of problems. Here's an example I encountered last week: Someone in my neighborhood is a 75 year old chemical engineer who likes computers and got into Linux a few months ago. I see him from time to time when walking around, he's a nice guy and overall has a scientist's mindset. He doesn't make a lot of assumptions and tries to think things through but some…

It's funny how well this reflects the contrast in internet advice between Windows and Linux issues. All users deserve advice beginning with thorough sanity-checks and potential quick-fixes before having to dig deeper.

Searching about common Windows issues results in misleading blogspam. Suggested "solutions" resemble blindly applied folk remedies.

I'm no stranger to breaking my desktop Linux after an hour of misdirected troubleshooting and desperately messing with core libraries. I'm still glad I can quickly find my way to ArchWiki.

Re: Domain expertise has always been the real moat

#518

I find this take off. In general, LLMs collapse a bit of all knowledge work, including many domain experts. I work with domain experts often and it’s usually the most difficult part of the process. Now, I can ask an LLM the questions I need to design the system and have an agentic system help me build parts. And it works, quite well. The places it falls flat is domain expertise that isn’t well documented, like specif…

Shallow generic domain knowledge is not really a helpful domain expertise, is it. Lets take banks - knowing how banks work in general means little for that one specific bank who is paying you, which has different portfolio than most, different processes because everything is homebrew over decades of doing business and they differentiate from rest of the market in many ways and thats their key proposition, different d…

I'm in the position of being shallow in the domain I code for--and I find it a very big help. Knowing what the real world implications of what the numbers become is a great help in understanding what truly is being requested. Just ran into that not too long ago--my code suddenly started slamming a side-cutting bit into the wood. Look into it....years ago there was a bug upstream of me that slammed the bit into the wood. Simple fix: spot the offending pattern, replace it with something sane. The upstream bug was "fixed" (not fully), my simple (lack of true knowledge of what was happening) fix proceeded to undo their fix. Then it got rewritten the way it should have been, a more general recognition of unacceptable movements and how to fix them.

Re: Domain expertise has always been the real moat

#519
post #455
post #432

Earlier quoted context omitted.

I think the answer is in the second sentence of the article. The most valuable person in this new world (using the author's own phrasing from the penultimate paragraph) is the one who is good at "building a working model of the domain in [their] head". Depending on the domain, this may either be the domain expert themselves, or someone else trained in formal logic, data structures and organizing information into cohe…

I'm this person, and I do find AI to be quite helpful, though I'm mostly just playing around at this point. I'm the daughter and granddaughter of programmers, and I learned the basics of how to code as a kid. I'm good at it and have a knack for it, but I didn't want to do it for 8+ hours a day and then spend my nights on it as well, so I didn't pursue it as a career. I did an undergraduate degree in Linguistics, whic…

> which has been really helpful for having an intuitive sense for what 'language as data' can accomplish and for a strong understanding of the difference between language as data and language as meaning.

100%. I think, intuitively, software developers understand that there's a strong connection here, but most fail to translate that into practice. It always amuses me when someone comments on the triviality of creating CRUD apps. Setting aside the fact that people usually get the mechanics of it wrong (despite it being a solved problem), they overlook the difficulty of producing a good information design.I've developed software in a variety of industries, and I would say maybe 5% of the designs I inherit are well-done and represent the concepts they're trying to model in an elegant, parsimonious way. Rather, most examples are replete with ambiguity, orthogonal concepts smashed together into single elements, and misleading naming and relationships.

Re: Domain expertise has always been the real moat

#520

Earlier quoted context omitted.

I'd like to believe I have an inkling, having done a fair bit of teaching. Still, imagine how hard other skills are to acquire. How much civil engineering can you learn in two weeks? How much violin playing? But you could absolutely get basic grasps on a general purpose programming language. With something specialized like Unity or Excel you would get tons of useful output. The hurdle around assignment operator is as…

> The hurdle around assignment operator is as old as symbolic languages. That's why legends such as Niklaus Wirth wanted to use another operator, ":=", a notation that is still being used. Well, sure; but more generally, the ability to accept other meanings for symbols (and keep subtly different symbols straight in one's head) is a mental skill, and individuals vary in their aptitude for it. (Presumably, this one is…

Nah I just think you are so overwhelmed that "=" having a different meaning lh and rh is just too much. It is hard to remember how hard it was.
Post reply on HN