Home‎ > ‎

Management Tips

  • Their job is not to write code
    Code is only a side-effect of a programmer's real function, which is to help the client or business discover what tools they really need. 

  • Don't lose your temper
    One of the most important lessons I learned was to keep your cool with a difficult employee who won't listen to your side. Even if they're being stubborn in the face of what you think is a logical argument, an escalation is going to make emotional barriers clamp down and prevent any constructive discussion from taking place. Drop the argument gently, and without snapping it off. Say something like: "Alright, let's table it for now. I'm going to check on a few things, but we should come back to it later this afternoon." Don't leave them hanging with the feeling that you're out to get them, because they'll begin preparing for a fight, which will distract them from work and make it harder to resolve the issue

  • Don't be a shoulder nazi
    You're walking by and catch someone surfing the web instead of working. Programmers need to take mental breaks frequently to avoid wasting time with over-analysis or over-pursuit of false solutions. The breaks are meant to induce creative pause, which is like stepping out of the trench you're digging to make sure you're not digging in the wrong direction. But if they feel like there's always someone staring over their shoulder, ready to scold them for browsing Reddit, they'll avoid taking those breaks and waste hours trapped in these mental quagmires

  • Allow teams to gel
    When you have a team of programmers working on the same project, give them enough freedom to find their own way of working together. Let them decide when to go on lunch break, encourage them to eat together, let them arrange their desks and workspaces their way, and give them some leeway when it comes to structuring their day and their workload. Gels form in liquids when the molecules are allowed to settle into an arrangement that links up with other molecules. Avoid stirring things up by constantly moving programmers to other teams, and keep them away from heat and pressure that can agitate the members with stress. (For more, see chapter 18 in Peopleware by DeMarco & Lister)

  • Pressure in moderation
    Most teams can perform miracles under pressure, but this "afterburner" effect can damage a team if sustained for too long. Apple routinely pushes its engineers to the edge in order to create great things, but after the product ships they're given a vacation and lots of time to cool off. One of the most tragic things I've seen happen to an engineer is to be pushed to the edge, day after day, year after year with no breaks. This led to panic attacks, clinical depression, medication, and more than a month of disability leave. Use pressure in short, widely spaced bursts to avoid burn-out syndrome

  • Prioritization is a technical decision
    The order that work is done affects how the later stages are done. If you give executives the power to chose when a component or feature is implemented, then you deny to the programmer the ability to choose how its done

  • Know everything
    Even if you're not the manager-by-name, in the software world just knowing how things should work or where to find things out will make you manager-by-act, and perhaps later manager-by-promotion

  • Don't use programmers as your personal reference library
    To answer a question, avoid paging programmers and calling them into your office to tell you what the columns in a spreadsheet mean or remind you, for the fourth time, how the feature you asked for last month works. This may mean you need to hire a technical writer

  • Don't be blinded with Certifications
    It's more important that they know the problem well than know the tools well. Some people are good at passing certification exams but lousy at coming to see things your way, so they will deliver a brilliant implementation of the wrong solution

  • Specify the interface, not the guts
    Programmers are more productive when you let them design the internals of the program themselves, because they'll think about it more

  • Manage the case-tracking system for them
    Convert emails and sheets of scribbled requests into cases for your programmers, clean up and close resolved cases for them, do all of the follow-ups for them

  • Don't override their estimates
    Let the programmer doing the work come up with a time estimate and don't apply pressure on them to shorten it. You job will be to build a schedule out of these guesses, then revise the schedule constantly

  • The less they code, the more productive they are
    Code is a liability, so the less they write the more value you get. You need to make sure you're paying them to think, not to dig you deeper into a hole

  • Have a short style guide
    Settle on a naming convention that can be described in half a page. Everything else is trivial; a "curly-brackets policy" insults everyone's intelligence

  • Introduce new techniques one at a time
    If a programmer is using old fashioned techniques, introduce a new one by demonstrating how it improves their code. Wait until they've mastered it before introducing another

  • 9-to-5 is a serving suggestion
    Book appointments and meetings for them, stress that they need to be there on time and presentable. Otherwise the project schedule is more important than when they arrive to type-out the code. They will be thinking about the code whether they're on premises or not

  • Remove obstacles for them
    You need to maintain the code repository and the case tracking system, tackle problem-employees to the floor before they get to them, empty their wastebaskets, fix the door knob and replace the toilet paper