Managing Developers How not to suck.docx

1、Managing Developers How not to suckManaging Developers How not to suckContentsYour Job is NOT Telling People What ToDo 1Dealing with the TeamGenius 2Dont forget what its like to be10 5The word you are looking for is“People” 6Status Reports Suck and Everybody HatesThem 7All Developers Shall Have Good

2、Equipment 10Your Job is NOT Telling People What ToDowith 11 commentsThis post is part of my series on Managing Developers How not to suckIve had many people tell me they would like to be a manager. The first question I ask is why? The absolute worst answer is any variant of Because I want to tell pe

3、ople what to do. They might answer So I can have direct influence over the team., or So I can provide direct leadership.Any thing remotely like because I want to tell people what to do is the wrong answer. These people are not ready to be managers they are far from ready. Organizations that make peo

4、ple like this managers are making a huge mistake.Your job as a manager is to enable your team. You are paying them to think, solve problems and get stuff done on time. Let them do it. Your job is not telling people what to do.Enabling your team means setting them up for success, making sure they do

5、their best work with good continuity over time, not just at crunch time, or when it counts. If you are thinking, “Yes! A managers job is to make people do their best work.” Then you are not understanding this advice.Merriam Webster defines enable like this: to render able as in enable a person to gi

6、ve power, strength, or competency to to make possible, practical, or easy to give the opportunity to The term make is defined like this: to cause to act in a certain way. To compel Making people do things is telling them what to do. Enabling them is an entirely different thing. There are lots of way

7、s to do this. I cover some of them in this series of posts. Here are a few in no particular order Dont forget what its like to be an individual contributor (post) All developers shall have good equipment (post) Dont treat people fungibly (post) Know when to shut up and just listen. Depending on Hero

8、ics is “Epic Fail” Praise in public, criticize in private Make sure people know what to accomplish, by when and what done looks like Be your teams champion, not their defender This may not sound too hard. But let me make it harder you cant do this sometimes, like just at crunch time, or just when th

9、e bug count is high, or when the requirements change. Your job is to help your people deliver their best work all the time. It sounds impossible, but the closer you come, the better it is for everyone.Now, this doesnt mean you can avoid making decisions or you cannot correct mistakes. These are both

10、 part of a managers job and sometimes people will not like some of your decisions, or being corrected. Thats ok. There is a big difference between reluctantly doing this when necessary (and with good reason and explanation) and being a dictator.Here is what Id like you to remember. If you feel your

11、role is to help your team, you are on the right track. If you feel a visceral need to order people about, then you will suck as a manager not matter how good you are at everything else.-Foredecker Dealing with the TeamGeniuswith 3 commentsThis post is part of my series on Managing Developers How not

12、 to suckWeve all worked them at one time or another the loud, opinioned, authoritative, hardworking, smart capable, type A developer the one that always seems to have an opinion on everything. The guy whos code review feedback is usually something like that code doesnt look like my code. They dude w

13、ho wrote the super-complex-only-he-can-understand-it code your entire product depends on. You know, the code only he can touch. The code that has no comments because its all self documenting. He tells you he doesnt have time to write comments anyway(1). They guy that gets loud and upset at the drop

14、of a hat. The guy that has to use the most complex (beautiful he says) algorithm for even the most mundane tasks. They guy that writes his own debugger because existing one just isnt good enough. The guy that wrote his own domain specific language (using regular expressions) because there was no oth

15、er way to solve the problem. They guy that uses LINQ expressions for everything because they are fluent. They guy that gets impatient when other people cant instantly understand his code. This is the guy that to fix a bug, works straight through a weekend and completely re-writes a big chunk of code

16、 because the code needed to be re-written anyway. The guy that insists he is the only one that sees the big picutre. This is the guy that always expects an A+ performance review every single time.You know the team genius.The only problem is that he is probably isnt really a genius. Yes, he is probab

