Review: Smart and Gets Things Done

Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent
Smart and Gets Things Done: Joel Spolsky’s Concise Guide to Finding the Best Technical Talent by Joel Spolsky
My rating: 4 of 5 stars

This book proposed that if you have the Best Working Conditions => you get the Best Programmers => to develop the Best Software => which results in Profit!

The preface for this is the the quality of the work and the amount of time spent are simply uncorrelated. Productivity is 5 to 1 or 10 to 1 between programmers. You can’t afford to be number two, or to have a “good enough” product. It has to be remarkably good, by which I mean so good that people remark about it. Having really, really, really talented software developers is your only hope for remarkableness.

Candidate sourcing

The great software developers, indeed, the best people in every field, are quite simply never on the market. The average great software developer will apply for, total, maybe, four jobs in their entire career. Whereas bad people are on the market quite a lot.

How to find people who are not on the market:

1. Go to the mountain

  • What conferences do they go to? Top end conferences or up and coming technologies
  • Where do they live?
  • What organizations do they belong to?
  • Which websites do they read?
  • Avoid advertising on general-purpose, large job boards as the bad people who are all over the market will apply and swamp you.

2. Internships

  • Students are lazy, with lots of options so can roll out of uni into a job. For the good ones try to attract them a year or two early – they might need some training but it is beneficial for both sides. You will likely need to have a contact at the Uni to find the best students.
  • If they are great make them a good offer for after graduation

3. Build your own community

  • Referalls
    • Tend to be from former companies tent do be from the same company which can be risky
    • Nobody wants to persuade their friends to apply for a job at their company only to get rejected
    • If you pay too much for referrals then they will coach people through the interview process

Workspace

  • Private offices make programmers more productive and programmers prefer it
  • Putting on headphones with music to drown out the ambient noise reduces the ability of programmers to have useful insights
  • Office location
  • Does the office look exciting?
  • Good chairs don’t cost that much more over their lifetime and if you take the cost per week it is cheaper than most other office facilities
  • People want to work with good, cheerful and happy people – Smart, and Gets Things Done and not a jerk
  • Managers can advise but they must be extremely careful to avoid having their “advice” interpreted as a command

Thing which annoy programmers

  • being told to use a certain programming language
  • people being promoted because of their ability to network rather than being promoted strictly on merit
  • being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it.

People want to work on something cool, exciting new languages attract people.  Young programmers, especially, are attracted to ideological companies

  • open source or the free software movement
  • social causes
  • benefiting society

Developers don’t really care about money unless you’re screwing up on the other things – it means people aren’t really loving their job. If potential new hires just won’t back down on their demands for outlandish salaries, you’re probably dealing with a case of people who are thinking, “Well, if it’s going to have to suck to go to work, at least I should be getting paid well.”. That doesn’t mean you can underpay people, because they do care about justice – you do have to pay competitively, as long as the salaries are basically fair they will be surprisingly low on their list of considerations. Offering high salaries is a surprisingly ineffective tool in overcoming problems

Resumes filtering

  • Be selective about how we advertise jobs to limit the amount of poor CVs
  • Use a strictly objective system of reviewing and sorting them, this is not a filtering criteria it is just to sort a big pile of CVs to find candidates who are most likely to be suitable so they get interviewed first
  • Passion
    • Jobs with computers or experience programming going back to a very early age
    • People who love programming often work on their own programming projects (or contribute to an open source project) in their spare time.
    • Sometimes certain programming languages or technologies indicate evidence of someone who loves to explore new technologies
  • Pickiness
    • Specific covering letter to the company, a custom cover letter is a sign that if we do make this candidate an offer they’re likely to accept it
    • programmers who can communicate their ideas clearly – so neat, well structured and gramatically correct CVs
  • Brains
    • Math camp, programming competitons etc
  • Selectivity
    • Have they been through a rigorous review process before either for Uni or another company
  • Hard-core
    • Some development work is just harder than others, if they have the harder work then they stand out.
  • Diversity
    • Trying to bring new ideas into the team – to break people out of group-think and their own echo chamber
  • Great developers are likely to have enough options of places to work that any extra hoops will put them off bothering to apply.
  • Any technology you know right now might be out of date in a year, you are looking for people who pick things up quickly and can learn new things – so don’t filter CVs on key words.

