Developers, from scratch (Warecraft 2019 - Austin, TX)

Df8dadf45535cb8501d04a99b7f03f56?s=47 Mike McNeil
February 21, 2019

Developers, from scratch (Warecraft 2019 - Austin, TX)

The latest iteration of the talk, for Warecraft 2019 in Austin, TX (https://www.warecraft.io)

> Why hire a developer when you can hire a barista and teach them to code? Since 2012, I’ve hired and worked closely with many professional developers... but I’ve trained almost as many first-time programmers myself. It’s going surprisingly well. We’re building higher quality software at a much faster pace than ever before. In this talk, I’ll show you how we did it.

> You’ll see how long it takes (at least for us) before “from scratch” developers can be effective on real-world projects, and I’ll share some tips on how to empower them to be productive even while they are still very much an apprentice. Finally, we’ll take a look at the numbers. Home-grown training takes considerable effort, and it isn’t for everyone. But hiring even a small team of professional, full-stack software engineers is an expensive and time-consuming proposition— and it doesn’t necessarily lead to better results. Depending on your financials and timeline, certifying some of your own talent could be the right decision for your business, your products, and your users.

P.S. This talk at Warecraft was not recorded, but the video from a variation I presented a few months earlier in Santiago is available on YouTube: https://m.youtube.com/watch?v=M9kH4j74H70

Df8dadf45535cb8501d04a99b7f03f56?s=128

Mike McNeil

February 21, 2019
Tweet

Transcript

  1. Developers, from scratch

  2. Why hire a developer when you can hire a barista

    and teach them how to code?
  3. Why not? ≤ $3,500 per month $7,000 - $11,000 per

    month
  4. None
  5. None
  6. Why hire?

  7. because you can't do it all by yourself not fast

    enough, anyway
  8. None
  9. 1099 contractor Studio W2 employee

  10. reasons to hire

  11. None
  12. Conventional wisdom

  13. Business needs:

  14. some coding experience lots of coding experience

  15. entry-level developer $$ lead / architect $$$

  16. little to no coding experience apprentice (barista)

  17. Apprentices capture more and more business value as they gain

    skills specific to your business.
  18. Conventional wisdom

  19. Apprentices can enjoy and learn from tasks that more experienced

    developers might avoid.
  20. Apprentices don't have "bad" coding habits. (Yet.)

  21. Conventional wisdom

  22. What about velocity?

  23. Assigning the wrong user stories to apprentices can slow down

    the whole team.
  24. Fortunately, there's a lot of other important work to do.

  25. Semi-technical setup and configuration tasks

  26. Online account setup

  27. Time tracking (playing "timekeeper")

  28. First tier customer support (watching the "redphone")

  29. Reconnaissance (competitor research, UI research, etc.)

  30. Vendor / pricing research (and communication, when necessary)

  31. Hallway usability tests (and proactive human factors testing)

  32. Organizing the agile board

  33. Markup & stylesheets (HTML and CSS, email templates, PDF templates)

  34. Nitpicky UX adjustments

  35. Small things you might never get around to doing otherwise

  36. Custom forms, validations, modals

  37. Wireframes

  38. On-the-fly customer success hacks

  39. Open source support & triage (GitHub, Gitter, StackOverflow, social media)

  40. Looking up stuff from the database

  41. 3rd party API integrations

  42. Quality assurance (QA)

  43. The Company Managing apprentices (These guidelines work well for my

    team -- but every team is a little different.)
  44. The Company - Celebrate when apprentices catch bugs and gaps

    in requirements, even if they seem insignificant. - Decide on a process that apprentices will follow when they run out of stuff to do, and encourage active communication any time they're unsure what to work on next - You might be able to afford to send apprentices to planning meetings that would be too expensive for other developers Managing apprentices
  45. The Company - Set clear expectations about code ownership (which

    files apprentices can change without doing a pull request) - Set clear expectations about when it is appropriate to interrupt senior developers with work questions (e.g. only in the morning before or during the standup meeting) - Empower senior developers to delegate tasks to apprentices Managing apprentices
  46. The Company Managing apprentices - Never assign a business-critical task

    unless you're 99% sure you'll get to say "Nice work!" afterward. - Set an informal time window for "graduation" (e.g. 2 years) - Don't skimp on ahead-of-time training hours-- as long as those skills are sufficiently valuable to your team to be worth your $$$ and time. And only after the apprentice has already been initially exposed to the concepts you're showing them, in practice.
  47. Training apprentices

  48. Kinds of training - Ad hoc (scattered, on-the-job training when

    you realize you assigned a task that is too hard) - "I'll set this up while you watch" (setting up your dev environment) - Drills (contrived exercises or low priority tasks) - Theory (interactive lecture / live coding)
  49. Drills

  50. Drills

  51. Things worth teaching ahead of time - Essential tools &

    expectations (editor, what is the filesystem really?, terminal, GitHub app, node, npm install sails, Heroku, customer service, communication etiquette) - Thinking like an engineer (incognito mode and Chrome profiles, screenshot hotkeys, giphy, Chrome dev tools, the REPL, the terminal, the importance of thoroughness, how to think about edge cases, collaboration) - The DOM (HTML+CSS, and how the browser works) - Logic (&&, ||, v-if, v-else, v-for, etc) - HTTP and the internet (how to read API docs, how to use Postman, <ajax-form>, loading spinners, cloud errors vs. client-side form errors)
  52. Essential tools & expectations

  53. Thinking like an engineer

  54. None
  55. None
  56. None
  57. The DOM

  58. The DOM

  59. Logic

  60. Logic

  61. Logic

  62. HTTP and the internet

  63. HTTP and the internet

  64. So... does it work? - Yes. But start with just

    one apprentice - And try to only train one apprentice at a time (for us, that means staggering hires by at least 4 weeks, even if your backlog or budget might make it feel like you have to hire more quickly)
  65. PERCEIVED VELOCITY QUALITY x WITH APPRENTICES x WITH SENIOR DEVS

  66. So... does it work? - Since going "all in" with

    this model two years ago, hiring first-time programmers as apprentices, it took a little while to warm back up. - But today, we ship most features just as fast as we did with a larger and more experienced traditional team 5 years ago.
  67. Questions? @mikermcneil