Branch off of main
davesnider.com> The basic thesis is one of dedicated roles, with the manager archetype focusing their time towards enablement, communication, and expectation.
No, it's because programming requires a mental model of the software and most managers don't have that. Add in constant interruptions and the inability to focus and you have a recipe for disaster.
Would you sometimes take a break from programming to go help accounting do the accounting work? No, no you wouldn't - accounting would smack the tar out of you. Just because you think you can contribute because you used to be able to is the notion that you need to break, and this applies to other fields too.
> This starts young with telling kids they can't be good at multiple things. "You need to focus."
A lack of focus on a problem space is usually the problem, yes. This isn't because we want people to stay in their lane and want to keep kids from being creative. It's because difficult problems are hard to solve.
If you are going to spend hours pulling down code and building it, ask yourself this question:
"Is this the best use of my time? Is pulling down source code and waiting for a compiler the best thing I as a manager can be doing?"
> No, it's because programming requires a mental model of the software and most managers don't have that. Add in constant interruptions and the inability to focus and you have a recipe for disaster.
This is so strikingly true. I try to explain to people who want me to pause a job and do something else that in my head I have this large, abstract structure of what I am trying to build, that is in an abstraction that itself is ephemeral -- it doesn't map nicely onto black boxes or pipes or anything. It is whatever works at that moment, and it requires me to tour it in my head all the time for it to exist at all.
But to me it isn't a question of focus, strictly speaking, because focus doesn't explain my interaction with that model. It's more a question of relaxed, constant presence; it's about having blur over other stuff. If I can inhabit that model in my brain without having to worry too much, it starts to work itself through while I am doing menial tasks like washing up or laundry or cleaning.
As soon as the business side of my freelance life takes over as it sometimes must, I am suddenly on the outside of that abstraction looking in. And no amount of detailed notes or documentation or diagramming will help me back in quickly.
> I try to explain to people who want me to pause a job and do something else that in my head I have this large, abstract structure of what I am trying to build, that is in an abstraction that itself is ephemeral -- it doesn't map nicely onto black boxes or pipes or anything. It is whatever works at that moment, and it requires me to tour it in my head all the time for it to exist at all.
you can send them this comic directly: https://i.imgur.com/3uyRWGJ.jpg
You can. You can also demonstrate the issue in several other ways.
However, it never works. It may last a week, a day, a few hours, but sooner or later, they're going to believe that you're just staring off into space and that it's fine to interrupt you. That you can pick up and put down your task as easily as you would a pen.
Aha! I had seen this before, and lost it. Thanks :-)
> Would you sometimes take a break from programming to go help accounting do the accounting work? No, no you wouldn't - accounting would smack the tar out of you. Just because you think you can contribute because you used to be able to is the notion that you need to break, and this applies to other fields too.
As a counter-argument to this: With my software side business, I've had to dabble in accounting, and I find it a refreshing break. It's like going outside and pulling some weeds. For me it contributes to my productivity and mental health to have a diverse work experience.
> It's because difficult problems are hard to solve.
Most software development does not involve difficult problems however - other than how to comprehend the stitching together or "complected-libraries-du-jour" via maximal indirection.
I know this is a meme (I guess about frontend web dev sometimes?), but I don't think I've ever seen it play out in real life.
Almost every program source code that I've read or worked on mostly consists of "data processing" and "control flow", with various kinds of abstractions that depend on the problem, programming language, etc.
Even for applications that seem straightforward, writing software well requires quite a bit of mental energy and focus/attention. Especially once you consider future maintainability and interfaces that other devs will use, testing and testability, documentation, readability, et al.
Denigrating programmers for using frameworks and libraries (the horror!) is just pointless and arrogant. Sure, most programmers aren't implementing novel algorithms from scratch with manual memory management. But that doesn't mean other problems can't be hard, it just means that the level of abstraction is higher and the programmer is free to use their mental resources to work and reason differently.
In a land free of constraints all problems are simple.
> So, should managers code, design, and in other ways contribute in some way to production code or design? Sure, I don't see any reason they can't. Just understand the boundaries and stay out of other people's way.
Has this person been a manager? The amount of time is takes to keep up to date enough to make a net positive contribution is non-trivial. Doing this on top of management responsibilities? Good luck.
The communication between a development team and the rest of the company is complicated. Navigating this requires both a skillset completely orthogonal to writing software and a lot of time.
It all depends on how large the team is and the scope of responsibility. I see, in practice, three types of manager roles.
The first is the team lead manager. This team has 3-5 people on it, and the tech lead codes small features and pairs with other developers, and has a coaching role. Their people management skills are relatively low weight, and their managers, whether senior managers or directors, are doing the heavy lifting on how to manage career progression and run a department, but they will be intimately involved with the progression of the team's goals.
The second is the multi-team or large team manager. This manager has 6-15 reports and does not code or codes sparingly at best. However, they are responsible for low level strategy and tactics.
The third is the barely-technical people manager. This person has over 20 reports, and is in a reporting capacity and people managing capacity and the technical leads are delegated to handle strategic and tactical capacity. The manager is responsible for more holistic thinking and supporting the tech leads, Or the organization is light on career development.
I have seen all three happen. The key to understanding your responsibilities as a manager is to understand the organizational expectations. When you ask as a manager if you should code, the real question is what are you trading for that?
Agreed. I'm moving towards a team lead role at some point. I've volunteered in three positions in orgs outside of work. Team lead is about where my skills and interests end.
Using the tools, trying the workflow, experiencing the friction, and just generally developing empathy for the day to day will make everyone better at their jobs. That includes job shadowing, which this is pretty much a form of. The major caveat is that you cant be part of critical path and its sometimes tricky to write even a great PR and expect honest feedback.
Author here. I agree with your caveat wholeheartedly. You've expressed it better than my "don't get in the way" comment. Don't take on critical path work is key. By all means fix things on the edges that are not time-critical or would not cause conflict during review.