Things They Don't Tell You About in Bootcamps

There's a tl;dr at the bottom cause this post is quite long.

Primer

I started in my development career by going to a coding bootcamp; Bloc specifically. It was great and it taught me a lot of technical skills, most importantly how to learn, and I got to work 1 on 1 with mentors in the field. My program was longer than a ‘normal’ bootcamp. I spent 1.5 years going through the program. It was geared to be longer and more in depth than more traditional bootcamps. 9 months into it, just over the halfway point in the course, I got my first job at Modern Message, a great startup located here in Dallas, Tx. It was a bit of a shock to go from coding on my own projects or an open source project to a company where there’s consumers, clients, sales teams, product teams, designers, customer service reps, and investors.

It’s been almost two years since I was hired, and I’d like to go into details dealing with the transition of going from bootcamp to career, and what I had to do to ensure not only I, but team and the product I was working on was successful. There’s a lot of things bootcamp’s just aren’t able to teach you; things they can’t prepare you for. Hopefully this post sheds some light on the transition for fresh out of bootcamp jr. developers and senior developers mentoring fresh out of bootcamp jr. developers.

The Main Content

Disclaimer: I’m going to just refer to bootcamps as a global here. I know my experience is from a specific bootcamp, but I think that even though mine was possibly more thorough than a typical bootcamp, it still didn’t prepare me for the things I’m about to talk about.

Soft Skills

Soft skills are a strange topic to discuss without stepping on toes, and this forks into a whole other range of topics. I’m going to keep this one short.

Bootcamps aren’t able to teach you how to interact professionally and with empathy for your peers and managers. It’s important to be able to function well as a team. This does not mean you have to be a very extroverted person always talking to everyone, but instead, be someone who is approachable to the rest of the team. Spend sometime to think about what that means. If this is an intentional focus, as you develop in your career, mentoring will come a lot more natural when you’re approachable.

Understanding how to say “no” in an empathetic way is a powerful skill that I don’t know that I’ve even gotten close to mastering. It’s about understanding what the goal of the other person is, and communicating what limitations, constraints, or consequences will come as a result. This can be simply explaining that for this bug to be solved right now, means that this other work is going to get punted for the duration of time that it takes to solve the bug and get the fix out. It can also be politely declining to talk about something unrelated to protect yourself from context switching.

Being able to communicate clearly and effectively is a skill, and something that needs to be practiced all the time. Practice explaining technical topics to your loved ones or friends. I did that with my dog and I think she probably knows more about programming than I do at this point. Think about perspectives of people who aren’t in this world everyday. This will make you extremely valuable to the engineering team and to the rest of your organization.

We’ll come back to these soft skills later on.

Making Tradeoffs

Bootcamps are great at teaching you the ideal techniques and practices for developing clean, maintainable, and readable code. Things like TDD, OOP, and refactoring are brought to the forefront of your focus during your time at a bootcamp. Bootcamps SHOULD be teaching you these things to give you a foundation and base level understanding of writing great code, until you’re able to deviate from them in favor of your own thoughts and opinions, but when you’re a Jr, you don’t have those yet.

Most companies don’t operate like a student with their projects, instead, there’s money involved and lots of other people. This makes tradeoffs absolutely necessary. It’s a cycle that needs to be understood by those entering the field. The priority of users over developers is a hard one to grasp. I think in a startup’s early days, that just getting to market is the most important thing, or just finding their market fit is the most important thing. There’s some arbitrary point I call the Product Event Horizon, where the product user base is sustainable, paying, and growing, and this is when the focus becomes infrastructure, technical debt, planning for the future, refactoring, testing etc. At first it’s about getting out the door, then it becomes how you actually move.

Given this cycle, tradeoffs are necessary depending on where your company is. When I first started my job I was shocked (I know I was naive) that a lot of the code base was untested. Well, the company was only a few years old at that point. Looking back it was way better than it probably should have been, and comparatively to most startups in our situation. But it was a shock nonetheless. This was when I first discovered that we had to make tradeoffs to meet deadlines, client expectations, and stakeholder expectations.

It’s not easy but learning when and how to make tradeoffs is important. Ask engineers during interviews at a company, ask them when you start working there. Is there sort of an understood area to make those tradeoffs? Is there a plan for handling those in the future? Begin to wrap your mind around those things in order to be better prepared for the future.

