Here's Your Computer, Good Luck, Bye! Lessons Learned in Onboarding*
Have you ever joined a team where they just turned you loose on day one and expected you to come up to speed on your own? How did that feel?
In this presentation, we're going to look at onboarding from the perspective of a new hire. We'll go over what's worked and what hasn't worked for the teams I've been on. The specifics will be different for your teams, of course, but we'll discover some general principles together.
By the end of the talk, you'll be coming up with your own ideas you can apply to your team's onboarding process. By making a few simple changes, you can improve morale, boost productivity, and keep your fellow engineers around longer.
We’ll consider several different aspects of onboarding, including the following:
- “We don’t eat tuna at our desks here” – making tacit knowledge explicit
- “Who’ll be the first one to go home?” – how team behavior can silently set expectations
- “Um, let’s just copy and paste my first-day email” – building a reusable outline together
- “Every new hire has the same skill set, right?” – customizing your plan for each new team member
- “10-4, good buddy!” – the new hire’s success is your success
- “What is your quest?” – engage your hire in designing their own goals
- “Well, that’s 90 days, good luck, bye!” – psst, you can keep teaching after onboarding is done
I've spoken at several conferences, including Open Source Bridge, OSCON, and Pacific Northwest Software Quality Conference
Ian Dees was first bitten by the programming bug in 1986 on a Timex Sinclair 1000, and has been having a blast in his software apprenticeship ever since. By day, Ian slings code, tests, and puns at New Relic. By night, he dons a cape and keeps watch over the city as Sidekick Man. In his (heh) “spare time,” he converts espresso into programming books, including the team effort Seven More Languages in Seven Weeks.
- Title: Running Just the Test Cases You Need
- Track: Practice
- Room: B301
- Time: 1:30 – 2:15pm
When you’re writing software, fast feedback is key. The less you have to wait for your tests to run, the sooner you’ll know whether or not your code is correct.
Ruby’s two main test frameworks (minitest and RSpec) support several different techniques for testing only what you need for what you’re currently working on, and nothing more. In this talk, we’ll go through several of these practices for both frameworks, each more automated and awesome than the last.
- Speakers: Ian Dees