5 ms·

This is really a crucial point. I am a software developer in an engineering company. What is essential for my job is not only my programming skills, but also a

by _ph_ 5y ago

This is really a crucial point. I am a software developer in an engineering company. What is essential for my job is not only my programming skills, but also a decent understanding of the engineering I deal with. This can only be achieved by working long enough in the job, be it an engineer who picks up programming or a software developer who learns the engineering involved. This is of course much more expensive than picking up any contractor, who might be brilliant at programming, but lacks the domain knowledge that only grows over time, but it is a good way of having more eyes spotting potential spec issues.

rbanffy 5y ago
I really fail to understand the logic that may make someone to think a software engineer, however brilliant, can write software for a domain they don’t understand.
- slipframe 5y ago
  Wishful thinking.
- Aperocky 5y ago
  If this brilliance can be translated to understanding in other fields, which usually it can. This requires studying, which firms simply tries to avoid. I am a software engineer now, but my major was mechanical engineering, I can barely remember any of my coursework, but I understand how physics work in general, and a small bonus on how to disect a system. Nobody can know everything in today's world and that's why common engineering/sense training is so important IMO.
  - vidanay 5y ago
    Similar. I used to design automation equipment, but I've switched to software development. I'm still closely connected to the mechanical side though. More than once I've had to explain to someone who is a competent programmer that they can't accelerate mass x at rate y.
- pjmlp 5y ago
  Managers that only see Excel sheets and think software development is like factory work.
  - a3n 5y ago
    Total guess, some of those managers probably do appreciate what software engineering is, and what it needs, but they're pressured by their managers to cut costs and expertise.
    - pjmlp 5y ago
      I have several offshoring projects under my belt and have been doing consulting for 14 years. Where are those managers?
  - rodgerd 5y ago
    More than a few programmers are incredibly cocky about "I can write code" turning into "therefore all problems are simple". It's not just managers.
- slumdev 5y ago
  > I really fail to understand the logic that may make someone to think a software engineer, however brilliant, can write software for a domain they don’t understand. This misunderstanding arises out of necessity to compensate for the lack of understanding of the value of nontechnical roles. It's heartbreaking for BAs, POs, PMs, and every other flavor of functionary when they realize that, after some* years of experience, the programmers understand the business just as well as they do. And the programmers have countless other invaluable skills that the functionary could never understand if he studied for a hundred years. *This length of time is variable. Depending on the business domain, it could be anywhere between 1 and 10 years.
  - rbanffy 5y ago
    > It's heartbreaking for BAs, POs, PMs, and every other flavor of functionary when they realize that, after some* years of experience, the programmers understand the business just as well as they do. Shouldn’t be. Very few engineers want to move to BA/PM/PO or management track.
    - lordnacho 5y ago
      I think the point is there shouldn't be BA/PM/PO type people. It should just be engineers all the way. Engineers who understand those roles exist and should be given the reins. Call them whatever but an engineer with domain knowledge is what you need for just about everything.
      - jcims 5y ago
        I’d be curious how well this scales. We’ve had quite a bit of success moving to a product model for internal services. One thing I’ve observed though is that teams lacking strong PM/PO support tend to start looking inward to develop their roadmap rather than outward. This ends up building little silos in which they are doing something and it’s generally executed well but when you explore their plans it can be hard to see how it connects to the larger view.
        5y ago
- salawat 5y ago
  As a QA person, I have to fight with management to get time slotted for exploration, research, and learning work. There's no point crapping out automation for a domain you can't even hold a conversation with SME with.
- mauvehaus 5y ago
  I wrote calibration software for an instrument used to test airframes. You work very closely with somebody who is a domain expert (the analog guy, in my case) and you explain stuff back and forth until you reach a shared understanding of the problem at hand and how the software implements a solution. And you make damn sure that if either of you has questions or see something funny, you figure it out before you ship.
- duxup 5y ago
  Anyone just handing off software that you know well, or just having another new person work in it. The rate of "Yeah I thought of that too but it's actually a terrible idea." type discussions are somewhere near 100%. You'd hope you could communicate or document or something like that but exceptions are endless.
- deleted 5y ago
  [deleted]
liquidpele 5y ago
> contractor, who might be brilliant at programming I have yet to meet one of those unicorns.
- swiley 5y ago
  They probably get hired pretty quickly and cease contracting.
  - a3n 5y ago
    I knew one of those. He insisted on remaining a contractor, I think for his particular tax situation. He would have to leave the company every so often because of company rules (or labor law?) about how long the company could employee a contractor. Eventually he'd get hired back in, as a contractor.
spfzero 5y ago
And you can't easily get them that domain knowledge when you're only communicating via story descriptions or software requirements documents. They are looking at the problem through a thousands-of-miles-long tunnel.
- SilasX 5y ago
  >They are looking at the problem through a thousands-of-miles-long tunnel. So are the computers that have to actually implement the solution. So that seems like at least as much a blessing as a curse.
