4 ms·

There's an easy way to accomplish this: Commit yourself to 95% reading of code and 5% writing. Through great code reviews, spread your knowledge through the com

There's an easy way to accomplish this: Commit yourself to 95% reading of code and 5% writing. Through great code reviews, spread your knowledge through the company and make others as good as you. Has the added benefit of making the stack more homogenous. (I still code review 50% of all commits relating to the data model - SQL & API interfaces myself) Then about the 5% - this is high prio, high visibility fixes where you bring in your extraordinary expertise in some domain. Believe me, that's enough to stay respected. Your time is much better spent at sparring systems architecture & high level design, hiring and building well-oiled teams and discussing the business needs with the rest of the company. Isn't as fun, Doesn't feel as good, but it helps most the long run. The alternative is a high performance coding monkey that gets a tiny area of the company right - and the rest of IT goes wild and rewrites core APIs in the latest three hype language because "we needed to get rid of technical debt". The 44 lessons of the OP are distilled gold from years of experience, I rehearse them every year and can recommend them to any aspiring tech lead.

watwut 9y ago
Code reviews by a dude who codes only a little and has formal power are pure hell. It is tricky when he is wrong, he can force you to do things that cause trouble and so on and so forth - all that because writing and reviewing code are much different and he is gradually out of touch.
- valuearb 9y ago
  Why did you code it that way? How hard is it to answer that question?
  - NortySpock 9y ago
    "It will cause performance problems if you don't" , with only a gut feeling to back it up, and no actual testing. I just ran into this response yesterday, and I ended up going over his head (unfortunately) and asked our DBAs for a recommendation. DBA solution worked faster than either of the previous two solutions. I still need to apologise for that one.
    - mncharity 9y ago
      > I still need to apologise for that one. Curious. Running an idea by people to get their thoughts, because it's currently leaving you short on warm fuzzies... is something to apologize for? The initial solution was low on warm fuzzies for him. Your second solution was low on warm fuzzies for you. So you explored further. Where's the problem?
- sanderjd 9y ago
  It sounds like you've run into some bad apples, likely due to "promoted too early" syndrome, which is unfortunately pretty common. In my experience, code review by senior engineers is extremely valuable whether or not they're currently writing much code.
  - Spooky23 9y ago
    That's why coding managers is dumb. The army figured it out. The Officers are in charge, but the sergeants get shit done. In engineering, your leads/supervisors are the sergeants. Officer quality varies between complete shitbird and Julius Ceasar. Either way, the army marches.
    - dismantlethesun 9y ago
      Sound like tech leads are sergeants and project managers are officers.
      - Spooky23 9y ago
        That's where the analogy breaks a bit. Where I work, PMs don't "own" people, just deliverables. Their main weapon is pestering you.
- pkaye 9y ago
  The bigger problem is other reviewers assume that if the manager approves the review then there is no need for them to do as thorough a review.
Avalyst 9y ago
Programming is a skill just like management. I would argue that if you spend 5% writing and 95% reading you won't be maintaining that skill. If you come from a strong technical background when first promoted (Being the go-to expert on the team or similar) then you can probably keep the respect of the team for a while but eventually others will rise to fill the gap (After all there is 95% of a rockstar programmer's time missing in the team). At that point your comments on code reviews will mostly be seen as micro management. I would say that there are two ways to go about it, either fully trust your developers and let them develop and review their own code or stay as an active member of the team, doing as much coding as you can fit into your schedule. Which route you pick of course depends on the workload of managerial duties.
- sanderjd 9y ago
  This doesn't mesh with my experience. The skill of programming is not in writing code, it is in constructing solutions using code. For someone who has already written software for a long time, I believe critical reading and discussion of code keeps the skill just as sharp. Reading lots of code also gives a broader perspective than writing lots of code, which requires a sort of tunnel vision. Both the deep and the broad perspective are useful on a team.
