From Bootcamp Grad to Software Engineer

I’ve interviewed hundreds of software engineers over the course of my career, and their overall training generally falls into a few big groups:

1. Computer Science Grads
2. Self Taught/Lifelong Learners
3. Bootcamp Grads

Not surprisingly, we’ve had great success with computer science graduates. They often need considerable on-the-job training about the practical aspects of working on a team of software developers, but they usually have a strong foundation to build on.

We’ve also had a ton of success with self-taught engineers. These folks had interest early in their lives, combined with access to resources, and they’ve taught themselves how to write software. This has usually been a many-year process driven by a sustained interest. In order to keep at it, they are always working on their own projects, which gives them real world experience. They might have gaps in their foundational knowledge, but they’ve dug into many things due to the projects they’ve worked on and the problems they’ve faced. They often have a surprisingly deep understanding and ability to figure things out quickly.

In the third camp, there are also a lot of promising software engineers. The challenge is that often these folks are coming into software development for the first time, and going through a 8, 12, or even 24 week program gives them only the most cursory knowledge of software development. These programs, out of necessity, start at the end of the process. They teach the tools to use, and the steps to follow, but often these folks end up graduating with such a shallow depth of software development knowledge that if anything strays slightly outside of the path they have traveled down, they get completely lost.

But as I said earlier, many of the folks coming out of boot camps are really promising software engineers, they just need a deeper level of understanding. Or they need to show potential employers that they understand the current level of their knowledge, and they are actively seeking to deepen it. The wonderful thing is that this information is now available everywhere, you just need to find it. Unfortunately, that can be a challenge if you’re just starting out and don’t really know what you don’t know.

This has been fresh in my mind due to the huge number of bootcamp grads that I’ve seen applying to our positions over the last year. Because it can be difficult for new bootcamp grads to set themselves apart from the crowd, I wanted to create a list of topics for a fresh bootcamp grad who is looking to take the next step in their career. I’m not trying to recreate a computer science degree, I’m trying to collect a list of pragmatic topics that you can dive deeper into that will help you transform into a productive software engineer.

Keep it simple

Don’t get overwhelmed by this list. Don’t try to tackle the whole thing at once, just give the list a quick read. Maybe do a bit of reading about the different items in the list, and then just start small. Pick one thing to dive deeper into and give it a go. I tried to organize the list in the order that I thought they were the most important, but you might have different interests. That is okay, the whole point is to keep learning.

#1 Write software

The number one thing you can do coming out of a bootcamp is continuing to write software. So many bootcamp grads I see that apply for our positions have Github accounts which have gone inactive as soon as they graduated from their bootcamp. The bootcamp is just the beginning, you’ve got to show potential employers that you’re digging in deeper and are continuing to learn. In the software world you’ll be doing it for the rest of your career.

I’m not saying you need to launch a giant open source project, but just find an interesting side project to tinker with that will push you to explore. As with many hard skills, the best way to get better is to practice.

#2 Read software

If you want to get better at writing software, you’ll need to be exposed to more software. Until you land your first job, that can be difficult. Thankfully there are lots of large open source codebases written in different languages and frameworks that you might be interested in. Here are a few web based projects you can start with:

Rails – https://gitlab.com/gitlab-org/gitlab, https://github.com/discourse/discourse

Django – https://github.com/getsentry/sentry

Node.js/JavaScript – https://github.com/netlify/netlify-cms

Node.js/TypeScript – https://github.com/outline/outline

If you know of other great open source applications for other languages and frameworks, let me know and I’ll add them here.

#3 Soft skills

Soft skills are usually defined as things like:

• Communication skills
• Time management
• Collaboration
• Creativity
• Empathy

I’m not a big fan of the term “soft skills”, because it insinuates that these skills are less important than your “hard” skills. In most situations, I would argue that soft skills are far more important to the success of your career as a software engineer. Everyone knows the most difficult part of building software is figuring out what to build, being productive, responding to change, working with your team etc…

The book Soft Skills: The Software Developer’s Life Manual by John Sonmez is a great place to start if you’re looking for some solid advice in this area of personal development.

#4 Learn to break down problems

One of the biggest challenges for new developers entering the field is that they are routinely thrown into challenges that they have never faced before. Sometimes problems can feel huge and completely overwhelming, and watching more senior engineers solve problems can feel mystifying.

But the reality is that almost all problems worth solving are overwhelming if you try to solve them all at once. Every good software engineer, whether they are doing it intuitively or explicitly, takes a problem and breaks it down into discrete chunks in order to solve it. Gaining this skill will take time no matter what, but you can accelerate your learning here by being more intentional about your process. Here are two posts that I think can be helpful to get you started:

• Simple Programming Tasks – Breaking Down The Problem
• Breaking Down Problems: It’s hard when you’re learning to code

#5 Care about your code

Care about how it looks. Care about how it is indented. How deeply you nest things. How clear your functions are. Care as much about how your code looks as how it functions. When it comes to writing software professionally, you rarely get awarded just for solving the problem. You’re generally working with a team of people, and if no one can figure out your code, or people hate looking at your code, then you’re not going to get very far. On that same note, if you’re asked to complete a coding challenge and the code you hand in looks terrible, you’re going to be passed over.