jeffrallen 5y ago
Also: trust. It takes time and investment for other engineers to get to know you and feel comfortable explaining their thought process, including parts of the design they are afraid need extra testing. You can't outsource the essential give and take of a correctly functioning cross-domain team.

by _ph_ 5y ago

rbanffy 5y ago

I really fail to understand the logic that may make someone to think a software engineer, however brilliant, can write software for a domain they don’t understand.

slipframe 5y ago
Wishful thinking.
Aperocky 5y ago
If this brilliance can be translated to understanding in other fields, which usually it can. This requires studying, which firms simply tries to avoid. I am a software engineer now, but my major was mechanical engineering, I can barely remember any of my coursework, but I understand how physics work in general, and a small bonus on how to disect a system. Nobody can know everything in today's world and that's why common engineering/sense training is so important IMO.
- vidanay 5y ago
  Similar. I used to design automation equipment, but I've switched to software development. I'm still closely connected to the mechanical side though. More than once I've had to explain to someone who is a competent programmer that they can't accelerate mass x at rate y.
pjmlp 5y ago
Managers that only see Excel sheets and think software development is like factory work.
- a3n 5y ago
  Total guess, some of those managers probably do appreciate what software engineering is, and what it needs, but they're pressured by their managers to cut costs and expertise.
  - pjmlp 5y ago
    I have several offshoring projects under my belt and have been doing consulting for 14 years. Where are those managers?
- rodgerd 5y ago
  More than a few programmers are incredibly cocky about "I can write code" turning into "therefore all problems are simple". It's not just managers.
slumdev 5y ago
> I really fail to understand the logic that may make someone to think a software engineer, however brilliant, can write software for a domain they don’t understand. This misunderstanding arises out of necessity to compensate for the lack of understanding of the value of nontechnical roles. It's heartbreaking for BAs, POs, PMs, and every other flavor of functionary when they realize that, after some* years of experience, the programmers understand the business just as well as they do. And the programmers have countless other invaluable skills that the functionary could never understand if he studied for a hundred years. *This length of time is variable. Depending on the business domain, it could be anywhere between 1 and 10 years.
- rbanffy 5y ago
  > It's heartbreaking for BAs, POs, PMs, and every other flavor of functionary when they realize that, after some* years of experience, the programmers understand the business just as well as they do. Shouldn’t be. Very few engineers want to move to BA/PM/PO or management track.
  - lordnacho 5y ago
    I think the point is there shouldn't be BA/PM/PO type people. It should just be engineers all the way. Engineers who understand those roles exist and should be given the reins. Call them whatever but an engineer with domain knowledge is what you need for just about everything.
    - jcims 5y ago
      I’d be curious how well this scales. We’ve had quite a bit of success moving to a product model for internal services. One thing I’ve observed though is that teams lacking strong PM/PO support tend to start looking inward to develop their roadmap rather than outward. This ends up building little silos in which they are doing something and it’s generally executed well but when you explore their plans it can be hard to see how it connects to the larger view.
      - 5y ago
salawat 5y ago
As a QA person, I have to fight with management to get time slotted for exploration, research, and learning work. There's no point crapping out automation for a domain you can't even hold a conversation with SME with.
mauvehaus 5y ago
I wrote calibration software for an instrument used to test airframes. You work very closely with somebody who is a domain expert (the analog guy, in my case) and you explain stuff back and forth until you reach a shared understanding of the problem at hand and how the software implements a solution. And you make damn sure that if either of you has questions or see something funny, you figure it out before you ship.
duxup 5y ago
Anyone just handing off software that you know well, or just having another new person work in it. The rate of "Yeah I thought of that too but it's actually a terrible idea." type discussions are somewhere near 100%. You'd hope you could communicate or document or something like that but exceptions are endless.
deleted 5y ago
[deleted]

liquidpele 5y ago

> contractor, who might be brilliant at programming I have yet to meet one of those unicorns.

swiley 5y ago
They probably get hired pretty quickly and cease contracting.
- a3n 5y ago
  I knew one of those. He insisted on remaining a contractor, I think for his particular tax situation. He would have to leave the company every so often because of company rules (or labor law?) about how long the company could employee a contractor. Eventually he'd get hired back in, as a contractor.

spfzero 5y ago

And you can't easily get them that domain knowledge when you're only communicating via story descriptions or software requirements documents. They are looking at the problem through a thousands-of-miles-long tunnel.

SilasX 5y ago
>They are looking at the problem through a thousands-of-miles-long tunnel. So are the computers that have to actually implement the solution. So that seems like at least as much a blessing as a curse.

jeffrallen 5y ago

Also: trust. It takes time and investment for other engineers to get to know you and feel comfortable explaining their thought process, including parts of the design they are afraid need extra testing. You can't outsource the essential give and take of a correctly functioning cross-domain team.