Hacker News Reader

Comment by _ph_ | Hacker News Reader

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.

View on HN

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.

Wishful thinking.

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.

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.

Managers that only see Excel sheets and think software development is like factory work.

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.

I have several offshoring projects under my belt and have been doing consulting for 14 years.

Where are those managers?

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.

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

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

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.

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.

I've been tackling the opposite. Product specs their thing which is completely disconnected from the reality of what is actually needed. This creates massive levels of frustration for the end user.

Boeing management used to be grown from engineers. The person promoted would have been practicing "engineering in the large." I don't know if that's still true.

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

Why heartbreaking? That should make it easier for everybody to do their job, and to do it better.

> after some* years of experience, the programmers understand the business just as well as they do.

I don't push back on the premise that there are some incredibly dumb non-engineers. But of all the people I've had to work with, engineers were among the best and the worst. The latter has to do with their dysfunctional level of focus and utter lack of creativity - not just in an artistic way, but also in terms of general imagination.

Here's a very common scenario:

- non-engineer: let's improve this by 10%.

- engineer: that will cost 40%.

- non-engineer: I get that. But our current 90% is not competitive.

- engineer: but it doesn't make sense to invest 40% to get 10%.

That's what separates great engineers from the high-IQ/low-EQ ones: they have taste, imagination, and common sense. Incidentally, the latter group tends to have less self-awareness than the former, and tends to think they are the only non-idiots in the world.

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.

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.

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.

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.

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

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.

> contractor, who might be brilliant at programming

I have yet to meet one of those unicorns.

They probably get hired pretty quickly and cease contracting.

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.

Reply on news.ycombinator.com