If you don’t just innately care about your code, don’t worry, it is something that can be picked up with time. The first thing to do is to start with a linter. Most linters will clean up a lot of the surface level things that make code “ugly” (as well as find common mistakes). They will fix things like inconsistent indentation, weird capitalization, warn about deep nesting, and in general help you stick to your language’s stylistic standards.

If the linter you use will auto-apply fixes, I would recommend not using that feature at the beginning and instead looking at the changes it is recommending and research to understand why these changes are being made. There are a ton of standard refactorings that these tools will recommend that are important to understand (see Refactoring section below).

You can’t just stop at a linter though, they can only fix the most cursory issues with your code. If you want to go further, and you do, I would check out the book The Art of Readable Code. It is a wonderful book on writing beautiful code, without a lot of extra fluff.

#6 Basic Computer Science Topics

People love to joke about how impractical most Computer Science educations are, but there are a ton of topics you learn during a CS degree that will really give you a leg up in the professional software world.

One of the best ways you can quickly close some of your knowledge gap here is to go grab a copy of the Imposters Handbook by Rob Conery. It will give you a high level overview of a ton of computer science topics in a very approachable way.

Topics such as:

• Data Types
• Data Structures
• Boolean Logic
• Relational Databases
• Algorithms
• Patterns

There are even some nice videos if you want them. If you’re looking to really dig in deep, you can go on forever with computer science courses from MIT’s OpenCourseware.

#8 Structuring a codebase

This is a hard one to provide solid guidance on because it’ll depend a lot on which language and environment you’re working in. But the idea is that you’ll need to learn to do at the application level the same thing you do at the code level – keep things neat and organized. You’ll want similar things to live in the same place, and you’ll want to make it easy to find what you’re looking for. Look around at how other large projects using the same stack as you are keeping things organized. Focus on things like:

• Folder structure
• Namespace structure
• Grouping of related files/classes/modules

Here is a great post by the Slack engineer team that can give you a good idea of how much of a difference a well organized codebase can make – Slack Engineering – Happiness is a freshly organized codebase.

#9 Software Design

Our job as software engineers is to deliver value by creating software. So how we create that software is at the very core of our profession. So why is it so far down my list? Well, software design is also the most subjective topic that we have discussed so far, and one that you’ll be struggling with for the rest of your career. Not only will you constantly discover better ways to design software, but what is considered state-of-the-art will change as well. You’ll work with some folks who feel very strongly that software should be built in one way, and then you’ll interact with another group of people that feel just as strongly that software should be built in a very different way. Over time you’ll just have to decide for yourself what works best for you and the team that you’re working with.

But the best way to get started figuring out what works for you is to expose yourself to different takes on software design. To get you started, there is one book that has had an outsized influence on me and that is Practical Object-Oriented Design by Sandi Metz. It is hands down the best book on object oriented software design that I have ever read, and if you’re just getting started, I’d recommend taking a look. Another book worth taking a look at is A Philosophy of Software Design by John K. Ousterhout.

You’ll inevitably find topics in both of those books that you agree with, and some that you disagree with. You’ll find that you aren’t so sure about other topics. The point is to expose yourself to the knowledge, and over time you’ll internalize it more and more until you have your own philosophy of how software should be designed.

#10 Refactoring

One of the biggest hurdles you need to clear in being a professional developer is learning how to slowly improve the codebase you are working within as you go. Focusing on only changing the code you need to change in order to check the boxes off on your features will lead to a codebase that slowly rots over time. A professional developer is always on the lookout for places where the system they are working on can be improved, or where the code they are adding changes assumptions in the system in a way that needs to be addressed, or where a piece of the system has outgrown its original intent.

Just staying vigilant of where the code “just doesn’t feel right anymore” will get you pretty far, but there are some wonderful resources out there that can accelerate your knowledge. Martin Fowler’s book Refactoring: Improving the Design of Existing Code is the bible of refactoring and is worth checking out, but a recently released book called Five Lines of Code by Christian Clausen might be an even better place to start.

Keep Learning

Before you have a job in the field, it can feel impossible to find time to write code or read code or do any of these things mentioned above. This is doubly true if you’re a career-switcher, trying to balance all of this with the other demands of your existing job and family and all of life.

Trying to learn a new field of knowledge is a huge endeavor, especially one as large and rapidly changing as software development. It is a challenge that takes effort and persistence and humility. Most employers understand this, but we also need to see some evidence that you are up to the challenge.

So with whatever spare time you can scrape together, try to figure out how to keep learning. If you can’t make time to write software, maybe you can try reading code instead of browsing Reddit. If you don’t have time for that, maybe you can listen to an audiobook on software engineering during breaks.

There are some tactics that will help you learn faster than others, but the most important part is to do something to keep learning. So when I’m interviewing you and I ask you what you’ve done to keep progressing your skills, you have an answer. You can talk about the book or podcast or something that has opened your eyes and led to a new insight.

Every good software engineer, no matter how experienced and credentialed they are, learns a huge amount every year. It’s just how this industry works at its current stage of immaturity. So beyond your specific set of skills when you apply, what I’m looking for is that continuous learning mindset, proof that you have what it takes to keep learning and growing – evidence that you will become the great software developer you have the potential to be.