- BeetleB 9y ago
  >I would argue that if you spend 5% writing and 95% reading you won't be maintaining that skill. The amount a developer (not manager) should code varies from domain to domain. In my work, 5% may be on the low side. But I'd argue in most domains, if you're spending more than 20-30% of your time coding, you're overdoing it and creating too much technical debt. I'm not a manager, but if I were, I'd promote the folks who find (good) reasons not to code than to code. Some problems need software to solve a problem. But writing software should be a last resort. Of course, if you're writing throwaway code on a code base that won't last more than a year or two, code away. Technical debt is not a big concern.

watwut 9y ago

Code reviews by a dude who codes only a little and has formal power are pure hell. It is tricky when he is wrong, he can force you to do things that cause trouble and so on and so forth - all that because writing and reviewing code are much different and he is gradually out of touch.

valuearb 9y ago
Why did you code it that way? How hard is it to answer that question?
- NortySpock 9y ago
  "It will cause performance problems if you don't" , with only a gut feeling to back it up, and no actual testing. I just ran into this response yesterday, and I ended up going over his head (unfortunately) and asked our DBAs for a recommendation. DBA solution worked faster than either of the previous two solutions. I still need to apologise for that one.
  - mncharity 9y ago
    > I still need to apologise for that one. Curious. Running an idea by people to get their thoughts, because it's currently leaving you short on warm fuzzies... is something to apologize for? The initial solution was low on warm fuzzies for him. Your second solution was low on warm fuzzies for you. So you explored further. Where's the problem?
sanderjd 9y ago
It sounds like you've run into some bad apples, likely due to "promoted too early" syndrome, which is unfortunately pretty common. In my experience, code review by senior engineers is extremely valuable whether or not they're currently writing much code.
- Spooky23 9y ago
  That's why coding managers is dumb. The army figured it out. The Officers are in charge, but the sergeants get shit done. In engineering, your leads/supervisors are the sergeants. Officer quality varies between complete shitbird and Julius Ceasar. Either way, the army marches.
  - dismantlethesun 9y ago
    Sound like tech leads are sergeants and project managers are officers.
    - Spooky23 9y ago
      That's where the analogy breaks a bit. Where I work, PMs don't "own" people, just deliverables. Their main weapon is pestering you.
pkaye 9y ago
The bigger problem is other reviewers assume that if the manager approves the review then there is no need for them to do as thorough a review.

Avalyst 9y ago

Programming is a skill just like management. I would argue that if you spend 5% writing and 95% reading you won't be maintaining that skill. If you come from a strong technical background when first promoted (Being the go-to expert on the team or similar) then you can probably keep the respect of the team for a while but eventually others will rise to fill the gap (After all there is 95% of a rockstar programmer's time missing in the team). At that point your comments on code reviews will mostly be seen as micro management. I would say that there are two ways to go about it, either fully trust your developers and let them develop and review their own code or stay as an active member of the team, doing as much coding as you can fit into your schedule. Which route you pick of course depends on the workload of managerial duties.

sanderjd 9y ago
This doesn't mesh with my experience. The skill of programming is not in writing code, it is in constructing solutions using code. For someone who has already written software for a long time, I believe critical reading and discussion of code keeps the skill just as sharp. Reading lots of code also gives a broader perspective than writing lots of code, which requires a sort of tunnel vision. Both the deep and the broad perspective are useful on a team.
BeetleB 9y ago
>I would argue that if you spend 5% writing and 95% reading you won't be maintaining that skill. The amount a developer (not manager) should code varies from domain to domain. In my work, 5% may be on the low side. But I'd argue in most domains, if you're spending more than 20-30% of your time coding, you're overdoing it and creating too much technical debt. I'm not a manager, but if I were, I'd promote the folks who find (good) reasons not to code than to code. Some problems need software to solve a problem. But writing software should be a last resort. Of course, if you're writing throwaway code on a code base that won't last more than a year or two, code away. Technical debt is not a big concern.