5 Things I Learned in Bootcamp

by Rhia Dixon

Posted on January 14, 2019

woman typing

I didn’t take the college road to becoming a software engineer. I went to college to become a rocket scientist, and I hold a B.S. in Physics for my efforts. Although aerospace engineering hasn’t become a reality for me as of yet, I am not particularly dismayed. I found something that still allows me to use all that math, science, logic, and creativity to build amazing things people want to use.

How did I get here? I stumbled across a well-placed Facebook ad about a new program offering from the University of Kansas - Edwards Campus. The school teamed up with TrilogyEd to offer a Full Stack Web Development Certificate program. I was super wary about it, I needed to know whether or not the program was legit and if it would be worth the investment of my time and money. I researched several available options that were part-time, full-time, 3-months, 10-months, more expensive, less expensive, online, and in-person. I ultimately decided the schedule, price, and programs offered at KU-Edwards fit me and my direction. So I took a leap of faith and enrolled...absolute best career-decision I’ve made.

There are some things about bootcamps and code etiquette I didn’t know going into this, but I've picked up these few tech-ish tips and been wildly successful.

bootcamp is just the basics

A common misconception of bootcamp attendees is that they will learn all there is to know about whatever language or stack they’re learning. This is so completely untrue...I don’t even know where to start. Six months to a year of part-time fast-paced coding assignments isn’t enough time to learn it all. You may not even have a “good” command of all the concepts covered in the course. What you WILL have is a high-level understanding of how to build a program that works. In a MERN or MEAN stack program, you WILL have a great understanding of HTML, a pretty good understanding of how to use CSS, a moderate understanding of how JavaScript makes things functional, and hopefully a good enough understanding of databases to know the difference between SQL and NoSQL. Depending on how well you grasp things, you may also have a generally good understanding of React, Angular, or Python.

Understand that what you have learned has been applied to a miniscule codebase in comparison to what most companies are using. A CTO of a mid-size startup told me that, in his experience, bootcamp grads come off as arrogant and they think they know more than they actually do. He stated he’s all for confidence in your skills and abilities, but there is a not-so-fine line between confident and cocky. No one wants cocky.

version control is an understated joy

Companies want you to know what version control is, and you learn a little about it in bootcamp. However, I feel that the value of versioning and source control is highly understated in class. This is partially due to the fact that your codebase consists of your homework assignments, so it is easy to feel secure in your code and pushing to master. I suggest getting on the Google and utilizing the tutorials that are out there. I will always love GitHub, and I will always maintain my open source projects there...but they are not the only place to keep your code.

I have also discovered there are benefits to using Atlassian’s BitBucket -- for instance, it works so well with GitKraken (a cross-platform Git client that makes managing repositories easy). One of the main reasons I appreciate version/source control is that you can create a branch, make experimental changes, and if you don’t like those...you can blow the whole branch away! I can’t count how many branches I trashed...but the fact that those trash changes didn’t mess up my working code?? Priceless.

write clean code with comments

My goodness...this lesson right here is one of the reasons I’ve been successful in my software engineering role. There is nothing worse than having to go back to fix someone else’s undocumented, messy, nary-a-comment-in-sight code from five years ago! I’m not suggesting you comment every little bit of code, but a short comment about a function’s purpose isn’t too much to ask, right? Also, indentation matters. Sometimes, proper indentation (with tabs, not spaces -- looking at YOU, python...) is required for the code to compile.

The comments and formatting aren’t just for other people looking at your old code, it is also for YOU looking at your own old code. It is extremely difficult to write version 2.0 of a program when you can’t remember or figure out how version 1.0 works. When it comes to naming variables and functions, it is a good rule to keep it simple. It’s funny to run across random fun names, but it’s not so much fun to figure out what they do. For the record, I am not knocking fun names -- they just need to be clever enough to indicate their purpose. Try to name things in accordance with what they do so that you (or some unsuspecting soul) can easily figure out which parts are connected to what.

there is power in the markdown

I don’t think the importance of the README.md is emphasized early enough, nor as often as it should be, during the bootcamp curriculum. My bootcamp didn’t have us really use our README.md files until a little over half-way through the course (and I mentioned that during our exit interviews to help future attendees). By that time, we had completed multiple projects, and I’d slept several times since then. You go ahead and try to remember what you did or why 15 projects ago without documentation. That is a struggle like no other. When I started focusing on my README.md files, I wasn’t even thinking about the same things I was when I wrote the programs. The only thing that saved my sanity was that I put good comments in my code and wrote in a way that made it easy to follow.

Your README.md is the overiview and map for people, including you, looking at the code of your project. It tells the user the purpose of the project, how to use it, and what you may have used that they need to have. All portfolio projects should have a README. If you add some awesome new libraries? Add them (and the versions) to the README. Did you use specfic commands to run things? Document those in the README. If you worked with other people to create your awesome project? Credit them in the README and maybe add a link to their GitHub profiles. Don't know how to format your README.md file? You are in luck! GitHub has an awesome helpful page for that. GitHub user PurpleBooth also wrote up a nice, simple template to get you started.

your projects are your experience,
don’t half-step!

It’s not hard at all to take on the “easy” assignments and just get them done, regardless of presentation. Yes, functioning ugly-ness is better than broken pretty-ness. However, the cliche adage is true: You reap what you sow. Some of these bootcamp programs are free-ish, some are thousands of dollars, and some are tens of thousands of dollars. For the amount of time and money you have invested into this program, why would you put forth anything less than your best effort? This is how a potential employer will be able to have some visual insight into what you have learned and how you put things together.

I believe part of my success with my program was due to me attacking every assignment as if it was going to be in my portfolio. This left me with several polished, multi-concept, interesting projects to choose from when the time came to set up my portfolio. As the concepts got more difficult, I spent more time researching, testing, rewriting, and tweaking. My Harry Potter Hangman game was a great resume talking point! Even now, looking back at some of my projects, I know I’m going to rework them and use what I’ve been learning in my year as a software engineer to make them better, make the games harder, make them load faster. Keep this in mind: potential employers will know that you’re a bootcamp grad, and they know that you’ll be an entry-level candidate. This is completely okay. Just be sure that your projects reflect your best effort.

more blog posts
about the blog
"A career woman in street clothes" is what my husband called me as we were reflecting on how much I had managed to accomplish in a year. I liked the sound of that so much that I gave the name to my blog. The goal of this blog is to record my experiences as they relate to my tech journey and share what I've learned, read, and tried in hopes that I can encourage, inspire, or help someone else.
about the author
Rhia Dixon Meet Rhia -- a pretty awesome, somewhat nerdy, super-friendly software engineer, wife, and mother of one...a lover of puzzles, sci-fi book series, the Skittles in the purple bag, and ALL things Harry Potter. #TechIsLife #kcwomenintech #BlackTechTwitter