4 ms·

If you do learn the business, you have to explain to management why you wasted all that time. You cant say your application is cheaper in user errors, downtime,

If you do learn the business, you have to explain to management why you wasted all that time. You cant say your application is cheaper in user errors, downtime, maintenance, licences, change requests etc... as that would mean all the other expensive software is garbage.

gregjor 8y ago
Domain expertise is not wasted time. It makes the difference between a useful application and a pile of code. Developers should not assume they know more about a business domain than the people working in it.
- bobthepanda 8y ago
  Isn’t that the job of a product manager, though? To figure out what the product should actually do?
  - justapassenger 8y ago
    To be a true engineer, one should use technology to solve problems. PMs are suppose to help with that, but to be called an engineer, one should have that mindset. Otherwise, we're just code-monkeys.
    - gregjor 8y ago
      Yes, but someone has to make sure engineers solve the right problem in a way useful to end users.
  - gregjor 8y ago
    Ideally. When I started as a programmer companies had business analysts who had domain expertise and made sure software mapped to the domain and actual users. Now we have PMs, usually glorified project managers, too often with little or no domain expertise or technical understanding. I freelance so I don’t have PMs or analysts, I have to learn the domain and deal with the management/client/users directly.
  - daleco 8y ago
    That's also be the job of the UX/Product Designer to learn about the users and business domain.
  - Barrin92 8y ago
    tacit knowledge especially in an hands-on field like medicine where patients are involved cannot be conveyed by a manager with a power point presentation. This compartmentalisation in the name of efficiency is actively harmful. Developers should get out more and get first hand experience of the environments they develop software for.
    - freedomben 8y ago
      Could not agree more. It's a bit like the game of telephone that many of us played as children. The more hops in the connection, the greater ability for knowledge loss and distortion. I once had a PM tell us to do a feature a certain way, despite engineers saying we thought it was dumb. We shipped and had lots of user complaints, and lost millions of dollars ultimately in lost revenue due to cancellations that we think were at least in part to this. We eventually reversed course but much damage had been done. Afterward there was a witch hunt (which I staunchly oppose, but I digress). It turned out that the PM had taken the word of another PM who in turn heard from another that had gone on location and misunderstood what the customer was saying. To save a few thousand bucks the company only sent one person and expected them to brief everybody else on their findings. In hindsight I'm sure that skinnier travel budget wasn't so worth it.
  - freedomben 8y ago
    Yes, but I don't think it's wise or effective to put the onus all on a PM. As a dev, we often can have great insights into how much work/effort/maintainability one feature or another is, and having a rough knowledge of the business domain allows us to make much better recommendations regarding what we should do. Additionally, in my experience the best engineers have been part product manager anyway, just as the best product managers have been part engineers.
  - EpicEng 8y ago
    Of course there should be people who's primary concern is firguring out what to build, but the buck doesn't stop there. If you're not solving problems you're just a medoicre code jockey. I want to work with people who build iseful things, not people who stop and understanding syntax and think that code is a goal into itself.
  - commandlinefan 8y ago
    “So, you physically carry the specifications to the developers?” “Well, no, my secretary does that...”
  - paulie_a 8y ago
    If a developer is relying only on the product manager without first hand experience. It's a recipe for failure. I am a huge promoter of making devs do CSR, hell even make them do sales calls on occasion. The insight to the end user pain points is important. Devs need to hear it first hand.
- hyperman1 8y ago
  Amen brother. I know. Unfortunately, those above me don't allow me to do it.
EpicEng 8y ago
I have yet to work for a company that doesn't value time spent learning the domain. I'm not impkying these places don't exist, but your comment enters the realm of trope (e.g. all managers are spiky haired, know nothing MBA's). If you work in a place like that, I'm sorry, that sucks.
- gregjor 8y ago
  A lot of startups work this way. A group of people with technical talent but little domain expertise. And they tend to see every problem as a technical problem.

gregjor 8y ago

Domain expertise is not wasted time. It makes the difference between a useful application and a pile of code. Developers should not assume they know more about a business domain than the people working in it.

bobthepanda 8y ago
Isn’t that the job of a product manager, though? To figure out what the product should actually do?
- justapassenger 8y ago
  To be a true engineer, one should use technology to solve problems. PMs are suppose to help with that, but to be called an engineer, one should have that mindset. Otherwise, we're just code-monkeys.
  - gregjor 8y ago
    Yes, but someone has to make sure engineers solve the right problem in a way useful to end users.
- gregjor 8y ago
  Ideally. When I started as a programmer companies had business analysts who had domain expertise and made sure software mapped to the domain and actual users. Now we have PMs, usually glorified project managers, too often with little or no domain expertise or technical understanding. I freelance so I don’t have PMs or analysts, I have to learn the domain and deal with the management/client/users directly.
- daleco 8y ago
  That's also be the job of the UX/Product Designer to learn about the users and business domain.
- Barrin92 8y ago
  tacit knowledge especially in an hands-on field like medicine where patients are involved cannot be conveyed by a manager with a power point presentation. This compartmentalisation in the name of efficiency is actively harmful. Developers should get out more and get first hand experience of the environments they develop software for.
  - freedomben 8y ago
    Could not agree more. It's a bit like the game of telephone that many of us played as children. The more hops in the connection, the greater ability for knowledge loss and distortion. I once had a PM tell us to do a feature a certain way, despite engineers saying we thought it was dumb. We shipped and had lots of user complaints, and lost millions of dollars ultimately in lost revenue due to cancellations that we think were at least in part to this. We eventually reversed course but much damage had been done. Afterward there was a witch hunt (which I staunchly oppose, but I digress). It turned out that the PM had taken the word of another PM who in turn heard from another that had gone on location and misunderstood what the customer was saying. To save a few thousand bucks the company only sent one person and expected them to brief everybody else on their findings. In hindsight I'm sure that skinnier travel budget wasn't so worth it.
- freedomben 8y ago
  Yes, but I don't think it's wise or effective to put the onus all on a PM. As a dev, we often can have great insights into how much work/effort/maintainability one feature or another is, and having a rough knowledge of the business domain allows us to make much better recommendations regarding what we should do. Additionally, in my experience the best engineers have been part product manager anyway, just as the best product managers have been part engineers.
- EpicEng 8y ago
  Of course there should be people who's primary concern is firguring out what to build, but the buck doesn't stop there. If you're not solving problems you're just a medoicre code jockey. I want to work with people who build iseful things, not people who stop and understanding syntax and think that code is a goal into itself.
- commandlinefan 8y ago
  “So, you physically carry the specifications to the developers?” “Well, no, my secretary does that...”
- paulie_a 8y ago
  If a developer is relying only on the product manager without first hand experience. It's a recipe for failure. I am a huge promoter of making devs do CSR, hell even make them do sales calls on occasion. The insight to the end user pain points is important. Devs need to hear it first hand.
hyperman1 8y ago
Amen brother. I know. Unfortunately, those above me don't allow me to do it.

EpicEng 8y ago

I have yet to work for a company that doesn't value time spent learning the domain. I'm not impkying these places don't exist, but your comment enters the realm of trope (e.g. all managers are spiky haired, know nothing MBA's). If you work in a place like that, I'm sorry, that sucks.

gregjor 8y ago
A lot of startups work this way. A group of people with technical talent but little domain expertise. And they tend to see every problem as a technical problem.