Dealing with Stakeholders, Sales and Product Managers

For clarity’s sake, when I say product I mean product/project managers.

Bootcamps don’t really have high pressure environments. There’s no way for them to replicate the pressures of an organization effectively enough to cause you to have to make tradeoffs or put you into a corner where you either break something or lose a customer.

There’s a perception that’s quite common I’ve seen pop up all over blogs like this, in my own company, and especially Twitter: there’s a never ending war between product/sales & engineering. I don’t like this perspective because it automatically lends itself to division among a team and in a hectic environment like a startup, it can produce bad results and conflict. This will inevitably cause burnout and make work less fulfilling and enjoyable. In order to combat this, we have to refer to some of those soft skills I discussed earlier.

Communication is so important between engineering and product. It’s important to be able to explain how or why the feasibility of something is crazy, or why this thing isn’t a quick fix. Communicating technical topics in simpler ways can lend it self to avoiding conflict further down the line and help you to explain why something failed or broke in front of a customer.

It’s also important to recognize that it’s likely a person doesn’t have malicious intent against you personally, but they don’t understand the cost of what they are asking. Communicating that cost in a way they can understand can really help bridge that gap for them.

Engineering needs the other departments just as much as the other departments need them. Product, Sales, Marketing, Customer Service and Engineering form a symbiotic ecosystem. We all depend on the other to keep the company alive and thriving, so it’s best to make sure you’re doing you’re best to work as a team.

I’m fortunate enough to work at a company that values honesty and feedback, but some of you might not be so fortunate. The best advice I can give, to a jr. engineer at a company who’s culture is lacking in this area, is to be consistent and follow through. Be the example as much as possible, and hope you have an affect on the teams your working with. It’s not easy, but more often than not you’ll find that at least one person will recognize what you’re doing, and help open doors for you in the future, and you’ll have a tremendous amount of personal growth and patience you didn’t have before.

When in doubt, have empathy, believe the best in the other person (easier said than done), and be honest with yourself and the other person about realistic expectations.

Reading Other People’s Code

Most of the time in bootcamps you only ever have to read your own code. Sometimes you read someone else’s or example code, but most of the time the context is fully there and understanding the purpose of each little piece is easy. That’s not always the case.

Codebases than have been around for more than a year are likely going to be complex in how they are set up and do the things they do. Sometimes they aren’t as clear, because a solution at a particular scale has to be complex. For the first few months of my career, the only way I could understand what was going on was to step-through debug through anything I was curious about. This is one practical technique to help, and something I still do that to this day.

The only way to get good at this is to practice. It’s like reading music. You can know the theory, what the symbols mean, what the notes are what part of the different clefs etc. but sitting down and sight reading is a whole different story. Practice. Practice. Practice. Read open source code if you’re not in the field yet. A lot of projects have Gitter, Slack, or Discord channels to join, and you can ask questions about how a particular thing or area works. I had a great time with some fellow students meeting once a week to talk about technical topics, read documentation, or read code. This really helped me out a lot. I never read for 100% understanding, I read to get a high level understanding of what each method did and how a given set of data is processed through something.

As you’re understanding of the code grows, so will your opinions on how it was written. Before you form your opinions about the person who wrote it, stop, take a step back, and think about the situation the person was likely in when they wrote it. They were probably making tradeoffs (as discussed earlier), the company as a whole was probably in a rush to land a specific account or client etc. Again have empathy for your fellow engineers.

Practice & Empathy.

Fresh Eyes Can Bring Better Solutions (but not all the time so take risks anyway)

In bootcamps, the problems often solved are small ones, ones that already have their “tried and true” solutions. This makes the mental toll figuring out solutions takes less burdensome in some ways, because there isn’t long term (years worth) of maintainability to be considered, or clients on the other side. Sometimes the best solution is the simplest one, sometimes not. Thinking outside the box is an important skill for a programmer to have, and sometimes a jr. developer is the perfect conduit for thinking outside the box.

If you see a different approach that could be taken or a potential way to rewrite something ask about it. Ask a senior developer why something was chosen to be written that way, and ask about the tradeoffs of your solution. It’s easy for jr. developers to feel the insecurity of being new to their field, and not want to run the risk of sounding ignorant or naive, but it’s an important learning opportunity. Sometimes you might stumble across something no-one had thought about in the midst of a chaotic time.

