Hacker News Reader

Comment by swader999 | Hacker News Reader

Anytime I manage I refuse to track dev productivity individually. Its all about how much functionality (complexity points) gets net accepted in prod per unit of time from the whole team.

If you measure at the team level you get collaboration and much better solutions. It's a friendlier and more rewarding way to work with little turnover. It encourages product, dev and QA to work together and solve user problems in economical ways, not just throw solutions over the fence to the next stage.

And yeah sure I know if there's someone not performing up to their pay rate, you don't need numbers for that, you need to be involved and looking at their code.

View on HN

> looking at their code.

I can't imagine many development managers do that. And even if they did, I'm not convinced that many would make a good assessment that way.

Most of the managers I've had over my career have been poor coders. I'd hate to have them judging me by their conception of what good code is.

EDIT: I guess many people have had better managers than I've had. So my "most" and "many" may be off base.

Counting myself as fortunate that I can git-blame and find my managers' (admittedly often old commit) name in the code base :-).

Fair point!

Well do you think someone managing development shouldn't know how to code? How would they hire? I've never worked on teams where dev is larger than six and I've always coded though. Bigger than six is automatically create another team in my books.

Sadly, it's very common. They typically ask one of the more senior engineers to assist with hiring. Earlier in my career, the managers knew how to code. Last 10 years... not so much.

How many managers have you had? Seems like an odd generalization.

> I can't imagine many development managers do that.

Wow, just a reminder that everyone's experience is unique and can't always be generalized. My first thought was "I can't imagine a development manager not doing that."

Seriously, I feel for you. Essentially all of the engineering managers I've had at one point or another have been coders. Some were well, well out of practice by the time they were my manager, and as I moved up in my career my managers were less interested in the details of my code, but I could always talk with them about highly technical concepts. I really feel bad for folks who think their engineering managers can't judge good code. And as someone who's also been an eng manager, I can't imagine managing devs without having an understanding of good code.

I admit it; my experience is my own and I'm happy to find out that other people have had better management than I have.

And you're right that it's absurd to try to judge developers without an understanding of good code. I just figured the world is absurd.

When I'm managing a dev team, I enjoy reviewing my team's code at least 3/5 of days every week. Otherwise how can I give them sincere feedback and ensure we aren't doing weird stuff?

This is the best way I've found to manage a high performing engineering team.

You do need to be extremely attuned to the development process, and like you said, read everyone's code. But it is absolutely worth the effort.

Reply on news.ycombinator.com