Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> No, but software is inherently different because you can leverage existing software to create more software.

That’s true. But when I put my “software engineering”, “cloud engineer”, or “data engineer” (theoretically) hat on, I can only do work of one person. No matter how good I am at any of it, I won’t be producing more output than someone equally qualified at my own company. Distributing software does have zero marginal cost more or less and that’s why we get paid more than most industries.

but I have seen so many good engineers become senior or tech leads and then forget these details only to then create software that needs constant fixing and eventually rewriting.

This is just like both my general contractor analogy and my real world scenario. As an “staff architect”, I come up with the initial design and get stakeholder buy in. But I defer to the SMEs the cloud architect, the data architect and the software architect who still eats, sleep and breathe the details in their specialty.

Just like the owners of the plumbing company, HVAC company and electrical company are the subject matter experts. The general contractor defers to them.

In the consulting industry at least, there are two ways you can get to the top, by focusing on depth or breadth. But in neither case can you do it by being staff augmentation (the plumber, electrician, or HVAC person), you still have to deal with strategy.

> You just need some basic general knowledge, and they just are time consuming

Knowledge isn’t the issue, it’s wisdom that only comes with experience that I assume you have. Going back to the hypothetical large implementation. It involves someone who does know architecture, development and data. No matter how good your code is, high availability, fault tolerance, redundancy, even throughput comes from the underlying architecture. Code and hands on implementation is usually the least challenging part of a delivery.

Its knowing how to deal with organizational issues, managing dependencies, sussing out requirements, etc



I can grant all of this makes sense for contractors, given that it's not building a career within a single company. I was more talking about full time, long term careers within a single domain.

> No matter how good your code is, high availability, fault tolerance, redundancy, even throughput comes from the underlying architecture. Code and hands on implementation is usually the least challenging part of a delivery.

I agree to a certain extent. Unless the solution is short lived, designing the code to scale properly is extremely important, and this happens at the implementation level where details of how code is being added makes all the difference. I can see how contractors might not be thinking about this, but it's a recurring pattern with legacy systems. Additionally with software, implementation gets automated away if done correctly, so there is only an initial overhead that pays back as the codebase grows larger and larger.

I'm not saying there is no need for engineers that deal with org and management issues, but rather that companies underestimate the need for senior level engineers focusing on the software implementation details, only to pay the price as the codebase inevitably accumulates complexity later as it scales in size.

Anyway, great discussion, I appreciate your input and will be considering it more.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: