DEVELOPERS, FROM SCRATCH
StarsConf 2018, Santiago, Chile
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.
Why hire a
when you can hire a barista
and teach them how to code?
because you can't
do it all by yourself
not fast enough, anyway
reasons to hire
some coding experience lots of coding experience
lead / architect
little to no coding experience
Apprentices capture more and more
business value as they gain skills
speciﬁc to your business.
Apprentices can enjoy and learn from tasks that
more experienced developers might avoid.
Apprentices don't have bad coding
What about velocity?
Assigning the wrong user stories to
apprentices can slow down the
Fortunately, there's a lot of other important work to do.
Semi-technical setup and
Online account setup
First tier customer support
(watching the "redphone")
(competitor research, UI research, etc.)
Vendor / pricing research
(and communication, when necessary)
Hallway usability tests
(and proactive human factors testing)
Organizing the agile board
Markup & stylesheets
(HTML and CSS, email templates, PDF templates)
Nitpicky UX adjustments
Small things you might never get
around to doing otherwise
Custom forms, validations, modals
On-the-ﬂy customer success hacks
Open source support & triage
(GitHub, Gitter, StackOverﬂow, social media)
Looking up stuff from the database
3rd party API integrations
Quality assurance (QA)
(These guidelines work well for my team -- but every team is a little different.)
- Celebrate when apprentices catch bugs and gaps in
requirements, even if they seem insigniﬁcant.
- 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
- Set clear expectations about code ownership (which ﬁles
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
- 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 sufﬁciently valuable to your team to be
worth your $$$ and time.
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" (mostly replaced by video tutorials)
- Drills (contrived exercises or low priority tasks)
- Theory (interactive lecture / live coding)
Things worth teaching ahead of time
- Essential tools & expectations (editor, what is the ﬁlesystem really?,
terminal, GitHub app, node, npm install sails, Heroku, customer service, communication etiquette)
- Thinking like an engineer (incognito mode and Chrome proﬁles, 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, ,
loading spinners, cloud errors vs. client-side form errors)
Essential tools & expectations
Thinking like an engineer
HTTP and the internet
HTTP and the internet
So does it work?
- Yes. But start with just one apprentice
- Try to only train one apprentice at a time (for us, that
means staggering hires by at least 4 weeks)
Background: Since going "all in" with this model last year, hiring ﬁrst-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.