6 ms·

Strong yes for 3 reasons 1. Reducing dev friction. When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline

• x0x0 2y ago
  Also, I'm just fundamentally skeptical you can do a good job of running a team, or hiring, when you don't know how to do the thing the team does. Software development skill requires active use/work to maintain it.
  • roenxi 2y ago
    Here here. There are a lot of decisions where there is no real contest between the choices to someone who has tried both options but are difficult to tell apart from a distance. EMs should be in a position where they are trying things in practice. I'd draw an example of someone who hasn't used git before, making a choice between a git repo and managing code by keeping daily .zip files. Anyone (almost anyone) who is a career coder won't see a choice there. That example is so basic I think most EM would get that right even if they didn't deal in code but the same dynamic turns up at every level of work. There are situations where there is a right option, the right option is obvious to everyone who is working on it and it is is a drain on the org when management gets confused and thinks that something that isn't an option is viable because they aren't on the ground working on it.
• apwell23 2y ago
  At the same time, they also tend to start interfering in the solutions proposed by their team. It hard to stave off that temptation.
  • whstl 2y ago
    First: it's not "interference" if they are also part of the team. Second: If their ass is on the line, then they DO get a bigger say. They are paid for seeing potential problems, guiding the team, among other things.
    • noirbot 2y ago
      Man, I wish the manager's ass was ever on the line. The amount of times I've seen a manager's whole team get laid off and the manager get moved to a different team to fuck everything up again is too many times. I think I've seen a manager get laid off never. And often seen half their team laid off because they were terrible at their job, but the management class takes care of their own.
      • jamesfinlayson 2y ago
        Yeah if I implemented my manager's ideas, I'd be the one fixing them too. No thanks - if I have to deal with the problems, I'll decide the solutions too.
    • isaacremuant 2y ago
      In practice, many act as an intermediary who can take the credit for the wins while passing down blame for the misses. It's not a good leadership trait but it's an effective career advancing move. The entire list on the post reeks of aspirational intermediary that doesn't actually do any of those things as effectively as empowered project/team leads who do contribute to the product. It's fluff and very easy fluff to remove without feeling pain. Of course, mediocre teams will have mediocre developers who won't want responsabilty and will benefit from intermediary "bossy" managers.
    • apwell23 2y ago
• flashgordon 2y ago
  Just curious have you managed people? At what capacity (tl? Em? Pm?)? How big was your team? What was the company env like in which your team(s) functioned?
  • apwell23 2y ago
    just curious what's your ssn, dob and mother's maiden name.
  • deleted 2y ago
    [deleted]
  • flashgordon 2y ago
    I guess I should have added some context. I have been (and keep swinging between) ic and management roles (including managers) regularly. I love coding and try to sneak in some when I have time (as a manager). But that a manager should always code is not something i found helping the team or the manager - all the time. One size does not fit all. In startups yes frankly there is hardly a need for a manager and it is TL, TPM, EM role combined into one. In larger cos though a most managers are innundated with all kinds of non technical work (meetings, alignment, perf management, product discussions etc). While having coded before is a great thing keeping uptodate is actually robbing the manager of time for all other things on the plate (and those actually benefit the team beyond what meets the eye). Besides at large orgs there is also so much technical (think large scale design and integrations) knowledge that a manager needs to keep track of which also needs time investment. Then there are various level/career related things that necessitate one or more TLs a manager needs to work with or manage and coding often gets seen as a manager "not doing their job" or worse stealing a junior engineers opportunities. There's a lot more that is very environmental but hope sets some context.
• peterldowns 2y ago
  Well said — completely true in my experience. It’s called Engineering Manager for a reason!
• dietr1ch 2y ago
  > 1. Reducing dev friction. This is so important, my managers who didn't code pretended things weren't too bad and took a "just deal with it" attitude whenever I proposed going for a QoL improvement.
  • vrosas 2y ago
    On the flip side I had a manager who had written a lot of the codebase before I joined and had a terrible time allowing anyone to touch his precious baby, regardless of how much his prior ”art” was hurting us, our productivity, and by extension the company.
    • ge96 2y ago
      Yeah... I said it was a "flaming pos" I felt bad about that. But he won't let me add tests so idk whatever. (we prototype software so speed is the main goal but yeah, stuff starts breaking, backtracking, hey... tests)
• eevilspock 2y ago
  I think it depends on how it is done, and the kind of ICs you have on the team. It can come off as micromanagement, which may work well enough if you have not-so-competent ICs, but will backfire if you have talented ones.
  • convolvatron 2y ago
    I've found it really helpful to be a support programmer. not someone that takes on big tasks. nothing with a hard deadline. not something that someone else needs to do their work. leftover cleanup. testing. minor refactoring. build. you need to keep your hand in the game just to understand what's going on with the codebase. but you're not an a-list player here.
  • jamesfinlayson 2y ago
    > It can come off as micromanagement, which may work well enough if you have not-so-competent ICs, but will backfire if you have talented ones. Yep agreed - I've seen a couple of managers that were probably fine as developers but struggled (to their extreme detriment) with being pretty average compared to the senior developers that they were managing. Their 'helpful advice' just served to show how superficial their understandings of the systems were.
