1. The Company

From day one, promote an open, collaborative learning culture

As part of my company’s onboarding 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.

I want to improve our contact sheet for the tech team and actually include a fun fact about the person, where they are physically located (some of our team is remote) and what specialities they have. IE — If you have any questions about ____, this person is the best resource.

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 is 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 dev 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 people prefer email? (probably not.) 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. I want to write an overview of the code for people to get started. 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. Tip for beginners: When I need to change something on our website, my strategy is to go into our github repo and search for that phrase or bit of code. Github will unearth the code I need to change.

List of common commands

There are some commands that I run 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 if we hire another beginning developer, I would definitely share these with them.

4. Get started!

Dogfooding

If it applies, have your new employee sign up for and use whatever your product is.

1. 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.
2. As an actual user, you start to feel passionate about your work.
3. 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. At my company, we have 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 thinks I can do something, I feel more confident in my abilities.