4 ms·

I seriously question #4. While the popular tools and languages and techniques churn, there are no fundamental revelations in software development that cannot be

I seriously question #4. While the popular tools and languages and techniques churn, there are no fundamental revelations in software development that cannot be understood at a higher level by somebody who stopped programming in the 70s. If anything, not being obsessed with the churn helps these managers step back and ask fundamental questions that are often ignored by magpie developers. It is very possible to keep up do date on all the new tech coming out at a surface level, ie enough to manage engineers and ask questions, without spending the time to deep dive into the nuts and bolts of each new tech.

camjohnson26 6y ago
For 3, you can keep yourself informed without coding on the job. Continuous education is a common part of many professional careers. Just code a personal project every couple of years and read the tech news and you’ll be fine.
- blacktriangle 6y ago
  Not to mention just sitting in on code reviews and listening to the developers will help keep you continuously educated. Take notes and read up on any debates that come up that confuse you.
gfodor 6y ago
No, I'm not talking about those kinds of skills per se. ("Fundamental revelations.") I'm talking about: - Grokking what actually sucks about the tools, languages, frameworks, etc in use. And grokking what complaints of suckiness are shallow or misplaced. The former is an opportunity to deliver empathy for the team's suffering and propose good solutions, the latter is an opportunity to remind engineers (esp junior ones) not to be overly-cynical or see problems where they don't truly exist. - Ability to participate as a true peer in technical discussions, which deepens the bond you have with your team. If you are able to contribute one or two concrete, correct, and actionable ideas that unblock developers or the project's construction every quarter, it pays dividends imo in counteracting dynamics where you are considered an "other" in certain contexts given your position. I'm not talking about things like "maybe you should write some tests" but "maybe you should ditch that testing framework because the problem you are hitting is a non-issue if you just write a special harness yourself. You can start from mine." It's no silver bullet, but it helps. If you literally save a week's worth of effort for a team member by cleverly reframing the work they are doing to a better MVP they can handle (via your domain knowledge and intuition about implementation difficulty) they will be unlikely to care if you accidentally forgot to send them a birthday email. If you don't do that regularly, and basically are a full people manager, the missing birthday email could be a big problem. - If you aren't in the trenches at all, lots of problems will crop up over time that are insidiously hard to see once you've exited having the domain knowledge. For example, you won't be able to assess talent well enough to flag bullshitters who manage to sneak past your team's interviews. (Given you are the manager, you probably tilt more towards having the people skills needed to detect bullshitters which your team lacks, but without domain knowledge, neither you nor your team may have the total sum of skills needed to detect them.) Or, when giving overview discussions of how the software systems work to other managers, your team members might have to start biting their tongues when you're explaining things in a way that is objectively incorrect but coherent in your (now shallow) mental models. Having to regularly hear your manager saying something that is totally wrong is demoralizing, because it means you either have to "educate" your manager, which is awkward, or you have to effectively endorse what they are saying by staying silent. All of these come from a loss of literacy in the local domain of the work your team is doing, not in general principles. These are totally different forms of literacy, and the latter one is dynamic and requires effort to maintain (and losing it comes opportunity cost.) Edit: Also, people saying sitting in code reviews is good enough are fooling themselves imo - to believe that you also generally need to believe that you can become a good programmer on a project by just doing code reviews enough and then instantly be able to execute as a top-tier team member. This is objectively false. So the question is what margin is needed between "code review level literacy" and "building literacy" to get the benefits I mention. I'd argue it's a pretty big margin.
- jgeada 6y ago
  Trust. What you're really talking about is trust. If you're not coding 100% of the time on important value add tasks, you're not ever going to be as technical or as current on the details as your team. As a manager being the technical lead IS NOT YOUR JOB. You have people for that. Empower them, listen to them, arbitrate between them, enable them to get their job done. It is not your job to decide what technology is best, your team is the one with that know how and will offer you choices and tradeoffs; if you need to decide you'll need to trust their information to choose the best set of tradeoffs for the business strategey. Trust them to give you the right data. Nurture the team so they don't lie to you; if they're lying to you, there are much bigger problems to solve than the technical details.
