4 ms·

That is the problem with software developers with expertise in software, but no deep domain knowledge outside the CS world.

tempest_ 8mo ago
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.
- bluGill 8mo ago
  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 8mo ago
    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.
    - thwarted 8mo ago
      If this is the case is discoverable, for at least one direction. Reproducability is known to be a problem in some of the sciences, for various reasons. Find a paper that includes its data and software/methodology used for analysis, and try to get it running and producing the same results. Evaluate the included software/methodology on whatever software quality standards you feel are necessary or appropriate.
  - grvdrm 8mo ago
    Hard disagree with hard parts of software are harder than domain. I don’t know your story, skills, or domain. But this doesn’t match my experience and others around me at all.
    - tecoholic 8mo ago
      Maybe you and others around you are all in some form of engineering capacity? Because I have seen software everywhere from coffee shops, bicycle repairs, to K12 education - all of whom would hard disagree with you.
    - Lutger 8mo ago
      Really depends on the domain. I've been in jobs where the domain was much harder than my job as a software engineer, but I've also been in jobs where I quickly got to understand the domain better than the domain experts, or at least parts of it. I believe this is not because I'm smart (I'm not), but because software engineering requires precise requirements, which requires unrelenting questioning and attention to details. The ability to acquire domain knowledge quickly however, isn't exactly the same as the ability to develop complex software.
- paodealho 8mo ago
  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.
  - vntok 8mo ago
    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 8mo ago
      > AI will make the spreadsheet more stable Hallucinations sure make spreadsheets nice and stable.
    - xeromal 8mo ago
      We have monthly presentations at my job and the business folk are really leaning into AI. The biggest win so far are them being able to generate new user experiences and get them into figma by themselves. They're able to test a design, get it into figma, generate some code, and get it in front of users without a developer or designer at all. It's not perfect but the tests show what we need to focus on vs what falls flat when put in front of users. It's very impressive and I'm proud of them.
      - rafterydj 8mo ago
        Super interesting. I don't know why, but something about this comment made something click for me, as an "AI fatigued" engineer. From the view you describe, it seems AI just lets you experiment faster, when all you want to do is experiment. You find product market fit easier, you empower designers more, etc. Much easier to iterate and find easy wins from alternative designs - as long as your fundamentals work! Only problem is that you are experimenting in public, so the massive wave of new AI generated features come to the public from everywhere at once. Hence the widespread backlash. Not to mention, the core job function when you are experimenting is different from what defines a lot of hard technical progress: creating new technologies, or foundational work that others build on, is naturally harder and slower than building e.g. CRUD services on top of an existing stack. Deep domain expertise matters for selling, deep programming expertise matters for stability. I don't know, curious where the line will end up getting drawn.
- imiric 8mo ago
  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.
  - peteridah 8mo ago
    Conversely, good developers can now leverage LLM’s to master any domain.
    - imiric 8mo ago
      Hhmm I think that's more difficult than using these tools for creating software. If generated software doesn't compile, or does the wrong thing, you know there's an issue. Whereas if the LLM gives you seemingly accurate information that is actually wrong, you have no way of verifying it, other than with a human domain expert. The tech is not reliable enough for either task yet, but software is easy to verify, whereas general information is not.
- no_wizard 8mo ago
  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 8mo ago
    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.
- isubkhankulov 8mo ago
  In practice, does that happen? Usually companies try to bring the best of both and build from there.
  - thephyber 8mo ago
    I wouldn’t argue how things historically worked, but rather where the LLM innovations suggest the trajectory will go.
- thephyber 8mo ago
  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.
- rprend 8mo ago
  This is interesting. Do you know of any examples of successful tech companies built by non-technical founders?
  - seemaze 8mo ago
    I think a more appropriate question would be: "Are there more or less examples of successful companies in a given domain that leverage software to increase productivity than software companies which find success in said domain?"
  - xeromal 8mo ago
    Your question kind of answers itself with the filter of "tech companies". If you asked broadly about successful companies, the answer would be more apparent. But an answer to your question would be Capital One.
- ramblerman 8mo ago
  Eh, this is the kind of pithy soundbite that sounds vaguely deep and intelligent but doesn't hold up. In what domains have you had experience taking non programmers with domain knowledge and making them programmers?
- brightball 8mo ago
  One of my favorite things about this field is getting to learn about all of these different business domains.
MattGaiser 8mo ago
Pretty much. I’m working on a few things with several people and I’m now constrained by their ability to find stuff to build.
ge96 8mo ago
I want to make a business, but what is the business
CuriouslyC 8mo ago
It's way easier to raise for dev tools than domain tools right now.
ebiester 8mo ago
Or... the places they have deep expertise they have NDA/non-competes to worry about. (At least, outside of California.) Sure, I could go and create an accounting app - or a clinical trial recruitment app - as a basic clone of what I've already created. And I might even make it better for some niche. But even if I know what that product system needs, I still need to find someone with the relationships to get in the door. The trick is - you don't need an idea man for a non-technical founder. You really need someone with a rolodex and a problem.

