The Junior Jump – Life After Coding Bootcamps

As a former Dev Bootcamp (DBC) student, I get a lot of inquiries from recent grads asking for tips on landing a job. I was lucky to get into the DBC early, graduating from the second cohort a year and a half ago, and the job market was quick to pick us up. However, after going through the growing pains of learning how to code in a production environment, I don’t find it too surprising that bootcamp grads now are having a harder time landing jobs.

The Problem

Though these new devs are graduating with far more web development knowledge than I did when I graduated, bootcamp grads lack some critical meta-skills that are necessary for contributing quickly and effectively in a production environment. With just a little bit of training, these bootcamp devs can be extremely valuable to companies in need of engineers. However, the simple truth remains that a noticeable chasm exists between graduating bootcamp and becoming an effective junior developer. Fortunately, the Junior Jump can be made!

Bootcamp grads are lacking in important production-specific skills, but only because a lack of exposure to them. There were so many factors outside of coding that hindered my ability to perform well at my first job after Dev Bootcamp. I was unfamiliar with planning meetings, story estimation, and product discussions, which made it hard to contribute or concentrate. I found navigating relationships with designers and non-technical co-workers to be awkward. When I finally dove in, the humongous code base was mentally draining. All these things contributed to my first story being a total disaster.

It dawned on me pretty quickly that I needed help. With time and guidance, my knowledge grew quickly, and by the three month mark, I was able to complete assignments and participate in general product areas effectively. By the six month mark, I was playing a significant role in a major release we had. The learning that I did in those six months was as critical as DBC to my getting hired at Carbon Five. Here are some things that I drew from that experience that other bootcamp grads can hopefully use to propel themselves across the Junior Jump.

How I Progressed and How You Can Improve Your Skills

Pairing and Feedback

Pairing and getting feedback was the fastest and most effective way for me to learn, and directly contributed to both of my hirings. I gained knowledge from every pair I interacted with, often copying coding patterns or styles I saw. In the process of pairing, I was also exposed to meta-skills, observing how one collaborated with a designer, navigated a codebase to squash a bug, or effectively used git or bash. When I wasn’t able to pair, I sought constant feedback. I used lunch and any free moments to discuss ideas I had and clarify things that I didn’t understand.

When you’re not able to work in a professional production environment, you have to seek out opportunities to pair and work with experienced developers. Go to a hack night with a small coding problem and find an experienced pair. What tools do they use that you don’t? How do they structure their code and their tests? What do they pay attention to that you don’t? Find things you like about their style and adopt them. Be sure to show them off when you get the chance in an interview setting! Bootstrap a project and start building incremental features using pull requests on Github. Then have an experienced developer review your code.

Learning All the Things Around Writing Code

When I first started working, there were so many factors around writing code that I didn’t know, that it was hard for me to focus on coding itself. Learning the domain model, estimation, design collaboration, git flow, and a deployment process, all while trying to show your technical worth can be hard. It took me months to learn all these little skills, but if you can learn some of them before entering the workforce, you can really hit the ground running! Not only that, but you’ll be able to talk about them knowledgeably at an interview, improving your chances of getting hired. Here’s a list of skills that gave me some trouble early on.

Estimation – Use Pivotal Tracker to define incremental stories and estimate them. Find somebody who has done it before to show you the ropes!

Design collaboration – Start a small project, and have somebody design a feature. Work with them to complete that feature. Make sure they are invested and take note of what it’s like to collaborate. Ask mentors for advice on how to more effectively collaborate.

Git – Start using a more professional git branching model to build features and fix bugs. If you can, work with others so you can learn how to navigate conflicts. Ask mentors for advice on how to best avoid conflicts and safely merge code. Learn how to squash and amend commits, cherry-pick, create remote branches, and bisect.

Pull requests – Learn how to use pull requests effectively as a step between code completion and merging.

Deployment – Learn about different environments at a company or several companies. How do production, staging, acceptance, and development servers differ? What is the purpose for each?

Developing features and story writing – Avoiding feature creep is one of the hardest things to do as an engineer. Have a conversation with a mentor about how to write more effective stories and how to stick to the architecture of that story while developing a feature.

Debugging – Work with five different engineers and you will see five different methods of debugging a problem. Using a debugger to logging to just plain ripping out large chunks of code are just a few of the methods you’ll find out there.