- njwi332 6y ago
  I completely agree with you. How do you prevent this happening? I've relocated from a team where I used to be a software engineer on the team (and therefore had a peer-level understanding of the systems) to one in a different company where I'm starting from day 1 as a manager. How do you maintain/build that localized domain knowledge? It doesn't feel like it's solvable by doing a week of coding now and again.

camjohnson26 6y ago

For 3, you can keep yourself informed without coding on the job. Continuous education is a common part of many professional careers. Just code a personal project every couple of years and read the tech news and you’ll be fine.

blacktriangle 6y ago
Not to mention just sitting in on code reviews and listening to the developers will help keep you continuously educated. Take notes and read up on any debates that come up that confuse you.

gfodor 6y ago

No, I'm not talking about those kinds of skills per se. ("Fundamental revelations.") I'm talking about: - Grokking what actually sucks about the tools, languages, frameworks, etc in use. And grokking what complaints of suckiness are shallow or misplaced. The former is an opportunity to deliver empathy for the team's suffering and propose good solutions, the latter is an opportunity to remind engineers (esp junior ones) not to be overly-cynical or see problems where they don't truly exist. - Ability to participate as a true peer in technical discussions, which deepens the bond you have with your team. If you are able to contribute one or two concrete, correct, and actionable ideas that unblock developers or the project's construction every quarter, it pays dividends imo in counteracting dynamics where you are considered an "other" in certain contexts given your position. I'm not talking about things like "maybe you should write some tests" but "maybe you should ditch that testing framework because the problem you are hitting is a non-issue if you just write a special harness yourself. You can start from mine." It's no silver bullet, but it helps. If you literally save a week's worth of effort for a team member by cleverly reframing the work they are doing to a better MVP they can handle (via your domain knowledge and intuition about implementation difficulty) they will be unlikely to care if you accidentally forgot to send them a birthday email. If you don't do that regularly, and basically are a full people manager, the missing birthday email could be a big problem. - If you aren't in the trenches at all, lots of problems will crop up over time that are insidiously hard to see once you've exited having the domain knowledge. For example, you won't be able to assess talent well enough to flag bullshitters who manage to sneak past your team's interviews. (Given you are the manager, you probably tilt more towards having the people skills needed to detect bullshitters which your team lacks, but without domain knowledge, neither you nor your team may have the total sum of skills needed to detect them.) Or, when giving overview discussions of how the software systems work to other managers, your team members might have to start biting their tongues when you're explaining things in a way that is objectively incorrect but coherent in your (now shallow) mental models. Having to regularly hear your manager saying something that is totally wrong is demoralizing, because it means you either have to "educate" your manager, which is awkward, or you have to effectively endorse what they are saying by staying silent. All of these come from a loss of literacy in the local domain of the work your team is doing, not in general principles. These are totally different forms of literacy, and the latter one is dynamic and requires effort to maintain (and losing it comes opportunity cost.) Edit: Also, people saying sitting in code reviews is good enough are fooling themselves imo - to believe that you also generally need to believe that you can become a good programmer on a project by just doing code reviews enough and then instantly be able to execute as a top-tier team member. This is objectively false. So the question is what margin is needed between "code review level literacy" and "building literacy" to get the benefits I mention. I'd argue it's a pretty big margin.

jgeada 6y ago
Trust. What you're really talking about is trust. If you're not coding 100% of the time on important value add tasks, you're not ever going to be as technical or as current on the details as your team. As a manager being the technical lead IS NOT YOUR JOB. You have people for that. Empower them, listen to them, arbitrate between them, enable them to get their job done. It is not your job to decide what technology is best, your team is the one with that know how and will offer you choices and tradeoffs; if you need to decide you'll need to trust their information to choose the best set of tradeoffs for the business strategey. Trust them to give you the right data. Nurture the team so they don't lie to you; if they're lying to you, there are much bigger problems to solve than the technical details.
njwi332 6y ago
I completely agree with you. How do you prevent this happening? I've relocated from a team where I used to be a software engineer on the team (and therefore had a peer-level understanding of the systems) to one in a different company where I'm starting from day 1 as a manager. How do you maintain/build that localized domain knowledge? It doesn't feel like it's solvable by doing a week of coding now and again.