> I'd say a developer is doing a good job when you, as a manager, are not having him come in at all hours to fix problems with his stuff.
That's also what a developer who ships nothing, ever, looks like. There are quite a few of those. A developer who gets the most done and tackles the hardest work, on the most important and frequently used tools, integrating with the most problematic 3rd party systems and has specialist knowledge is likely to be called on a lot.
Ultimately you can't make any judgement of the developer without detailed understanding of the specifics of the work. This applies to every possible developer productivity metric which is why its so damned hard.
You can manage them, you just can't judge their work. I'm a team lead and I'm lucky in that my direct supervisor was a programmer for a long time, still runs a SaaS in his spare time, etc, so he gets it. But he has colleagues who are CPAs, management consultants, etc before they were managing their current dev teams.
They rely a lot more on their technical leads to tell them how the other devs are doing at a technical level. They're perfectly capable of managing their professional development without having an in-depth knowledge of enterprise architecture or C#.
> They rely a lot more on their technical leads to tell them how the other devs are doing at a technical level.
So the leads are de facto managers in that they're assisting the manager in managing the other developers. I think this can work, but I don't think it contradicts what I said. It just means the leads wind up doing some managing even though that's not what their titles say.
I've meet one programming manager with 0 programming experience (but he was a Mech Engr). His team loved him, they got real work done, he prioritized things for them effectively, and he helped insulate them from the b.s.
So, while it's rare there are certainly managers out there who can.
If you can't accurately assess the productivity of the developers by monitoring their output, you will default to metrics you can understand - usually that means monitoring the time spent in their seat.
From what I've seen coding managers seem much more open to remote work than non-coding managers.
well remote working does make checking on the remote worker harder so more difficult to know what they are actually doing, but knowing if their tasks are difficult or similar things should be achievable just over chat.
I have noticed that people who review your code have no issue with remote work, and can easily assess your state of mind, personality traits without much more help like video and visits. It makes it harder for the people not reviewing your work.
Sadly you are right. In person, an unskilled manager can tell if it looks like you are working hard, even if they don't understand what you are doing. Remotely, they can't even tell that, and are effectively blind.
At the company I work for we've had a few developers who would've done a lot less damage if they hadn't written any code rather than the code they did write, which we then spent months on to detangle afterwards.
Those are bad enough - but I have met one developer that was technically competent (I would definitely pass his code in a review) except that he didn't care about how anything else worked in the company or even the logical constraints of the real world data (like the concept of brand was useless because different companies providing data treated it so differently) so what he spent a month working on at the end was nice code that did what it was ostensibly supposed to do but that could not be integrated with anything else, as a result of which if that code was integrated it meant the destruction of several years worth of work.
Was he a good developer? Looking at his github repo I would have said yes... talking to him I said yes... if I had examined what he built without any context I would have said yes, but really he was something of a company destroyer that I would not ever recommend to anyone else.
Yes, exactly. There are developers who can create code that works, that looks fine, that works for a certain context; however that context is completely separate from reality.
Conceptual damage to an application is a lot harder to fix than the damage of 'ugly' code. You spend years fully recovering from fundamental flaws in the concepts of your application.
This rings true. There are those who tackle the low level plumbing, core problems and take them on with the rest of the team. Then there are those who take on surface-deep issues. Intentions and subject matters.
That's also what a developer who ships nothing, ever, looks like. There are quite a few of those. A developer who gets the most done and tackles the hardest work, on the most important and frequently used tools, integrating with the most problematic 3rd party systems and has specialist knowledge is likely to be called on a lot.
Ultimately you can't make any judgement of the developer without detailed understanding of the specifics of the work. This applies to every possible developer productivity metric which is why its so damned hard.