Be resourceful! – My mentor used to always tell me, ‘Google is your friend.’ Learn how to unstick yourself using Google, but also, take all internet advice with a grain of salt!

Learn to read code

Bootcamp schools are all about teaching you how to write code, but it’s just as important to be able to read code. One of the hardest parts about stepping into a production environment from a bootcamp setting is reading code that somebody else wrote in a context you are not familiar with.

Find a pair and dive into some gem or open source library. Pick a piece of the library you are curious about and start digging into how it works. Even figuring out how a single method works can be challenging in larger libraries!

If you’re not sure where to start, just open up a gem using bundle open [gem-name] in the command line. Install the pry and pry-debugger gems and insert your binding.pry just before your method call. You can step through every call the method makes. Docs and Github are a great place to start as well!

Summary

While searching for jobs after bootcamp schools is harder than it was a year ago, the need for developers is growing rapidly. If bootcamp grads can learn a few more real-world skills and showcase them effectively in an interview setting, they will be much more competitive in the job market.

If you’d like to work with Carbon Five to learn some of these real-world metaskills, you can sign up for a Tinderbox Meetup event geared toward improving your post-bootcamp skills here. Also, if you would like more Junior Developer specific advice, you can find more content at my personal blog, Senior Junior Dev.

Mark Levi

mattbaker

Thanks for the write-up, Ken. I’m a teaching at DBC Chicago now and DBC’s curriculum changed a lot since you went through. I just wanted to share some things we do at DBC now in response to feedback like your own:

> Estimation – Use Pivotal Tracker to define incremental stories and estimate them. Find somebody who has done it before to show you the ropes!

This is excellent feedback, and estimation is huge in software development. We now get students using pivotal tracker or trello to track stories, and we discuss project management in the context of agile/xp/scrum in lectures. Students use this in their group projects in Phase 3, and I’ve watched them collaborate and project manage very effectively as a result.

> Design collaboration – Start a small project, and have somebody design a feature. Work with them to complete that feature. Make sure they are invested and take note of what it’s like to collaborate. Ask mentors for advice on how to more effectively collaborate.

We’re doing group projects weekly beginning in Phase 1. Working in a group is tough, and I’m happy we’re giving students experience in this since, as you well know, it’s crucial out there in the professional world.

> Git – Start using a more professional git branching model to build features and fix bugs. If you can, work with others so you can learn how to navigate conflicts. Ask mentors for advice on how to best avoid conflicts and safely merge code. Learn how to squash and amend commits, cherry-pick, create remote branches, and bisect.

We’re using Git starting in Phase 1. Challenges are submitted as pull-requests, and groups are encouraged to use good git workflows to collaborate (feature branches, PRs, etc). Again, fantastic feedback from you and others regarding Git, and DBC took it to heart. We do lecture on git, and do some light work in more advance git tools like cherry-picking.

> Pull requests – Learn how to use pull requests effectively as a step between code completion and merging.

It’s a core part of how students interact with their learning experience here now. We’re 100% github starting in phase 1

> Deployment – Learn about different environments at a company or several companies. How do production, staging, acceptance, and development servers differ? What is the purpose for each?

Crucial information, but it varies highly from team-to-team (for example, some companies with continuous deployment push straight to prod). We do get students comfortable with some very basic deployment via Heroku now, although Heroku is sufficiently magical that they still have a lot to learn about running a production server.

> Developing features and story writing – Avoiding feature creep is one of the hardest things to do as an engineer. Have a conversation with a mentor about how to write more effective stories and how to stick to the architecture of that story while developing a feature.

Our lectures on Agile/XP/Scrum really help with this. We have students doing basic user stories in P1. By phase 3 they’re learning how to manage feature creep and produce an effective MVP in time for employer day. I’m really happy we’re doing this now.

> Debugging – Work with five different engineers and you will see five different methods of debugging a problem. Using a debugger to logging to just plain ripping out large chunks of code are just a few of the methods you’ll find out there.

I think debuggers are definitely a sign programmer sophistication. We’ve been pushing Ruby and JS debuggers, including a lecture on Ruby debugging in Phase 1.

Thanks again for sharing your experience, we learn so much from students like you writing blog posts like this!