Don’t get stuck in an analysis phase while working on an implementation. Look at how similar things were implemented in the code base, replicate that, or do it in a new way. See what happens at code review time. You never know what you might stumble upon. If it gets rejected, take it as learning, not rejection. Ask questions, don’t be afraid to break something. Your bound to break something eventually anyway, as we’ll talk about later, so don’t let that fear paralyze you into not pursing doing something cool or great.

All that being said, listen to your fellow senior engineers. They probably have gone through that implementation style at some point and may choose to bypass your code. Don’t get too emotionally attached. Always remember, you learned something cool that might come in handy one day. Stick it in your memory and leave it there for when it might be relevant.

Find Your Fit (Organizationally/Culturally Speaking)

Job searching is an important part of a bootcamps curriculum. At the beginning it’s just about getting that first offer letter. After that’s complete, you have a set path to gaining experience which will then snowball into an easier job search later on. What’s important with this is learning from your first job what you thrive in, and what you don’t.

Some people thrive in a startup environment, where everything is ambiguous and you move at 100mph down the product roadmap. Some people prefer a less intense environment where they can focus on their code, focus on building complex things and the pass them off to the release team. The environments are drastically different and important to distinguish early on, cause it can shape the rest of your potential career.

Personally, I thrive in stressful environments. When the pressure is on, the deadline is in 4 hours and it’s 4am, I honestly can do some of my best work. I hate it but I love it. But it’s not for everyone and that’s absolutely ok. Be honest with yourself, after your first year, take some time to really reflect on the type of environment you thrive in. This is a personal thing so there isn’t much to say on it.

One more thing, don’t let the temptation of “cool startup life” drive you to be miserable. Not everyone enjoys it, and most things about “cool startup life” are fickle and don’t matter at all after you’re there for a quarter or two. It’s more important that you find a place that you’re able to slot into the team well and flourish than it is for you to find a place with a ping pong table and a beer tap.

Be intentional and honest with yourself.

You’ll Take Down Production

One thing bootcamps absolutely don’t tell you about, is what it’s like to take down production. You can hear and read about it for years, but until it happens you don’t really know what it’s like. There’s a few things to keep in mind when this happens that are vital to you personally and professionally.

• Own up to your mistake
• Alert the right people right away
• Ask your fellow developers what you could have done to prevent what happened
• When you bring it up to stakeholders, product, upper management communicate to them that you’ve taken steps to prevent this from happening again by learning what you did wrong and going from there.
• Even if no one else prompts you, write up a post-mortem document yourself, and post it somewhere you can access it. Writing does a lot for helping you understand something when you feel bad about it

Don’t be stupid, but don’t be fearful. The whole team has likely done the same thing you did (maybe in just a different way) and it’s almost like a right of passage. Accept your responsibility, apply what you learned, and move on.

It’s worth mentioning that some company cultures aren’t to great when it comes to this type of thing. Which is unfortunate cause we’re all humans and make mistakes. Given these environments, it’s likely though, that taking responsibility is still the best path forward, not only for yourself, but even in harsher environments people will still value that.

Take responsibility and learn.

Wrap Up

I’m sure there’s plenty more topics that you don’t learn in bootcamps that I didn’t mention here. I may do a follow up post describing some more. Hopefully, this post will help some bootcamp students as well as senior engineers working with former bootcamp students.

Remember: all of us developers are always learning everyday so as long as you’re doing the same you’ll be just fine.

I have plenty of thoughts on bootcamps and have a special place in my heart for bootcamp students. Feel free to reach out to me on twitter @juliusdelta , my dm’s are always open. I might regret putting that up on a public site but it’s all good, it’s just Twitter.

I'm really curious to know what other developers think about these things? What do you see bootcamp students lacking? What other things can they do to better prepare themselves for the working environment?

tl;dr

• Soft skills, practice communicating and breaking technical things down and explaining your ideas
• Learn where to make technical tradeoffs, ask co-workers if you have to
• Deal with stakeholders/product & project managers with empathy and good communication (e.g. softskills)
• Practice reading other people's code as often as possible
• Fresh eyes can bring better solutions, but not all the time - so take risks cause you never know
• Find the environment you thrive in and go there
• You'll take down production, when you do, taking responsibility and owning is probably the best idea