undefined | Better HN

0 pointsproc01y ago0 comments

I get what you're saying but this is inherently a contradiction:

> As an engineer — in other words: a salaried employee — you're already a businessperson.

An engineer is NOT a business person. I don't recall business fundamentals in computer science classes... but I get it, most companies see full time employees as part of the business that they are responsible for.

The main problem I see is that it becomes an issue as to where the boundaries of the role is, and therefore pushes engineers away from their focus and that leads to more problems down the line. I've seen this so many times in my career and I can attribute it to the fact that orgs do not respect how hard engineering is, so they think they can have this role wear many hats, and then you have applications that are fragile and hard to work with. I get anyone can quit and find a better job, but that's besides the point. "Impact" is just a lazy way for businesses to define roles.

0 comments

3 comments · 1 top-level

evujumenuk1y ago· 2 in thread

Do you receive financial remuneration for your services as an engineer? Then I'd say you're engaging in an ongoing business transaction. As such, the parties to the contract this is happening under will each evaluate whether continuing the existing business relationship is worthwhile.

You may think that this kind of deliberation is outside of the context of what being an engineer is, but it's certainly not outside of the context of what being an employee is. If you wish to be an engineer and not be saddled with business stuff, don't demand compensation, or only token compensation, which is what I alluded to at the end of my last post. In the context of business, all parties need to constantly prove that what they're providing is worth more than what they're asking for.

You can work at a company that asks for "impact", and be given a degree of agency for determining which problems are worth solving, and solve them, hopefully leading to increased revenue, reduced costs, or reduced risks. Or, you can not do that, do whatever Jira asks you to do next, and have no case as to why the company should give you more money or indeed continue to employ you in favor of another engineer who can demonstrate more of an "impact".

proc0OP1y ago

Right, you are basically saying that because the company pays you, you are obliged to just do what you are paid for, and that can be literally anything within legal boundaries and the success of the company.

I acknowledge that, and I am also pointing out that it isn't very helpful as a goal for something that is meant to be a specialized domain. Telling them to "create impact" is borderline tautological. Obviously every employee needs contribute and make the business money, but it should be up to the stakeholders and leadership to be a little more specific as to what the goals are, and let the engineers focus on doing engineering.

For example, we see a lot engineers transition to management because of this kind of expectation that running the business is always the priority. This causes a lack of domain specific expertise which is filled with new engineers, which causes a lot of inconsistencies in the software systems, which creates complexity, bugs, slows down development, etc., and this costs a lot money, just because engineering is being underestimated in favor of doing more business-centric tasks.

evujumenuk1y ago

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.

1 more reply

j / k navigate · click thread line to collapse