It is my belief with some exceptions it is almost always easier to teach a domain expert to code than it is to teach a software developer the domain.

▲

thephyber 24 minutes ago | parent | next [-]

Not all kinds of programming are the same.

Web dev is low entry barrier and most web devs don’t need a very deep knowledge base.

Embedded, low level language, using optimizations of the OS / hardware require MUCH more specialized knowledge. Most of the 4 year undergraduate program for Computer Science self selects for mathematics inclined students who then learn how to read and learn advanced mathematics / programming concepts.

There’s nothing that is a hard limit to prevent domain expert autodidacts from picking up programming, but the deeper the programming knowledge, the more the distribution curves of programmers / non-programmers will be able to succeed.

Non programmers are more likely to be flexible to find less programming-specific methods to solve the overall problem, which I very much welcome. But I think LLM-based app development mostly just democratizes the entry into programming.

▲

bluGill 2 hours ago | parent | prev | next [-]

For problems that can be solved with only a small amount of simple code that is true. However software can become very complex and the larger/more complex the problem is the more important software developers are. It quickly becomes easier to teach software developers enough of your domain than to teach domain experts software.

In a complex project the hard parts about software are harder than the hard parts about the domain.

I've seen the type of code electrical engineers write (at least as hard a domain as software). They can write code, but it isn't good.

	▲	scottyah 23 minutes ago \| parent [-]
		That's true both ways though: if a theoretical physicist wants to display a model for a new theorem, it'd be probably easier for them to learn some python or js than for a software engineer to understand the theorems.

▲

isubkhankulov an hour ago | parent | prev | next [-]

In practice, does that happen? Usually companies try to bring the best of both and build from there.

	▲	thephyber 23 minutes ago \| parent [-]
		I wouldn’t argue how things historically worked, but rather where the LLM innovations suggest the trajectory will go.

▲

no_wizard 2 hours ago | parent | prev | next [-]

Every single time I try to get a domain expert at $job to let me learn more about the domain it goes goes nowhere.

My belief is that engineers should be the prime candidates to be learning the domain, because it can positively influence product development. There’s too many layers between engineers and the the domain IME

	▲	thephyber 20 minutes ago \| parent [-]
		I mostly agree, but I see programmers more as “language interpreters”. They can speak the computer’s language fluently and know enough about the domain to be able to explain it in some abstractions. The beauty of LLMs is that they can quickly gather and distill the knowledge on both sides of that relationship.

▲

paodealho 2 hours ago | parent | prev | next [-]

It is my experience that most of these business domain experts snore the moment you talk about anything related to the difficulties of creating software.

▲

HolyLampshade 2 hours ago | parent | next [-]

Yeah, I think the issue has more to do with the curiosity level of the participant rather than whether they are a business domain expert or a software engineering expert.

There’s a requisite curiosity necessary to cross the discomfort boundary into how the sausage is made.

▲

vntok 2 hours ago | parent | prev [-]

Until a few months ago, domain experts who ciuldn't code would "make do" with some sort of Microsoft Excel Spreadsheet From Hell (MESFH), an unholy beast that would usually start small and then always grow up to become a shadow ERP (at best) or even the actual ERP (at worst).

The best part, of course, is that this mostly works, most of the time, for most busineses.

Now, the same domain experts -who still cannot code- will do the exact same thing, but AI will make the spreadsheet more stable (actual data modelling), more resilient (backup infra), more powerful (connect from/to anything), more ergonomic (actual views/UI), and generally more easy to iterate upon (constructive yet adversarial approach to conflicting change requests).

	▲	bopbopbop7 an hour ago \| parent [-]
		> AI will make the spreadsheet more stable Hallucinations sure make spreadsheets nice and stable.

▲

imiric 2 hours ago | parent | prev [-]

That doesn't track at all IME.

Programming is not something you can teach to people who are not interested in it in the first place. This is why campaigns like "Learn to code" are doomed to fail.

Whereas (good) programmers strive to understand the domain of whatever problem they're solving. They're comfortable with the unknown, and know how to ask the right questions and gather requirements. They might not become domain experts, but can certainly learn enough to write software within that domain.

Generative "AI" tools can now certainly help domain experts turn their requirements into software without learning how to program, but the tech is not there yet to make them entirely self-sufficient.

So we'll continue to need both roles collaborating as they always have for quite a while still.