tempest_ 8mo ago

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.

bluGill 8mo ago
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 8mo ago
  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.
  - thwarted 8mo ago
    If this is the case is discoverable, for at least one direction. Reproducability is known to be a problem in some of the sciences, for various reasons. Find a paper that includes its data and software/methodology used for analysis, and try to get it running and producing the same results. Evaluate the included software/methodology on whatever software quality standards you feel are necessary or appropriate.
- grvdrm 8mo ago
  Hard disagree with hard parts of software are harder than domain. I don’t know your story, skills, or domain. But this doesn’t match my experience and others around me at all.
  - tecoholic 8mo ago
    Maybe you and others around you are all in some form of engineering capacity? Because I have seen software everywhere from coffee shops, bicycle repairs, to K12 education - all of whom would hard disagree with you.
  - Lutger 8mo ago
    Really depends on the domain. I've been in jobs where the domain was much harder than my job as a software engineer, but I've also been in jobs where I quickly got to understand the domain better than the domain experts, or at least parts of it. I believe this is not because I'm smart (I'm not), but because software engineering requires precise requirements, which requires unrelenting questioning and attention to details. The ability to acquire domain knowledge quickly however, isn't exactly the same as the ability to develop complex software.
paodealho 8mo ago
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.
- vntok 8mo ago
  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 8mo ago
    > AI will make the spreadsheet more stable Hallucinations sure make spreadsheets nice and stable.
  - xeromal 8mo ago
    We have monthly presentations at my job and the business folk are really leaning into AI. The biggest win so far are them being able to generate new user experiences and get them into figma by themselves. They're able to test a design, get it into figma, generate some code, and get it in front of users without a developer or designer at all. It's not perfect but the tests show what we need to focus on vs what falls flat when put in front of users. It's very impressive and I'm proud of them.
    - rafterydj 8mo ago
      Super interesting. I don't know why, but something about this comment made something click for me, as an "AI fatigued" engineer. From the view you describe, it seems AI just lets you experiment faster, when all you want to do is experiment. You find product market fit easier, you empower designers more, etc. Much easier to iterate and find easy wins from alternative designs - as long as your fundamentals work! Only problem is that you are experimenting in public, so the massive wave of new AI generated features come to the public from everywhere at once. Hence the widespread backlash. Not to mention, the core job function when you are experimenting is different from what defines a lot of hard technical progress: creating new technologies, or foundational work that others build on, is naturally harder and slower than building e.g. CRUD services on top of an existing stack. Deep domain expertise matters for selling, deep programming expertise matters for stability. I don't know, curious where the line will end up getting drawn.
imiric 8mo ago
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.
- peteridah 8mo ago
  Conversely, good developers can now leverage LLM’s to master any domain.
  - imiric 8mo ago
    Hhmm I think that's more difficult than using these tools for creating software. If generated software doesn't compile, or does the wrong thing, you know there's an issue. Whereas if the LLM gives you seemingly accurate information that is actually wrong, you have no way of verifying it, other than with a human domain expert. The tech is not reliable enough for either task yet, but software is easy to verify, whereas general information is not.
no_wizard 8mo ago
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 8mo ago
  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.
isubkhankulov 8mo ago
In practice, does that happen? Usually companies try to bring the best of both and build from there.
- thephyber 8mo ago
  I wouldn’t argue how things historically worked, but rather where the LLM innovations suggest the trajectory will go.
thephyber 8mo ago
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.
rprend 8mo ago
This is interesting. Do you know of any examples of successful tech companies built by non-technical founders?
- seemaze 8mo ago
  I think a more appropriate question would be: "Are there more or less examples of successful companies in a given domain that leverage software to increase productivity than software companies which find success in said domain?"
- xeromal 8mo ago
  Your question kind of answers itself with the filter of "tech companies". If you asked broadly about successful companies, the answer would be more apparent. But an answer to your question would be Capital One.
ramblerman 8mo ago
Eh, this is the kind of pithy soundbite that sounds vaguely deep and intelligent but doesn't hold up. In what domains have you had experience taking non programmers with domain knowledge and making them programmers?
brightball 8mo ago
One of my favorite things about this field is getting to learn about all of these different business domains.

MattGaiser 8mo ago

Pretty much. I’m working on a few things with several people and I’m now constrained by their ability to find stuff to build.

ge96 8mo ago

I want to make a business, but what is the business

CuriouslyC 8mo ago

It's way easier to raise for dev tools than domain tools right now.

ebiester 8mo ago

Or... the places they have deep expertise they have NDA/non-competes to worry about. (At least, outside of California.) Sure, I could go and create an accounting app - or a clinical trial recruitment app - as a basic clone of what I've already created. And I might even make it better for some niche. But even if I know what that product system needs, I still need to find someone with the relationships to get in the door. The trick is - you don't need an idea man for a non-technical founder. You really need someone with a rolodex and a problem.