3 ms·

I have a strong opinion on this, but it starts at a lower level... A good developer is a developer that makes themselves obsolete. By making themselves obsole

I have a strong opinion on this, but it starts at a lower level... A good developer is a developer that makes themselves obsolete. By making themselves obsolete the developer has made themselves invaluable. How can both of those things be true? This is basically because you find that great developers write code and patterns that make it easy for anyone to jump in an understand. Even if complicated. I strive to do this as much as possible. The more I do this the faster development becomes for myself and my team. However the more I do this, the more my team leads realize that without me, things won't progress in the right direction. But theoretically they can fire me any time and find a cheaper worker to do my job. The point is, I see lots of managers treat engineers as commodities. However if that is their outlook, then they will always look to outsource because they see no value in you. Good managers realize that things are smooth and maintainable because of the people who put effort into doing that, not that because things are smooth and maintainable everyone is expandable. Every time I see the latter being the mindset there's always a HUGE slowdown because the wrong things start being built.

runawaybottle 6y ago
I think the thing you are describing might be seen as a scalar quantity by management. They may just see speed, and not why something is fast. This is unfortunate because if they are operating with scalar conversions then you might misleadingly believe they see the why and how, but in reality are just seeing the what (price or speed or quantity, but not value, impact).
- Justsignedup 6y ago
  well yes, however good management works to check up on that. it is foolish to assume everything is smooth because it is smooth, you want to know why things are going well just like you want to know why they are not. at a high level this is really hard to know. but it is important to know who your talent is, otherwise you replace the talent. many in upper management assume engineering is like factory work, which is how you end up with the most terrible software and no path to fix it :(
luckylion 6y ago
I agree, but in my opinion, that's not about greatness, but about mindset and your understanding of your role. You don't need to be great or write very smart code to get there, you just need to have "somebody must be able to take this over if a bus runs me over tomorrow" and "I want to solve this and move on, not managing it to become my permanent job" as guiding principles when you approach problems. I've seen a very smart developers get fired recently, because he was hogging responsibility and became a bottleneck precisely because he figured that would strengthen his position in the company. "If they need me, they can't fire me". Once "they" figure that out, they will really want to fire you, and if the pain you cause is greater than your value, they will. And it usually always is greater if you're a bottleneck.

runawaybottle 6y ago

I think the thing you are describing might be seen as a scalar quantity by management. They may just see speed, and not why something is fast. This is unfortunate because if they are operating with scalar conversions then you might misleadingly believe they see the why and how, but in reality are just seeing the what (price or speed or quantity, but not value, impact).

Justsignedup 6y ago
well yes, however good management works to check up on that. it is foolish to assume everything is smooth because it is smooth, you want to know why things are going well just like you want to know why they are not. at a high level this is really hard to know. but it is important to know who your talent is, otherwise you replace the talent. many in upper management assume engineering is like factory work, which is how you end up with the most terrible software and no path to fix it :(

luckylion 6y ago

I agree, but in my opinion, that's not about greatness, but about mindset and your understanding of your role. You don't need to be great or write very smart code to get there, you just need to have "somebody must be able to take this over if a bus runs me over tomorrow" and "I want to solve this and move on, not managing it to become my permanent job" as guiding principles when you approach problems. I've seen a very smart developers get fired recently, because he was hogging responsibility and became a bottleneck precisely because he figured that would strengthen his position in the company. "If they need me, they can't fire me". Once "they" figure that out, they will really want to fire you, and if the pain you cause is greater than your value, they will. And it usually always is greater if you're a bottleneck.