3 ms·

I was sold this same line since I started my career in software as an intern ~15 years ago. Every year I've become less convinced that fully applying myself is

I was sold this same line since I started my career in software as an intern ~15 years ago. Every year I've become less convinced that fully applying myself is worth it for my career. Any time that I've stepped up to fill a gap when it didn't directly benefit the short-term perception of my manager/skip-level, the effort was undersold or outright ignored. Edit: ok - I'll admit, I didn't read the whole article at first. I still stand by my point, though - even when I'm simply identifying those gaps and not fixing them, I still don't see engineers being rewarded proportionally for the value they're bringing their employers.

quickthrower2 4y ago
Sometimes it is better to leave the gap. Let someone feel the pain. And have it consciously fixed by management. Depends what the gap is. Small gaps (QA person is sick today, so can someone test...) I would just fill them if they are not happening all the time.
- malfist 4y ago
  Agree with this. Pain points are cleavage. Let them be felt, then leverage them into making your improvements known. I so often see junior engineers making work for themselves by "fixing" things that weren't broken. This is often the case when they want to refactor something to make it better. If you can't measure the improvement, it's hard to make the case you actually improved things. Legacy code is like settled law, touched only when absolutely necessary.
yellow_lead 4y ago
It always depends - on the company, leadership, and each particular situation. Always pick your battles wisely :)
athrowaway3z 4y ago
> I still don't see engineers being rewarded proportionally for the value they're bringing their employers. My theory is that's because the relationship between employers and engineers has an off by 1 error. Non-software folks see 'managers managing software developers creating software' in a similar dynamic as 'managers managing drivers driving trucks'. Whereas I believe it is better to frame the function of software engineers as 'managers managing code handling data'. From the business perspective, its software engineers should be seen as managers. Its just that what they manage doesn't require HR or sick days. And just like a re-organization of the business, software updates might take more than a sprint or two.
AlwaysRock 4y ago
Isnt this the point of the article? Also early in my career I had a boss who told me something like, "I know X is a problem. It's easy to point out X is a problem. It's hard to point out X is a problem, figure out a solution for it, and time/manpower/money to fix it" Pointing out issues is easy. Most of the time you're not going to point out something that no one has noticed before. Many issues are known. They just havnt been solved because they are too hard compared to the payoff or they are not that big of an issue.

quickthrower2 4y ago

Sometimes it is better to leave the gap. Let someone feel the pain. And have it consciously fixed by management. Depends what the gap is. Small gaps (QA person is sick today, so can someone test...) I would just fill them if they are not happening all the time.

malfist 4y ago
Agree with this. Pain points are cleavage. Let them be felt, then leverage them into making your improvements known. I so often see junior engineers making work for themselves by "fixing" things that weren't broken. This is often the case when they want to refactor something to make it better. If you can't measure the improvement, it's hard to make the case you actually improved things. Legacy code is like settled law, touched only when absolutely necessary.

yellow_lead 4y ago

It always depends - on the company, leadership, and each particular situation. Always pick your battles wisely :)

athrowaway3z 4y ago

> I still don't see engineers being rewarded proportionally for the value they're bringing their employers. My theory is that's because the relationship between employers and engineers has an off by 1 error. Non-software folks see 'managers managing software developers creating software' in a similar dynamic as 'managers managing drivers driving trucks'. Whereas I believe it is better to frame the function of software engineers as 'managers managing code handling data'. From the business perspective, its software engineers should be seen as managers. Its just that what they manage doesn't require HR or sick days. And just like a re-organization of the business, software updates might take more than a sprint or two.

AlwaysRock 4y ago

Isnt this the point of the article? Also early in my career I had a boss who told me something like, "I know X is a problem. It's easy to point out X is a problem. It's hard to point out X is a problem, figure out a solution for it, and time/manpower/money to fix it" Pointing out issues is easy. Most of the time you're not going to point out something that no one has noticed before. Many issues are known. They just havnt been solved because they are too hard compared to the payoff or they are not that big of an issue.