4 ms·

I hate that word "impact". As an engineer my job should be to engineer systems not to worry about how the business is running and how much profit it makes. I kn

by proc0 2y ago

I hate that word "impact". As an engineer my job should be to engineer systems not to worry about how the business is running and how much profit it makes. I know this is not how most companies work but I feel it is at the core of a lot of disfunction in the practice of making software. It's like hiring a plumber and telling them "your job is to create the most impact in my house"... uh, no... how about you tell me what you want or what the problem is, and if you want an overhaul that can be done as well. This whole "create impact" and "add business value" is such a sneaky way to exploit people, and of course there are many people who oblige and just dedicate their entire careers to running a business instead of being engineers and implementing things properly.

fosterfriends 2y ago
Agreed! > "Do You Even Want to Be 10x? You don’t have to. You’re not a lesser engineer if you operate at a steady clip, write clean code, and value stable processes. Seriously. Some workplaces thrive on consistent, methodical improvement—and a 10x renegade might actually hurt them."
HPsquared 2y ago
Plumbers do often use initiative and offer improvements over what the customer initially requested.
- proc0 2y ago
  Of course, but the expectation wouldn't be "make my house better", it would be specific to plumbing and making the pipes work. It wouldn't make sense to expect them to add a guest bathroom because that's better for the house.
evujumenuk 2y ago
As an engineer — in other words: a salaried employee — you're already a businessperson. How do you negotiate for better total compensation or benefits if you reject knowing, and thus positively influencing, your worth to the company? If you really don't want to engage in that sort of thing, I'm sure there's a lot of companies that'll let you be a fungible code monkey for pennies…
- proc0 2y ago
  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.
  - evujumenuk 2y ago
    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".
    - proc0 2y 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.
bdangubic 2y ago
As an engineer my job should be to engineer systems not to worry about how the business is running and how much profit it makes. and yet you don’t actually get to be an engineer if the business is not running and profits are not made - if that happens you get canned and you have to find another place to engineer. the whole purpose of your employment is that you should generate more value to the company than your compensation. people that are not aware of this will have a difficult career in front of them
- proc0 2y ago
  Sure, but you are describing something that is not an engineering problem, and part of my point is that this has consequences for the business as well. We're really talking about how the roles are divided in teams within an org, and increasingly engineers are having to worry about non-engineering tasks and I have experienced this causing a lot of issues in the long run for the business. I'm basically saying that if you make the roles wear too many hats then they can't be experts in their domain and this has consequences sooner or later. One of the ways companies dilute the roles is by telling them to "create impact", instead of say create systems with no bugs and that can be iterated upon quickly.
  - bdangubic 2y ago
    I'm basically saying that if you make the roles wear too many hats then they can't be experts in their domain and this has consequences sooner or later. One of the ways companies dilute the roles is by telling them to "create impact", instead of say create systems with no bugs and that can be iterated upon quickly. I don’t disagree with just about everything you wrote except for one perhaps fundamental issue - what I think is engineers (best ones, 10x ones) always think of the business and in order to do that they must learn the business inside and out. and their engineering decisions need to heavily weight on the business. here’s a personal example, I’ve worked as lead engineer on software solution that is deployed in courthouses across the united states. we were working on modernization (basically creating an enterprise version of legacy powerbuilder app)… up until that point I have been in this industry for 9 years and have worked on-site in a courthouse in colorado for 3. I was intimately familiar with both the innerworkings on the courthouses but also demographic if the entire user-base. hence, ALL engineering decisions were made with the business in mind, how does my company win new business, how does the business work overall… if someone else was leading this effort who was not familiar with the business the new app could have been an absolute marvel of engineering with every imaginable bell and whistle but would likely have been a collosal failure

by proc0 2y ago

fosterfriends 2y ago

Agreed! > "Do You Even Want to Be 10x? You don’t have to. You’re not a lesser engineer if you operate at a steady clip, write clean code, and value stable processes. Seriously. Some workplaces thrive on consistent, methodical improvement—and a 10x renegade might actually hurt them."

HPsquared 2y ago

Plumbers do often use initiative and offer improvements over what the customer initially requested.

proc0 2y ago
Of course, but the expectation wouldn't be "make my house better", it would be specific to plumbing and making the pipes work. It wouldn't make sense to expect them to add a guest bathroom because that's better for the house.

evujumenuk 2y ago

As an engineer — in other words: a salaried employee — you're already a businessperson. How do you negotiate for better total compensation or benefits if you reject knowing, and thus positively influencing, your worth to the company? If you really don't want to engage in that sort of thing, I'm sure there's a lot of companies that'll let you be a fungible code monkey for pennies…

proc0 2y ago
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.
- evujumenuk 2y ago
  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".
  - proc0 2y 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.

bdangubic 2y ago

As an engineer my job should be to engineer systems not to worry about how the business is running and how much profit it makes. and yet you don’t actually get to be an engineer if the business is not running and profits are not made - if that happens you get canned and you have to find another place to engineer. the whole purpose of your employment is that you should generate more value to the company than your compensation. people that are not aware of this will have a difficult career in front of them

proc0 2y ago
Sure, but you are describing something that is not an engineering problem, and part of my point is that this has consequences for the business as well. We're really talking about how the roles are divided in teams within an org, and increasingly engineers are having to worry about non-engineering tasks and I have experienced this causing a lot of issues in the long run for the business. I'm basically saying that if you make the roles wear too many hats then they can't be experts in their domain and this has consequences sooner or later. One of the ways companies dilute the roles is by telling them to "create impact", instead of say create systems with no bugs and that can be iterated upon quickly.
- bdangubic 2y ago
  I'm basically saying that if you make the roles wear too many hats then they can't be experts in their domain and this has consequences sooner or later. One of the ways companies dilute the roles is by telling them to "create impact", instead of say create systems with no bugs and that can be iterated upon quickly. I don’t disagree with just about everything you wrote except for one perhaps fundamental issue - what I think is engineers (best ones, 10x ones) always think of the business and in order to do that they must learn the business inside and out. and their engineering decisions need to heavily weight on the business. here’s a personal example, I’ve worked as lead engineer on software solution that is deployed in courthouses across the united states. we were working on modernization (basically creating an enterprise version of legacy powerbuilder app)… up until that point I have been in this industry for 9 years and have worked on-site in a courthouse in colorado for 3. I was intimately familiar with both the innerworkings on the courthouses but also demographic if the entire user-base. hence, ALL engineering decisions were made with the business in mind, how does my company win new business, how does the business work overall… if someone else was leading this effort who was not familiar with the business the new app could have been an absolute marvel of engineering with every imaginable bell and whistle but would likely have been a collosal failure