4 ms·

(BTW I am 40, have been working as dev for the past 21 years and I am now transitioning to my first non-development role ever after working as tech lead / senio

(BTW I am 40, have been working as dev for the past 21 years and I am now transitioning to my first non-development role ever after working as tech lead / senior dev for over a decade) > Sure having some understanding of software is helpful as a manager but IMHO this only includes skills up to the "mid"/"just after junior" software dev level. I disagree. There is a lot of useful skills that a developer can pick up usually only after you are very comfortable with the coding and technical problem solving. Ability to improve processes, being able to influence morale of your team, ability to think though a coherent strategy for what you are working on, handling emergencies, preventing emergencies, creating space for your teammembers so that they can thrive, teaching others useful skills, managing up, and so on and so forth. > So if a senior software developer becomes a manager it's wasting their potential as software developer. Sure. But maybe they can now "leverage" (building towards that bullshit bingo card...) their experience in a position that has more impact?

kcplate 5y ago
> For me ability to code (like knowledge of programming language) is a necessary but relatively minor ability of a good software developer. Absolutely. I have been in tech since the eighties and it’s remarkable to me how all the other skills that used to be necessary to create quality systems have seemingly taken a backseat to this skill. There are far to many developers with a severe lack of good engineering and troubleshooting capabilities nowadays…but boy are they fluent in the language de jour
- bboylen 5y ago
  What is the best way to develop engineering & troubleshooting capabilities? Definitely seems a lot less clear cut than just practicing a language
  - kcplate 5y ago
    I think to a certain degree it’s just an innate capacity for creativity coupled with logic that gets refined in practice. If you don’t have those core components in you you are pretty much at a disadvantage to develop them. To be honest in the last 10-15 years with the shift to Agile it really feels like the type of folks who become software devs prior to that shift represent about 15-20% of the new devs now. The rest are kind of just commodity devs. Give them good detailed requirements and they can churn out code. That 15-20% are the ones who can churn out something without a hyper level of detail or refined requirements.
CaptArmchair 5y ago
I'm 40 but I've been on both sides of the aisle. It's not just moving from a "development" into a "non-development" role. You're basically moving into an environment with very different incentives, interpersonal relationships and so on. As a tech lead / senior developer, you're very much part of the operational level, and your decisions are mostly tactical and working from an existing strategical framework which you don't control. That changes when you move into a (mid) management role. You now have to come up with overarching strategems, long term vision, be able to form strong alliances, navigate political landscapes, know who will fight you and why they will fight you, be able to broker deals and understand how your stance on a current issue creates much needed leverage down the road. Technical knowledge matters far less. Being prepared when going into a meeting room means knowing who sits in front of you, what drives their motivations, what they want / oppose, and having a deep understanding of what you can say, and - more importantly - how you are going to say it. People will try to get under your skin, not because they have a personal dislike of you, but simply because the position you were promoted / hired into may be perceived as threatening to them. You're skin needs to grow thick. At this level, the people you're going to work with don't care how the pie is being made. They want to leverage software to act on their larger strategic goals. You will have to promote technology not just because of its merits for developers, but above all because of the value it provides to stakeholders. You have to find selling points that resonate with the stakeholders you're supposed to cater to. And you have to ensure you can deliver on your word. So, how does this apply to software developers? When you're working at an operational level, dealing with day-to-day emergencies and issue queues, working with a small team of people, building / maintaining systems and applications,... you're not really exposed to all of the above. Your supervisor is supposed to shield you from all of this and defend the work you and your team is doing. When you move up into that (mid) managerial level, you're moving into a very different world which requires skills and experience you can't easily acquire on an operational level as an IC. Now, that doesn't mean it's impossible to grow into that level. You're transitioning into it, right? Your being recognized for your skills, the experience and the perspective you've grown over the past two decades. The big challenge ahead of you is learning how to actively "let go" of that operational level and delegate anything and everything operational so you can spend your time advocating for the stakeholders you're supposed to represent. However, making this career change isn't for everyone. Nor is it something that ought to be seen as a marker for "career success". There's a lot of merit in being a senior developer who is keenly aware of the decision making process upstream and how things move, so they can organize work on the operational level accordingly. And this includes taking the lead in making pragmatic technical decisions regarding architecture, incorporating technologies, programming practices, documentation, setting priorities and so on. This is what sets them apart from someone who's at the beginning of their career and still has a lot to figure out about themselves as well as the workplace and everything involved in the process of building software and delivering value.

kcplate 5y ago

> For me ability to code (like knowledge of programming language) is a necessary but relatively minor ability of a good software developer. Absolutely. I have been in tech since the eighties and it’s remarkable to me how all the other skills that used to be necessary to create quality systems have seemingly taken a backseat to this skill. There are far to many developers with a severe lack of good engineering and troubleshooting capabilities nowadays…but boy are they fluent in the language de jour

bboylen 5y ago
What is the best way to develop engineering & troubleshooting capabilities? Definitely seems a lot less clear cut than just practicing a language
- kcplate 5y ago
  I think to a certain degree it’s just an innate capacity for creativity coupled with logic that gets refined in practice. If you don’t have those core components in you you are pretty much at a disadvantage to develop them. To be honest in the last 10-15 years with the shift to Agile it really feels like the type of folks who become software devs prior to that shift represent about 15-20% of the new devs now. The rest are kind of just commodity devs. Give them good detailed requirements and they can churn out code. That 15-20% are the ones who can churn out something without a hyper level of detail or refined requirements.

CaptArmchair 5y ago

I'm 40 but I've been on both sides of the aisle. It's not just moving from a "development" into a "non-development" role. You're basically moving into an environment with very different incentives, interpersonal relationships and so on. As a tech lead / senior developer, you're very much part of the operational level, and your decisions are mostly tactical and working from an existing strategical framework which you don't control. That changes when you move into a (mid) management role. You now have to come up with overarching strategems, long term vision, be able to form strong alliances, navigate political landscapes, know who will fight you and why they will fight you, be able to broker deals and understand how your stance on a current issue creates much needed leverage down the road. Technical knowledge matters far less. Being prepared when going into a meeting room means knowing who sits in front of you, what drives their motivations, what they want / oppose, and having a deep understanding of what you can say, and - more importantly - how you are going to say it. People will try to get under your skin, not because they have a personal dislike of you, but simply because the position you were promoted / hired into may be perceived as threatening to them. You're skin needs to grow thick. At this level, the people you're going to work with don't care how the pie is being made. They want to leverage software to act on their larger strategic goals. You will have to promote technology not just because of its merits for developers, but above all because of the value it provides to stakeholders. You have to find selling points that resonate with the stakeholders you're supposed to cater to. And you have to ensure you can deliver on your word. So, how does this apply to software developers? When you're working at an operational level, dealing with day-to-day emergencies and issue queues, working with a small team of people, building / maintaining systems and applications,... you're not really exposed to all of the above. Your supervisor is supposed to shield you from all of this and defend the work you and your team is doing. When you move up into that (mid) managerial level, you're moving into a very different world which requires skills and experience you can't easily acquire on an operational level as an IC. Now, that doesn't mean it's impossible to grow into that level. You're transitioning into it, right? Your being recognized for your skills, the experience and the perspective you've grown over the past two decades. The big challenge ahead of you is learning how to actively "let go" of that operational level and delegate anything and everything operational so you can spend your time advocating for the stakeholders you're supposed to represent. However, making this career change isn't for everyone. Nor is it something that ought to be seen as a marker for "career success". There's a lot of merit in being a senior developer who is keenly aware of the decision making process upstream and how things move, so they can organize work on the operational level accordingly. And this includes taking the lead in making pragmatic technical decisions regarding architecture, incorporating technologies, programming practices, documentation, setting priorities and so on. This is what sets them apart from someone who's at the beginning of their career and still has a lot to figure out about themselves as well as the workplace and everything involved in the process of building software and delivering value.