h4ck3r+=boi v 2.0

  1. Search
  2. About
  3. Subscribe
  4. Archive
  5. Random

h4ck3r+=boi v 2.0

Newer
Older
  • How do you know if you have a good programmer?

    So there’s this question is management: “How do I know if this coder I have is any good?”. The answer is simple:
    1. Perform a 360 degree review. Get opinions on this guy from other developers, manager the programmer works with, etc etc.

    2. Now that you have that baseline of information, and have many opinions from technical peers / team members, sit down with the coder and watch him work. You could be detached, or you could actively pair with him on a part of the system you know something about.

      Now ask yourself the following questions:

      • How often does the coder google something, find a code snippet, and paste it directly into your codebase?

        Hint: this should not happen very often, with a good programmer

      • Do they write tests, or at the least documentation about his code?

        Hint: he should be doing both. Having said that, some parts are just hard to test, or involve legacy code (also hard to test). Bonus: ideally these tests should describe the business behavior of the system.

      • Does he make this look easy or does he make it look super complicated (“change this thing here, that thing over there, oh and gotta make sure I switch this thing”). Unless it’s a refactoring, ideally it should look easy.

        Hint: Having to change many things to get one smaller ticket done might be a symptom of your codebase, not that this guy sucks. The 360 degree review may reveal this to you.

      • How much care / attention to detail do they have? How much care do they exhibit?

      • How often do they ask for help to the rest of the team?

        Hint: this is tricky, because “asking a lot” could mean you have someone who’s not pulling their weight… or someone who asks questions because they know someone else on the team has the answer. That’s why the 360 degree review before this is important

      • Do they have time/space to concentrate, or does someone come by every 5 minutes to interrupt the programmer?

        Hint: High amounts of concentration are important for programming. The more they get interrupted, the less work they can do

      • If you ask a question of the programmer, does he answer “it’s much too complicated”, or does he go off and explain this highly technical thing for 5 minutes?

        Hint: You want the latter. And yes, those tears in your eyes after 5 minutes? Those are tears of boredom

    3. Notice things about the environment. How many hours per week / days per week is this person working?

      Hint: long hours and long days = your highly paid programmer taking longer to do things (and making more mistakes) then normal.

      Super hint: you want efficiency in your organization (especially for people who may be getting paid by the hour)

    4. Are you giving your entire team the time they need to do a quality job? Or is it one “can’t miss it” deadline after another? This is demoralizing, and could actually lead to your programmers getting worse

    5. Does the programmer take time during “work time” to take care of personal matters?

      Hint: maybe this is not because “he sucks”, but maybe that he’s been worked too hard for too long, and personal stuff can’t be pushed off any more. Again, see the answer for #3. Or maybe “work time” is unreasonable (conference calls at 9:00 PM on a Sunday night, for example) and not allowing time they need to get personal stuff done.

    Posted on March 7, 2011

  • staff

Field Notes Theme. Designed by Manasto Jones. Powered by Tumblr.