• oliwarner 2y ago
  Friction can be more of a problem too though. If your manager is objectively better than the team, estimates can get cut short and failing to meet those adds tension. Obviously a good manager might pitch in, understand their teams capabilities but it's not always a natural transition for senior devs moving to management.
• andoando 2y ago
  I don't see why you need to be writing code to understand all of this. It can help, but almost everything you said is ascertained from daily syncs
  • dv_dt 2y ago
    Fewer or shorter daily syncs is a plus
  • Aeolun 2y ago
    You don’t need to be writing code. But it’s a convenient shortcut to a great many things that otherwise take dedicated effort to understand. Some managers will do that. Most won’t. Given that, it’s easier to just tell them all to code.
    • andoando 2y ago
      Or just tell them all to regularly communicate/listen to their team? Sounds way more efficient.
      • Aeolun 2y ago
        Doesn't work, because the team won't always tell you of the issues that block them (normalization of deviance). Sometimes you need to find out yourself.
        • windward 2y ago
          You can see this when you join a (disfunctional) new team, notice the friction, then suggest improving it.
      • strken 2y ago
        If a manager communicated with and listened to their team, but their team had written a web service with gaping security holes or disastrous data integrity practices because all their senior engineers were incompetent and/or were hired at a level that was above their ability, would that manager find out just from chatting with them? I promise you that it's not guaranteed. You need to actually go looking through the code to find everything that's wrong.
• webdever 2y ago
  I tend to agree but, playing devil's advocate, is this true for other roles? Does a movie director need to know how to build sets? How to sew costumes? How to use Blender/Maya/Houdini? My manager can code, used to code, sometimes does code, but they aren't familiar with their team's current work. Like imagine you were a coding manager 10 years ago with AI experience. Sometime over the last 10 years your team does AI infra. You, as a manager and as an IC, have zero AI experience (you've never trained a model, never used a trained model, never using any of the various AI frameworks). Are you still okay to manage this team or should you be replaced with someone who does have that experience?
  • theresistor 2y ago
    > I tend to agree but, playing devil's advocate, is this true for other roles? Does a movie director need to know how to build sets? How to sew costumes? How to use Blender/Maya/Houdini? I don't know that much about movie making, but my understanding is that there would be managers and/or leads within each specialty, who are (among other things) managing the interaction between their specialty and the director / producers. That seems pretty comparable to what's being discussed here.
    • deleted 2y ago
      [deleted]
  • SpicyLemonZest 2y ago
    In any industry, if you want a team to work well, you have to have someone with both authority and hands-on experience who’s responsible for providing day-to-day guidance. Sometimes that person is called a “supervisor” or “tech lead” instead of “manager”, although this typically implies some division of responsibilities as well; no reason the person providing guidance necessarily has to be the same person reporting to leadership or hiring and firing.
  • mitthrowaway2 2y ago
    Toyota calls it the gemba walk. Managers need to see how the factory is running with their own eyes. Not just live behind a desk and listen to what they hear in meetings. A movie director can see the sets with their own eyes. But you can't see the state of a software codebase without reading and understanding the code, and the most surefire way to do that is to try to write something, even just documentation. You don't assess the state of your software by walking around the office and looking at hands on keyboards. You look at the codebase.
• sodapopcan 2y ago
  > or worked on hard problems because of comments and Git blame. Oh lord we'd better hope they have absolutely IMPECCABLE git fu if they are going to be using this metric. Unfortunately here on HN I've seen people essentially brag that they only know just enough git to get by and "who cares if I don't know all the other commands deeply." In any event, this scenario REQUIRES that a manager know exactly how to determine who originally introduced something, or, exactly where it was significantly improved if they are going to be reading comments and blaming to see "who performs." The very fact a manager might be doing this has got me a little worked up, mainly as I know great managers who don't do this and who are scared of something as simple as the reflog.
• wkat4242 2y ago
  > When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too. For me a good manager is a facilitator, not a leader. Someone who removes obstacles for us. Whether they themselves are affected or not. Someone only fixing an issue because they have to deal with it too seems like a pretty bad manager to me. They're not for pushing targets or trying to weed out non-performance, I don't work at a playschool. My manager is there to make sure I can do my job and that I can reach my maximum potential (including making sure I'm in the right job)
  • mitthrowaway2 2y ago
    When the company tells your manager "we need to cut wood" and you tell your manager "I need to sharpen my axe", these things are in harmony but it's still a balancing act. The manager should trust your judgement, but they may also have a better view of the short-vs-long-term tradeoffs, and sometimes we spend too much time sharpening. Sometimes we don't spend enough. I think a good manager should be able to take a swing with the axe to get a feel for its sharpness.
• wanderr 2y ago
  I think every team needs a TL. If the EM isn't filling that role, then another team member should be, and most of what you're talking about falls on the TL (with some sanity checking from the EM by talking to other team members about these things as well)