> It’s often a smart political tactic to make your work sound slightly more complicated than it really is. Otherwise you risk falling into the “you made it look easy, therefore we didn’t need to pay you so much” trap. But it’s foolish to actually do unnecessarily complicated work. Software is hard enough as it is.
Totally agree here with the part where "it’s foolish to actually do unnecessarily complicated work"!
But I'd say the ultimate job security is being known as someone who creates real value to the organization, and the way you do that is by putting in extra effort into understanding and communicating the business value of your work.
for example: the latency reduction is not just a latency reduction, it's an increase in x% in revenue.
I mean, I have seen both sides of the story. People putting too much effort into simplifying things where the product users just do not care about it, as well as people overcomplicating things while implementing features up to the point of the program being non-functioning (or very hard to update).
I would say that it is more about how coupled your field and the product you are building are with it being implemented properly. For some areas, like most of the web or building SaaS, it is not as tightly coupled as for other areas like system engineering, building high-performance products, etc.
Engineers who ship get promoted. Sometimes they also write simple code. Often they do not.
> It’s often a smart political tactic to make your work sound slightly more complicated than it really is. Otherwise you risk falling into the “you made it look easy, therefore we didn’t need to pay you so much” trap. But it’s foolish to actually do unnecessarily complicated work. Software is hard enough as it is.
Totally agree here with the part where "it’s foolish to actually do unnecessarily complicated work"!
But I'd say the ultimate job security is being known as someone who creates real value to the organization, and the way you do that is by putting in extra effort into understanding and communicating the business value of your work.
for example: the latency reduction is not just a latency reduction, it's an increase in x% in revenue.
I mean, I have seen both sides of the story. People putting too much effort into simplifying things where the product users just do not care about it, as well as people overcomplicating things while implementing features up to the point of the program being non-functioning (or very hard to update).
I would say that it is more about how coupled your field and the product you are building are with it being implemented properly. For some areas, like most of the web or building SaaS, it is not as tightly coupled as for other areas like system engineering, building high-performance products, etc.