Published on

Smart And Get Things Done - A Developer’s Notes

Authors

Contents

Overview

These are notes that I took for Joel Spolsky’s Smart and Gets Things Done. However, many of said notes take the perspective of an aspiring developer. In other words, much of the written advice reflects actions that a developer can take to get a position.

Introduction

  • Hiring is an elimination course
  • A lot of people have...
    • ... never heard of your company
    • ... don’t know what you’re hiring
    • ... live far from your offices
    • ... got the interview and bombed
    • ... had other offers
    • ... have imposter syndrome

Chapter 1 - Hitting The High Notes

  • The real goal is for software companies to convert capital into software that works
  • It’s worthwhile to hire good programmers.
    • it will show in the software → more people buy it → you can afford better programmers
    • Hire Brad Pitt and take the financial tank in exchange for the hype that will bring in people
  • Quality of work does not correlate with amount of time spent
  • Brooks’ Law, “Adding manpower to a late software project makes it later”
    • The more programmers, the more coordination
  • Software MUST be good (#2 doesn’t cut it). Thus, you NEED good programmers

Chapter 2 - Finding Great Developers

  • Great software developers often connection their way into a job
  • Great software developers are noticed early
    • SHOW that on Linkedin
  • Why programmers get fired
    • Shit
    • Company goes awry
    • Both
  • There do exist solid, competent programmers.
  • Majority of resumes are shitty, incompetent programmers
  • Three methods to finding developers
    • Climb mountains
    • Internships
    • Building a network
      • Find people that interact with your company websites
      • Go to tech conferences (company ones, open source ones, new tech ones)
    • General rule: Avoid general job board ads
  • Find programmers that code in their free-time
  • Ask your current developers and interns (NETWORK, NETWORK AND NETWORK)

Chapter 3 - A Field Guide To Developers

  • Find developers that aren’t absolute cunts (not ALWAYS needed though)
    • A sort of leniency in regards to this
  • Developers want something INTERESTING to work on
    • Show interest in company technologies
  • Developers look into the social values of a company
    • Show that you match or enjoy the values of a certain company?
    • An issue is in being fake.

Chapter 4 - Sorting Resumes

  • RESUMES ARE WEAK INDICATOR OF COMPETENCE.
  • Resumes are sometimes used to filter people out, not directly hire them
    • Tailoring resumes are important since they only help you get interviews
  • Criteria for sorting resumes
    • Passion: Clear signs that the applicant has a strong interest towards computers. This may include: programming experience that goes far back, early applications of coding
    • Extra Curricular Activities: Projects that you worked on for fun
    • New Technologies: Showing new and rising technologies (Solidity, Rust, Go)
  • In a cover letter, talk about the interest to work at a given company as much as you talk about yourself. It shows that:
    • The person isn’t applying to a fuck ton of jobs
    • Tells the company that you actually took your time with designing your application
  • People that can communicate code are a must
  • Looking for general smarts (GPA, other activities)
  • Diversity plays a factor in effective hires since they offer new perspectives on old problems
  • Specific technologies shouldn’t be considered when hiring people
    • The tech we use now will go obsolete in a few years
    • It’s not hard at all to learn new technologies
    • The one exception is a software lead or some kind of higher up

Chapter 5 - The Phone Screen

  • Phone screens are good at weeding out people that are only paper smart
  • Phone screens focus on the quality of what someone is saying
  • Things to look for during a phone call
    • Their a problem solver
    • They have a lot of passion
    • They care about what they did
      • Technology: They know their shit for what they put down (2 years of Py experience? Better SOUND like you have 2 years)
      • Politics: How did someone handle challenges of all kinds (team based, coding issues, logistics)
      • TLDR; They have DETAILS ON A LOT OF WHAT THEY DID
  • “The interview is as much a way for the candidate to decide if they want to work for us as it is a way for us to decide if we want to hire the candidate”
    • Assumes that the candidate specifically chose to apply for the company (instead of applying randomly)

Chapter 6 - The Guerrilla Guide To Interviewing

  • Figure out who the right programmers are for the job that you need to finish
    • Companies have different standards for what makes a “qualified” programmer
  • Companies should go on a basis of “hire” and “not hired”
  • Rejecting good candidate is FAR better then accepting a bad candidate
  • Look for candidates that are smart and get things done
  • What is smart:
    • No need to explain shit over and over again (flow)
  • Shitty interviewers
    • Blowhard:
      • Gives no chance for the candidate to speak.
      • Hires everyone cause they share the same views
    • The Quiz Show Host:
      • “Knows a fuck ton of shit that you can google in 15 seconds?” “HIRED”
  • Hire people that can learn shit FAST
  • An example process of an interviewer
    • Intro
      • Warm up the interview
      • The initial impression can fuck you up (don’t get pre-interview impressions)
    • Recent projects/experiences
      • Look for passion, good explanations and signs of leadership
    • Easy programmer question
      • Warm-up to weed out people that lied
    • Hard programmer question
      • A demonstration of “can they handle multiple abstractions at once?”
      • Programmers should be able to handle understanding programming down to low level languages
    • Are you satisfied?
      • The most nightmarish question in the hiring process is “there’s a bug in your code”
      • The test is to see if one can catch the bug
    • Questions?
  • Write hire/no hire a few MINUTES after the interview is done

Chapter 7 - Fixing Sub-optimal Teams

  • There are different ways that one can contribute to a team
  • Forms of management
    • Command and Control - Make people work cause of their fear for you. Pretty shitty ass idea by the way.
    • Econ 101 - Assuming that everyone wants to work for money, give people money incentives. An issue is that you condition devs to only write good code when money is on the line
    • Identity Management - Use a series of methods to make devs identify with the company and the goals of said company. Basically, creating a family.

The Joel Test

  • Do you use source control?
    • Using Git and Github
  • Can you make a build in one step?
    • Good teams have one script that builds and runs the project
  • Do you make daily builds?
    • Basically, check if builds work everyday
  • Do you have a bug database?
    • Organizing and managing bugs
    • Should include:
      • Complete steps to reproduce the bug
      • Expected behaviour
      • Observed (buggy) behaviour
      • Who it’s assigned to
      • Whether it has been fixed or not
  • Do you fix bugs before writing new code?
    • Prioritizing bug fixing over writing new code
  • Do you have an up-to-date schedule?
    • Avoids issues in logistics between departments (eg, business/PR)
  • Do you have a spec?
    • In other words... DOCUMENT EVERYTHING
  • Do programmers have quiet working conditions?
    • F O C U S
  • Do you use the best tools money can buy?
    • Good tech → Productive environment
  • Do you have testers?
    • 1 tester for every 2-3 programmers
  • Do new candidates write code during their interview?
    • New candidates MUST show aspects of applications before being hiring
  • Do you do hallway usability testing?
    • Hallway usability test - Get the first person that passes by a hallway to test what you wrote

Every “yes” is one point. This is rated out of a score of 12.

12/12 - Perfect | 11/12 - Tolerable | ≤10/12 - Kinda an issue

Discuss on Twitter • View on GitHub