Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Onboarding The Ruby Way
- 8. @LMcNish14 Layne McNish Technical Support Have you tried turning it off and back on again?
- 11. @LMcNish14 Layne McNish Jill of All Trades ¯_(ツ
- 12. @LMcNish14 Omada Health Omada Health is on a mission to inspire and enable people everywhere to live free of chronic disease.
- 13. @LMcNish14 Omada Health We’re hiring! Chat with me afterwards if you’re interested!
- 15. @LMcNish14 I want you to examine your current process with fresh eyes and ask yourself, could this be nicer?
- 16. @LMcNish14 I want your new engineers to walk away from their first day feeling useful, productive and confident in their choice to work on your team.
- 18. @LMcNish14 Current State of Things README Driven Onboarding
- 19. @LMcNish14 Get your shiny new computer
- 22. @LMcNish14 ERROR
- 26. @LMcNish14 ERROR
- 28. @LMcNish14 ERROR
- 30. @LMcNish14 ERROR
- 31. @LMcNish14 Works on My Machine Team says:
- 32. @LMcNish14
- 37. @LMcNish14
- 38. @LMcNish14 Debug
- 39. @LMcNish14
- 42. @LMcNish14
- 43. @LMcNish14 Make your 1st commit
- 44. @LMcNish14
- 45. @LMcNish14 Did this seem nice to you?
- 46. @LMcNish14
- 47. @LMcNish14 Setting up your dev environment
- 48. @LMcNish14 Follow a README or Wiki
- 51. @LMcNish14 Source: XKCD The failures usually don't hurt anything, and if it installs several versions, it increases the chance that one of them is right. (Note: The 'yes' command and '2>/dev/null' are recommended additions.)
- 54. @LMcNish14 Be mindful of dependencies
- 61. @LMcNish14 Imagine a world where getting started is as easy as
- 62. @LMcNish14
- 63. @LMcNish14 Minimizes set up time
- 66. @LMcNish14
- 67. @LMcNish14 Works on my Vagrant instance
- 69. @LMcNish14 SLOW
- 70. @LMcNish14
- 72. @LMcNish14 Project specific rake tasks
- 74. @LMcNish14 Easy way to set up similar projects
- 84. @LMcNish14 Rules are hard to agree on
- 85. @LMcNish14
- 87. @LMcNish14 When to go manual
- 92. @LMcNish14 Allow time for questions Optional
- 94. @LMcNish14 Give them a few quick wins
- 95. @LMcNish14 What can you do to make your on-boarding process nicer?
Editor's Notes
- Welcome Friends to Onboarding the Ruby Way!
- This is my 1st time in Taiwan and I have had such an amazing time
- Basically, all I’ve done for the past week is hike and eat and
- go shrimp fishing. Check out this shrimp, it’s enormous! Not pictured is when it pinched me right after this photo was taken. Anyways, thank you all for a wonderful time. America has a lot to learn from the hospitality of Taiwan.
- Let me introduce myself, my name is Layne McNish and I’m a software engineer and fellow rubyist from Oakland, California. I’m a bit late to the game of software. Before I became an engineer, I’ve worked in many industries from
- Publicity to
- Chef to
- Technical support to
- Veterinary Technician to
- Professional Cellist
- and everything in between. Through these experiences, I have seen many approaches to onboarding and their varying levels of success they achieved.
- Now, I work for Omada Health. We’re a digital health company focused on helping and enabling people to live free of chronic disease.
- If you’re interested in sustainable engineering practices, pair programming, test-driven development, weekly tech talks, monthly hackdays, mentoring, volunteering and constant collaboration come talk to me afterwards.
- So What am I talking about? I want to extend MINASWAN to your on boarding process and team culture as a whole. Matz is nice and so our onboarding process is nice (MINASOOPIN). Sorry, Matz.
- By the end of this talk, I would like you to examine your current process with fresh eyes and ask yourself, could this be nicer?
- I want your new engineers to walk away from their first day feeling useful, productive and confident in their choice to work on your team.
- On my first day of a job, they handed me my shiny new computer, put me in a room and said okay, get your development environment and the project set up and we’ll check back with you in a few hours. After they left, the panic set in as I frantically googled the errors I was getting during the setup process and at least once, I googled “How to set up a computer”. By the end of the day, I did get everything set up for the most part except for Elasticsearch which took me a further three weeks to get fully set up. I left work feeling dumb, defeated and questioning my decision to work there. That’s not a nice feeling to have.
- So what is the common current process like?
- Yay, it’s your first day! Let’s get you set up.
- Clone the project
- Start following the installation instructions. So far, so good.
- Error. Ugh.
- Okay, so try looking it up! Trusty old Google and Stack Overflow should save the day.
- Great, you got it working again. Let’s move on
- Let’s keep going through the instructions.
- Ugh, error again.
- Google it.
- Nope.
- Ask for help.
- Ugh.
- Ask again and they tell you the magic words: It works on my machine.
- Really? Ugh
- Pray to the Google gods and do some deep google searching.
- Oh thank god. You found a blog post on the 20th page of results that has a comment that mentions a similar problem that leads you to a solution.
- Yay, you’re all set up! Hopefully.
- Let’s run the tests! You followed all the instructions so this should be easy.
- Oh, hm. I wonder why that failed.
- Start going down the debugging rabbit hole.
- Nope, still not working.
- Oh, they forgot to tell you that the project requires you to have the full version of Xcode and python installed. Cool.
- Okay, so you fix it again.
- Success!
- Make your first commit by updating the README with all the things it was missing.
- Leave your first day feeling unproductive and wondering if you’ve made a mistake
- This didn’t seem like a very nice way to introduce someone to your company.
- How can we make it better? Let’s talk about automation. Being able to go from nothing to having green tests in just one or a couple of steps would be a dream come true. However, this can cause it’s own set of headaches so feel free to implement changes one at a time.
- Starting from the beginning, how should you have new teammates set up their development environments?
- I know that this isn’t an automated solution but I just want to state that there really isn’t anything wrong with following a README or Wiki IF it is kept up to date, all the information is in one place and not spread out all over the place and they’re able to go from nothing to having a green test suite by the end of following the instructions.
- If you want an example of a great set up guide, check out RailsBridge’s installfest guide. It works for mac, windows, and linux and provides step by step directions.
- Let’s start automating some things:
- You can easily create a bash script to get most, if not all, of your projects set up in a single step within just a couple hours.
- It’s really tempting to just hack things together but take the time to write some reusable functions to make it easier to maintain and update in the long run.
- Make your set up script the one stop shop for setting up new computers and updating current ones. You should be able to run it again and again without any ill effects. If you are using the same script for both installing and updating, your engineers are more likely to use it and keep it up to date.
- Take stock of all your dependencies and your dependencies’ dependencies. Don’t leave anything out. This is also a great opportunity to take stock and get rid of some extraneous things that you don’t use anymore.
- It’s easy to allow your teammates to make the customizations that they need to be productive. Either add the ability to add their own customization script at the end of your set up script OR
- add the ability to ask them what customizations they want on the fly and execute them as you go.
- If your whole team is using a certain version of an application, make sure that you add it to the script to use that same version. Not having the same version of GPG caused one of our new developers to have a perpetually hanging test due to a differing security screen.
- This is a no-brainer. Add logging to aid in debugging and to let them know what point in the process they’re at.
- If you want some ideas on how to set up your bash script: Github has a blog post and repo about their script structure to get their projects set up. Thoughtbot has a really great laptop setup script that I used to get started when creating the one we use at my company.
- Another setup option is using Vagrant.
- Imagine a world where getting started is as easy as saying Vagrant up
- That would be pretty sweet, right? Vagrant has many benefits such as:
- You can get vagrant and a virtual box installed and set up in just a couple hours or less
- You will get to develop in an environment that should match production. This can help give you confidence that if something works locally, it will work on production too.
- It is helpful to have everyone on the team using the exact same tools and versions. It’s such a pain when debugging to find out the problem is that one of you has a slightly different version than another.
- That all sounds good but Vagrant is not without it’s shortcomings.
- Instead of it works on my machine, you’ll get it works on my Vagrant instance. If anyone tells you it will fix that, they’re lying.
- Configuring your project to use Vagrant comes with a high upfront cost in time and effort. Configuring it can be confusing and tricky. If you’re not on friendly terms with your wonderful devops team, you may in for a world of hurt.
- I’m going to steal a quote from CHAD OSTROWSKI: Even if you figure out how to link your enormous source code directory with NFS instead of whatever default, you’re still running your app inside a resource-starved VM. Oh, your charmer will tell you, just turn up the RAM on that thing! Just turn up the CPUs! But kid, you know what’s always going to have more RAM and CPUs available than any VM that lives out its miserable life trapped inside your host machine? Do you? Your friggin’ host machine!
- For me personally, the benefits did not outweigh the hassle and annoyances that Vagrant caused me BUT that could totally just be from how it was set up. You may have a different experience than me so take this with a grain of salt and evaluate if this might be a good option for your team.
- Once you have your new teammate set up, what are some other things you can do to make their transition easier?
- Project specific rake tasks are a nice addition to your setup process but may not necessarily replace it.
- You’re a Rubyist, not a Bashist so use what you know.
- They can offer a quick way to set up projects that have similar dependencies. That way once you’ve gone through the installation instructions for your dev environment, context switching will be easy when you just have to run a bootstrapping rake task.
- BUT they’re not great for setting up dependencies. They work best if you already have a base environment set up and you use them as convenience idempotent tools to set up and update your projects.
- They also aren’t very flexible when it comes to user customization. I can’t be the only one who forgets to cuddle my commands and arguments when providing options to a task.
- Making your db setup into a singular rake task can be an easy thing to start with. Combining all the things you need to setup your database to get going in development or test mode into a single task will make your life much easier. If you need to work with production data in development, one thing I’ve seen work well is to create a trimmed subset of your production db excluding or truncating tables you don’t need to have everything working. This can cut down your setup time significantly and makes the pain of worrying about migration conflicts and data migration strategies a thing of the past.
- Shared dotfiles
- Allows new team members to learn your team’s version of best practices without being called out when they make a mistake.
- You can create hooks to check for styling, running linters, check for the format of your commit messages all before your new team member pushes allowing them to fix things before someone notices and embarrasses them by saying something about it. It stinks to have to be called out for having an incorrectly styled commit message by your teammates when you could have skipped over that to begin with.
- Developers are lazy and smart! If they’ve come up with some neat shortcuts to make things easier for themselves, share it across your team so everyone can benefit.
- Provides consistency between the development environments across your team. This will make onboarding, debugging and working together easier.
- Which makes pairing easier Not saying that you should always pair program but it is pretty fun so you should try it.
- I’m not sure if you’ve noticed but developers can have lots of opinions that they will defend to their dying day. So, it can be difficult to get everyone to agree on best practices or rules to implement especially as your team gets bigger.
- Do you have a long list of helpful aliases and commands?
- Make sure to add a help command to remind newbies of their various options.
- Remember, you don’t have to automate everything. We’re people, not machines after all. Let’s talk about some human-friendly things you can do to make your process nicer.
- Tell them exactly what you expect of them in the next day, week, month, 3 months. Next, explain what you plan to do to get them there.
- Don’t just pair them with your most senior team members. Your interns might be the folks with the most recent knowledge on how to get things set up or might have a list of the top ten things that stumped them when they first started that they’ll be happy to share.
- If your office is bigger than one room, make them a map. Don’t make them ask where the bathroom is.
- Make a list of all the tools and services you use and how to access them. New teammates will never know to ask for access to tools they don’t even know that you use.
- Build in time for them to ask questions. Understand that sometimes it can take a while to learn the words they’ll need to be able to ask the questions they really want.
- Pair them with a buddy outside their team to go get coffee or chat with. This is a great way for them to build connections to your company as a whole instead of being isolated just on your team.
- This will work best if you let them show off some of the skills you hired them for. E.g. don’t just give them busywork. Let them solve real problems.
- When you go back to your own companies, ask yourself… How can you make your onboarding nicer? How can you instill that ‘niceness’ in your culture? What can or should you automate to make it nicer for your team?
- Thanks! Does anyone have any questions or want to share an on boarding horror story?