top | item 19769790

(no title)

eight_ender | 6 years ago

I wrote code like a madman and then went into management. I like management, but I understand what the author of this article was getting at.

I had an identity crisis early on doing management. I liked to tell people what to do, because I had a big map in my head of where things should go. Because of this developers sort of organically gravitated to me for guidance even before I had the official job. However, I also liked to write a lot of code.

Once I was promoted to management I quickly realized just how much "not coding" that job requires. I struggled with not coding as much. I struggled with wanting to micro manage my staff. I struggled with wanting to write their code for them. I had juniors on my team and I wanted to snatch the keyboard from them and write their code for them.

The defining moment for me was one day, while watching one of my developers deploy something magnificent, that I realized I don't necessarily like to "build things", I like to "see things built". I like to see people succeed. I like to see a scribble on a napkin become a tangible piece of software. Code was a means to an end for me.

I won't lie and say I don't miss coding full time. I still get right in there when I can, but I step aside when I know my management duties are going to let the team down. One thing I don't feel is guilty about not coding as much anymore.

discuss

order

ramraj07|6 years ago

So how DO you deal with people under you writing code under you that just boils your blood? Especially if you instinctually see that their contributions are always more counterproductive than not, but everyone else (including their people manager) thinks they're alright?

jklm|6 years ago

There are a couple ways you can look at this situation:

- There generally isn’t an ‘optimal’ solution, but there are a lot of solutions with tradeoffs.

- Everyone has their strengths and weaknesses, and gravitate towards different molds.

- People aren’t born perfect, but what they can do is grow. How can you help them do that?

orthoxerox|6 years ago

I am a manager as well, and I just recall that there are only so many hours in a day and I couldn't have written all of that code myself. But that's for suboptimal code, not atrocious code.

I haven't dealt with people under me who write truly abysmal code so far, mostly because I am a picky hirer, but that subpar code that my people have written is my fault, because it's my responsibility to make them better programmers.

pbh101|6 years ago

Inspect your own feelings of why you feel your approach/solution is better. If you haven’t done it before, this can be a lot of work.

Get to the point where you can convey the underlying reasons for them: why is it important to you? What’s going to be worse or slower with their solution? What future problems is your solution avoiding? How can they identify similar situations and apply the same concept next time?

It is good that you see these things instinctually as you say but if others don’t (including the coder in question) then you can make improvements by conveying this to them. And that is frequently more than half the battle in getting improvements operationalized: getting others to adopt and push and spread your good ideas as their own.

In a healthy org, these developers should be open and eager to listen, learn from new ideas, and adopt improved methods or outlooks, especially from a tech lead (or equivalent), who in turn should be able to update his/her own methods/outlooks when similarly presented with improvements.

eight_ender|6 years ago

Performance and quality is something you can mentor. I work my ass off to make sure my devs have a plan to get better at their craft and learn from others. If they're not doing well I tell them immediately before it grows into a shitshow.

Bad values is a slightly difference conversation. If the dev has a bad attitude, refuses to improve, lazy, etc then you can only coach that so far before it's time for termination. It sounds harsh but a good managers job isn't just filling seats. You need to make sure the people on your team force multiply each other, and that your best devs are happy enough to mentor the up and comers. Low values people spoil all of that and need to go, even if they're high performers.

jupp0r|6 years ago

Try to mentor them. If all the code you see is like that you’re in the wrong spot.