This exchange is fascinating to me, because I still feel like we're talking past each other.
I suppose it could be helpful to think of a job designation such as "software engineer" as sort of a shorthand for "businessperson whose toolbox is one of a software engineer" as long as we're in that employer-employee relationship, and if we want to exclude all the pesky business stuff from our daily doing, it cannot be in the context of that relationship.
This also means that all the usual problems of deficient software craftsmanship, such as inconsistencies, accidental complexity, faults, low velocity, and so on, aren't even problems as far as the employer is concerned as long as there is no impact to the business.
In a way, it's inconsistent of you to be concerned that any of these problems is going to cost the business money. Either you accept the task of deciding what's good or bad for business, or you don't.
Some devs who dislike actually engineering around time, money or risk constraints at work do open source stuff in off hours where that stuff doesn't matter. The one to decide if that's worthwhile to you is yourself. In the context of a business, engineering is simply a requirement to what's actually its goal, which is of course making gobloads of money, consistently, with minimal effort.
One thing that I can see though is that in many of these cases where engineering is asked to work on high-impact issues, engineering doesn't actually have all the information, or the toolset required to draw conclusions from it. In that sense, yes, demanding that from engineers comes across as a bit lazy. Nevertheless, it's not like you have to prove to e.g. Netflix that the service doesn't meet your requirements anymore: the onus is on them, and the same way it's on engineers to prove that their salaries are warranted. Of course, that goes both ways, and your employer can fail to meet your own requirements.
The option to have less agency is one that many employers will gladly grant you, but we are not married to companies, and these arrangements have to make sense for us as individuals as well. Hamstringing ourselves from being able to demonstrate our worth doesn't feel like the correct course of action, even if we care more about our produced engineering artifacts than even its buyer does.
If I understood correctly, you're effectively saying that the priority of a software engineer is the success of the business, and that their value is directly correlated to the amount of value they add to the business, and that it's on them to prove and justify this.
The main concept for me is how software engineering is a vehicle for increasing value to any business, since it's about information technology, which is based on automation.
> In a way, it's inconsistent of you to be concerned that any of these problems is going to cost the business money.
I don't see this as inconsistent because an engineer's value to the company should be implicit by the definition of the role.
I guess this is where my disconnect is. I don't see engineering like any other role, i.e. management. I see it as something that should inherently add value if done properly because of its very nature. This may sound like I'm glorifying engineering over other roles, but we're now talking about the possibility of AGI and *replacing* engineers with software made by other engineers, so there's something inherently different about it.
The original context of this was 10x engineers, and how they need to add value to the company, but what better way than to leverage the limitless automation of software to do so (as oppose to having them worry about the direction and details of the business)?
I think what we are really talking about right now is essentially a pair of jobs that, though both called "software engineer", are vastly different in scope.
One of them is a software developer who basically does just that, implement requirements. To enable an engineering department with this type of developer, management needs to already have developed a pretty good view on the business processes that could benefit from automation, or that could become feasible in the first place through software. It is understood that a 5% improvement on the critical path can be more difficult, yet still more worthwhile than a 50% improvement in some less important part of the system. To gain this understanding, management needs to know what is technically possible and perform lots of requirements analysis. After that, well-defined work packets can be handed down to rank and file engineers, and then everyone is on their merry way.
The other kind of software engineer performs most of this support work on their own. Such an engineer has additional responsibilities, but can be useful in many more places because the surrounding support structures don't need to exist. You might not even have to give them specific guidance. However, it means that to use this kind of engineer effectively, you have to expose them to accidentals like time, money and risk, or they will not be able to accurately assess where their talents would be most useful.
Many organizations will actually have both types of engineers. But invariably, the perception of how valuable they are will be heavily skewed in favor of the latter kind of engineer. In the hands of management, they handle like a chef's knife, while the "pure" type of engineer would feel more like a cookie cutter. Even the sharpest, most efficient and most perfect cookie cutter will have a hard time to be perceived as more valuable than a reliable multi-use tool that needs next to no setup for decent results.
The point is, maybe you really hate all that stuff. Nothing stops you from being an awesome cookie cutter. More power to you. I suspect, however, that most of your colleagues would regard that as a career-limiting move.
Yeah that makes sense. There seems to be no escape from assessing the risks and investment, although I think there is some inherent value to doing proper engineering, such that the risk is usually worth it because software automation has accelerating returns, but that is also a hard sell in most cases except highly technical areas.
It's an interesting discussion, thanks for your input!
I suppose it could be helpful to think of a job designation such as "software engineer" as sort of a shorthand for "businessperson whose toolbox is one of a software engineer" as long as we're in that employer-employee relationship, and if we want to exclude all the pesky business stuff from our daily doing, it cannot be in the context of that relationship.
This also means that all the usual problems of deficient software craftsmanship, such as inconsistencies, accidental complexity, faults, low velocity, and so on, aren't even problems as far as the employer is concerned as long as there is no impact to the business.
In a way, it's inconsistent of you to be concerned that any of these problems is going to cost the business money. Either you accept the task of deciding what's good or bad for business, or you don't.
Some devs who dislike actually engineering around time, money or risk constraints at work do open source stuff in off hours where that stuff doesn't matter. The one to decide if that's worthwhile to you is yourself. In the context of a business, engineering is simply a requirement to what's actually its goal, which is of course making gobloads of money, consistently, with minimal effort.
One thing that I can see though is that in many of these cases where engineering is asked to work on high-impact issues, engineering doesn't actually have all the information, or the toolset required to draw conclusions from it. In that sense, yes, demanding that from engineers comes across as a bit lazy. Nevertheless, it's not like you have to prove to e.g. Netflix that the service doesn't meet your requirements anymore: the onus is on them, and the same way it's on engineers to prove that their salaries are warranted. Of course, that goes both ways, and your employer can fail to meet your own requirements.
The option to have less agency is one that many employers will gladly grant you, but we are not married to companies, and these arrangements have to make sense for us as individuals as well. Hamstringing ourselves from being able to demonstrate our worth doesn't feel like the correct course of action, even if we care more about our produced engineering artifacts than even its buyer does.