though it's worth mentioning that the greatest difficulties are never, ever technical, they're always about people and feelings, which can surprise a lot of new managers
I wholeheartedly agree, and would like to add that this surprises developers and individual contributors perhaps even more than it surprises managers.
Re:The Manager as Debugger
by enraged_camel on Saturday December 05, 2015 @03:00AM
(#10681248)
>>though it's worth mentioning that the greatest difficulties are never, ever technical, they're always about people and feelings, which can surprise a lot of new managers
It can also frustrate developer-turned-managers. Dealing with software is in some ways easy because, for the most part, software is predictable: you get the same output for a given input. If you open your browser console and do:
console.log("Hello")
The output is always "Hello".
But if you go to a human and say hello, depending on their mood and feelings at that moment, you can get wildly different reactions.
P.S. I oversimplified, of course. The same function can give different results based on state, data, etc. But the point is, software is rational whereas humans are not always thus.
All you need is a mood monad. That'll fix the pesky state problem.
This article outlines some great first things to look for, but something important is missing: sometimes, after trying everything, it turns out that your team just has some truly terrible, morale-sucking people on it, and they need to be fired before things will pick up. That's sort of the "file a compiler bug" option of last resort, but there really are a lot of toxic people like that out there, especially amongst programmers, and as a manager you'll need to be able to pick them out and deal with them. That's almost the most important part of your job.