So you've decided to hire a bootcamp grad. Congratulations! As one myself, I remember being anxious about my first real tech job and wondering how I would prove myself worthy of their decision to hire me. Luckily, my company did a great job on-boarding and setting me up for success. Here are some tips for new developers and their employers to help ease the transition.
Although these tips were written specifically from the perspective of a bootcamp grad, these tips are really helpful for any new hire!
1. The Company
From day one, promote an open, collaborative learning culture
As part of my company’s on-boarding process, we went over the company’s values, and as one of them, they stress a learning environment.
- Questions and mistakes are ok.
- What we know matters. What we’re learning matters more.
- Mistakes are part of the learning process.
- Mistakes are low cost. We have monitoring/backups/recovery.
- We collaborate, help each other and ask for help when we need it.
- We teach and we learn.
Before I even wrote a line of code, I knew that I shouldn’t be afraid to ask questions and make mistakes. I felt encouraged to try things without fear of failure, and ask questions without feeling scared that I was asking something stupid or annoying. This is everything.
An informative contact sheet
I still think the best thing to have at a company is a contact sheet. At small start ups, it’s not always something that exists, but it provides immense value. As a new employee already feeling overwhelmed by new information, it’s hard to remember everyone’s names, and having a contact sheet as a resource is a great relief. What was that person’s name again? What does so-and-so do? Oh great, I’ll just look it up.
2. The Setup
Painless local dev environment setup
Challenge one as a new tech employee: set up your local dev environment and install all dependencies/tools. Inevitably, your command line will yell some errors at you, probably multiple times, before you get your codebase to actually look right.
The key to this is to have a very thorough, comprehensive, guide to getting set up. As a new graduate of a bootcamp, chances are high that you are unfamiliar to setting up a local dev environment to this extent. (Before, you probably just installed some things and started working). But each company has its own tools and dependencies, and for a beginner, having each step explicitly stated is helpful. For people who have done this before, a step might seem obvious, but when writing a guide, think of your audience as being totally new to this. Writing out the actual commands you should run is extremely helpful.
After I started working at my company, a co-worker set up docker to make set up even simpler. Now, you can just run a few lines of code in the command line and docker runs through the installation.
3. The Process
Embrace agile methodology (if you use it) from day one
For me, one of the things I enjoyed most about my new career was our daily stand ups. Even though I didn’t have much to report on my first few days, I immediately felt like part of the team by being included and hearing what everyone else was working on – even though I had no idea what it all meant yet.
If your company does them, stand ups and sprint planning are an instant way to start building camaraderie and make your new employee feel like a part of a team. It also provides structure and starts to hold them accountable for the work they do.
Documented outline of workflow
Similar to the comprehensive guide to getting your local dev environment set up, it’s very helpful if there’s written documentation that describes the company’s workflow. A bootcamp graduate has never followed a workflow before, so these are things that might come up:
- How do we communicate? Do we mainly use chat? Do we video hangout? Do we leave github comments? Or are we supposed to put all questions in an issue tracker?
- Do we use an issue tracker? Which one? Where can I go to find things to work on? How do I tell what is priority?
- OK, I found something to work on. Do I need to update the issue to in progress or assign it to myself?
- Do we do pair programming? Is most work independent?
- Do we use github? How should I name my branches? Is there a standard for commit messages?
- I’m done. Is there a review process? How do I tell someone my code is ready for review?
- How often do we deploy? What is the deployment procedure?
High level overview of code
Jumping into someone else’s codebase, especially when it’s code that’s running the complex site of a business and people who may not even work there anymore decided way back to structure it in the way they did, can be very difficult. We have several github repos that do different tasks, and it took me months to feel comfortable enough to know where to find something in the codebase. Giving someone a high level overview of how the code is structured is immensely helpful - even to someone not junior!
List of common commands
There are some commands that I ran almost daily. Some are specific to our code and have been set up to run some custom code, and some are specific to the framework we use. It’s everything from clearing a cache to compiling our SASS to logging in as a specific user. It would have been great to have a list of these to reference. Over time, I collected these into a notes document I have, literally titled “DEV STUFF”, and have shared them with other new developers.
4. Get started!
Dogfooding
If it applies, have your new employee sign up for and use whatever your product is.
- You become an actual user, so you can uncover insights about how easy or difficult it is to sign up and use the product. This is always valuable.
- As an actual user, you start to feel passionate about your work.
- When you fix or change things, as a user, you can see them and how they affect all users.
Simple first code merge and deploy
It’s good to push something into production early, just to go through the process and start becoming comfortable with it. We had a text file that lists tech employee member numbers for the framework we use. As a new developer, we show you the issue in our issue tracker, assign it to you, and you take the text file, add yourself to it, push, get a review, merge, and deploy. It’s a simple way to get the process down.
Bugs, bugs and more bugs
As a brand new developer, not only was I new to coding, but I had learned a completely different language and framework at my boot camp. Talk about feeling intimidated when I first started. I needed some quick wins.
I was told to look through our issues and find some bugs to work on. These are the best first tasks to work on for a new developer. They can be as simple as fixing typos on the site to css bugs.
- I was able to find bugs that I knew I could figure out without too much difficulty.
- I was able to push out code and see immediate improvements to our product.
- My confidence level rose as I “figured it out” more often than not.
- I felt useful because I knew that even though more experienced developers wouldn’t get to these simple bugs, as more pressing issues would always be priority, I was still improving our user experience in a way I could physically see.
- It was a great introduction to the codebase. Fixing bugs took me all over, so I learned where to find things and how it all worked.
- I learned about the language and framework in an easily digestible format. Instead of being overwhelmed, I researched only what I needed to know to fix an issue, which focused my learning. Instead of googling broad concepts, I figured out how smaller parts worked together.
Check in meetings
I think it’s important to set aside time on a calendar to have a check in with your new developer. This is a good time to ask how things are going, what could be improved, and what their goals are.
The next steps
After I fixed some bugs, I got assigned more complicated tasks. My first reaction was always, “If you’re sure I can do this…”, but being assigned them gave me some incentive to push myself to learn more. And when my boss thought I could do something, I felt more confident in my abilities.
Top comments (0)