Phone Interview

  • Get the candidate to describe their career history and basically tell me about themselves. Looking for:
  • Technology: How did they do things. What was their role. CV validation
  • Politics: How the candidate handles challenges. Looking for people who got things done, even in the face of opposition. I’m looking for people who challenged the status quo, who overcame objections, and who made things happen. Whose idea was it? Who convinced whom? Who did what? Did it work out? Why not?
  • Get the candidate to solve a technical problem. This should take something the candidate is familiar with but are unlikely to have implemented themselves. The aim is to look at their approach rather than getting them to speak code over the phone.
  • Get the candidate to ask questions about the company. This shows if they have done any research and what they are interested in.

Interviewing

  • 6 interviewers, at least 5 peers not managers
  • If two people would reject the candidate end the interview at that point
  • Don’t interview multiple people at once
  • There are three catorgories
    • Nos
      • “Hire, but not for my team.” is a no hire
      • “I’m a little concerned about” is a no hire
      • “Perhaps” is a no hire
      • It is much much better to reject a good candidate than hire a bad one
    • Maybes – never hire maybes
    • Superstars
  • Is the candidate Smart will the candidate get things done?
  • Bad interviwers
    • Interviewers who just talk the entire time
    • People who are just looking for trivia e.g. “What’s the difference between varchar and varchar2 in Oracle 8i?”, smart does not mean knows trivia, aptitude is more important. Any skill set will be out of date in a couple of years
  • Good practice
    • Know as little as you can about the candidate in advance so it does not bias your opinion.
    • don’t listen to recruiters opinions, don’t ask around about the person before you interview them, never talk to the other interviewers about the candidate until you’ve both made your decisions independently. This provides the least amount of bias for or against the candidate.
  • Good candidates
    • are passionate, they might be passionate in favor or against but passion is key. Bad candidates just don’t care.
    • can explain what they have done in a way a normal
    • look for signs of leadership, how have they pushed forward to get things done
    • write code and discuss it
      • Fundamentals – if they don’t know these then they won’t get very far
        • pointers
        • recursion
        • data structures
      • ask them to find bugs in their code, even in the unlikely event there are none, to see how they approach it
      • Even if they are a bad candidate, you want them to like your company and go away with a positive impression.
      • Don’t ask questions such as are they married, have kids etc even in a conversational way as this adds nothing and the candidate might feel this has been used against them which is likely illegal.
      • “Back of the envelope questions” e.g. How many piano tuners are there etc are a good way to provoke a conversation.
      • Do feedback instantly before you forget about the candidate
      • If 4 or 5 people think this person is worth hiring then you likely won’t go wrong
      • If you do have to say no to someone, do it quickly and respectfully
        Great people are much, much more valuable than average people – three to ten times as productive, costing 20% or 30% more

Teams

  • Why don’t they work?
    • performance measurements and incentives – devastatingly ineffective
  • Remove the parts which are not working.
    • Anonymous peer ranking with the options:
      • Great developer
      • Needs specific improvements
      • Hopeless
        • Firing poor performers can increase moral because poor performers are taking time away from the good performers. If you can’t fire them move under-performers to a place where they can’t cause any impact.
  • Putting in things which do work
  • Three approaches to leadership
    • The Command and Control Method
      • Tell people what to do and tell them off if they don’t do it
      • Disadvantages for developers
        • Smart people rebel against doing what they are told without good reasoning
        • Micromanaging would require a huge amount of managers to micromanage everything. That or you hit and run not seeing the consequences of your decisions.
        • The management have the least knowledge so are ill placed to make decisions.
    • The Econ 101 Method
      • Give them financial rewards and punishments to create incentives, aka replaces intrinsic motivation with extrinsic motivation.
      • When you stop paying the bonus, or when they decide they don’t care that much about the money, they no longer think that they care, even though they might have cared before you started giving them a bonus for it.
      • They’ll find some way to optimize for the specific thing you’re paying them, without actually achieving the thing you really want.
      • You’re encouraging developers to game the system.
      • You can’t abdicate your responsibility to train your people by bribing them.
    • The Identity Method
      • Make people identify with the goals you’re trying to achieve
      • The Identity Method is a way to create intrinsic motivation.
      • Make a point of of eating lunch with my coworkers. It’s hard to understate what a big impact this has on making the company feel like a family, in the good way.
      • by sharing information people will do the right thing

View all my reviews

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.