17、ly pretty smart and he certainly is loud. Yes, the team depends on him, and yes he gets a lot of work done, and he works a lot of hours. But most likely he is really quite disruptive and in reality not the team genius but the team prima donna. Thats a great phrase. It means:a person who finds it dif

18、ficult to work under direction or as part of a team. One who is impatient of restraint or criticism.Let me ask you two questions about your team genius.1. How much time do you and the rest of your team spend feeding the genius. 1. What would your team look like if he quit tomorrow? In my experience

19、team geniuses soak up an awful lot of other peoples time. Ive spent way too much time cajoling, soothing, arguing with, and otherwise dealing with the team genius. Think about it this way compared to other people on your team how much time do you spend dealing with the genius compared to others on y

20、our team? How much time do other team members spend dealing with the genius? If your experience is anything like mine, it is disproportionally much higher.How much does the genius annoy, frustrate or simply piss off others on your team or people on another team? How often have you had to sooth anoth

21、er team member and make excuses for the genius? Do others on your team avoid working with him? Are they careful what they say to him in meetings? How about yourself? Are you happy to see the genius in your doorway? Or do you cringe when he walks in your door?Think about his code is it really genius

22、code? Or is it merely over designed and over implemented? Did that problem really require the use of C# expression trees? Or a hand rolled recursive decent parser? Did he really have to write his own debugger? Did he really have to write his own custom template based XML de-serialize? Really? Ill be

23、t if you went back and looked at his design work his over design wasnt justified at all. I suspect that it just wasnt worth arguing with him about it.Think about the second question what would your team look like if the genius quit tomorrow? Your first reaction is probably oh crap. But think about i

24、t some more would the quiet guy who is often overshadowed by the genius be able to shine? Would the frustration and friction levels on your team go down dramatically? Could you replace him with that smart kid form the test team who really wants to be a developer? Would you have more time to spend wi

25、th your other team members even after replacing him?If your experience is like mine, then the genius is likely not as nearly as beneficial as you or others may think. Its likely that he is really quite disruptive and the technical value he brings to the team not really that super-awesome.As manager,

26、 your job is to help the genius maximize his benefit to the team while minimizing or eliminating his disruptive behavior. You must help him understand that the costs of having him on the team are only a little lower than the benefit he brings to the team. Help him see how much time he costs everyone

27、 else. For example, help him see that the costs of re writing that big pile of code costs the test team two weeks of regression testing, and that somebody needs to re-write all the unit test.This isnt easy. The team genius doesnt take constructive criticism well, is volatile, stubborn and will almos

28、t never agree with you. But you must try anyway because there is a chance you can help the team genius become a solid team member. Thats a great outcome.Even if this doesnt work, your efforts will benefit the rest of your team. They will see you as helping them by working help the genius be less dis

29、ruptive. This can do wonders for team moral and the teams trust in you.The really hard part comes if the genius simply doesnt come around. If this happens, you need to get the genius off the team they are just not worth it. Really they arent worth it. Disruptive people are simply death to an otherwi

30、se good team.After all is said and done, you may be stuck with your genius. Perhaps your management chain likes him. In that case you must simply work to minimize his disruptiveness and maximize his value.-ForedeckerDont forget what its like to be10with 3 commentsThis post is part of my series on Ma

31、naging Developers How not to suckRemember what it was like when you were 10 years old? I do. In the summers our mothers kicked us out of the house in the morning and didnt expect us home until dinner time, or later. We spent all day riding around on our single speed bikes causing minor trouble. We u

32、sually had lunch or dinner at the friends house we were closest too when hungry; our mothers treated us like a pack of wolves. We found cool junk, built forts, had dirt clod fights; shot each other with BB guns, swam in the pond, fell out of trees, blew stuff up, shot turtles, played in the mud, and got chased out of vacant lots by old men. It was a blast.I often ask people Do you remember what it was like to be 10?” By far the most common