Five Years after a Coding Boot Camp
On August 23, 2013, I left the United States Navy after fulfilling a 6-year contract.
Shortly afterwards, a mentor told me about programming. He mentioned I should look into attending a development boot camp. Coincidentally, a programming boot camp opened where we lived.
Knowing nothing about programming, I applied to the program and was accepted.
In January of 2014, I began a three-month programming course focused on teaching full stack web development.
We completed a few projects and worked 6 days a week. The training and subsequent job search resulted in nearly every graduate finding a job in the tech industry.
It’s been five years since I attended that program, and I want to share what I’ve learned from the experience until now.
The First Job
After we finished the 3 month program, our instructors continued to work hard to teach us how to find employment.
I went to the campus a few times after completing the class to discuss my interviewing strategy and how I could improve my chances.
At that time, I felt it was impossible to find a job. I knew my skills weren’t great and couldn’t imagine any company wanting to hire me. I sent out resume after resume feeling as if I was going to die. There was no way I would find a job.
My instructors had faith in us. They reassured me many times we would all be able to find jobs. I even remember one of the instructors looking at what requirements my first job interview listed and teaching me some topics based on the job listing.
After sending out 100 resumes and interviewing twice, I received an offer at a company with a remote office in Nashville, Tennessee. Nashville is also where I went to high school, and I jumped at the prospect of moving back home.
After moving back home, I chose to live with some friends who were still able to live a partying lifestyle. I tried to party with them and underestimated how that would affect my job performance. Since I didn’t have strong development skills, I really needed to work longer hours than I did. I ended up under performing at my job.
My skill level was not adequate enough to perform to the company’s expectations, and after two months I quit.
The Feeling of Can’t
After quitting my first job, I also quit programming for 6 months. I felt I wasn’t cut out for writing software and didn’t have the talent to be a developer.
Skills require a unique balance. If you try to tackle challenges that are too hard for you, they seem impossible.
If you try to do tasks that are too easy, you feel bored. There is an optimal push zone you should look for when learning skills that mixes things you have done in the past with some level of uncertainty.
The perfect mix of familiarity and novelty can push you into a state of learning where you can focus. The time melts away and you feel enjoyment.
At the time, I lacked the awareness and motivation to work in this space. One of the detriments I felt learning to code in a boot camp is the lack of time I spent digesting and applying all that we learned.
When you spend 10–12 hours a day, 6 days a week learning something completely new, you soak your brain with more knowledge than you can learn. You don’t have time for your brain to recover, and you end up learning a fraction of what you can learn. You can not drink knowledge from a firehose.
Exposure to stress for long periods of time decreases the quality of your learning and starts to kill your passion for the craft.
Before taking a similar course, I would spend 6 months falling in love with programming. If this wasn’t available, I would enroll in a 6 month program that moved at a slower pace.
Teachers can Inspire
By far, the most important lesson I learned in my programming boot camp is how damn cool it is to create things. Our instructors built their own businesses, found software engineering to be fun, and are some of the most interesting people I have met.
They truly want to build a better world.
At the time, I had not met people who were focused on building a better future. Just being around these types of people is motivating.
After I quit programming, I spent around half a year regaining confidence and interest to start learning again. After taking six months to explore, I once again burned with the passion to learn. This could not have happened without exploring the programming space in a self-directed way.
The drive to learn a passion can be extinguished from forced conditions. The learn drive an also reignite through self-discovery and exploration-based learning.
Powering The Learn Drive
Through attending the boot camp I learned how to build software on a team. What I lacked was knowledge from a traditional computer science background.
My instructors spent a couple morning sessions playing with computer science topics. We solved a couple problems, and I mostly struggled through material I found hard to comprehend at the time.
You can find jobs coding without strong theoretical knowledge. You can even write good code without strong theoretical knowledge. But it’s hard to write lasting code without strong theoretical knowledge.
When you pursue learning in passion, you tend to see the connections yourself. Rather than having theory forced down your throat in an intensive class, you run into hard problems and must learn theory to help you solve the problem. The more connections you make through your practice, the stronger your technical knowledge becomes.
Learning to trust your instincts is a skill most people in modern society have forgotten. Many people who were educated through the traditional system forgot how to explore and learn from their exploration.
You can relearn how to pursue a passion. But it does take time. The journey is not without its hardships. In the course of only a few years, you can remold your brain and retrain your self-discipline.
Attending the programming boot camp introduced me to the love of building. Not everything I have built has garnered attention. But that’s ok. The simple pleasure of the building process enriches my life each day.
It’s OK to Write Bad Software
When I first began writing software, I encountered many situations where I didn’t know how to solve the problem. Even if the technical specs were clear, I worked long hours to transform them into a product.
Sometimes, even when I would solve the problem, I felt my solution was sub-standard. I felt reluctant to let other people review my work. I didn’t always state my ideas in meetings and rarely said “I don’t understand, can you explain it to me?”.
Not doing these things led me to under performing at my first job. It was only when I learned that it doesn’t matter who the smartest engineer in the room is that I really started to grow.
After five years, I think it is not the smartest engineers or the ones who write the “best” code who are cherished.
Writing clean, bug-free code is a skill necessary in any engineering position. But it is not the only skill that leads to higher productivity. Engineers who have a variety of skills become the most productive. Companies tend to promote the most productive engineers.
The most productive engineers are not always the best coders. The most productive engineers tend to hand test their features. They double and triple check to ensure their code doesn’t add nasty bugs to the code base.
Productive engineers also excel at communication. At larger companies, communication skills are valued at least as high as technical skills.
When you work at a company on the scale of the FANG companies or other large Fortune 500 software companies, it is more important for you to be an effective communicator than simply a solid, knowledgeable engineer.
Don’t forget to develop your people skills. If you are looking to attend a programming boot camp, make sure they include collaborative project building. I’ve heard of some boot camps that don’t focus on building projects. Don’t waste your money on those types of classes. Even if a boot camp that doesn’t teach by building projects helps you find a job, you will need to build your skills from scratch. You might even under perform like I did.
Devleague focused on collaborating to build projects together, so we dealt with building projects with many people. This skill has helped me at every company I’ve worked in the past 5 years.
I am learning the secondary skills on my own through the years. This strategy has worked for me because in most companies the most valuable skill you contribute as a software engineer is the ability to plan out an application and build it as a team.
You don’t need be a CS major to succeed
After graduating from a coding boot camp, do not sell yourself short if you don’t have a Computer Science degree. You will probably find it hard to pass the first few technical interviews due to a lack of breadth of knowledge.
As long as you keep learning and stay interested you will be able to learn enough theory to be hired. It might take you a shorter or longer time than it took me. That’s ok, as long as you keep learning and interviewing, you will find a job.
The longer you continue to learn, the more likely you are to also surpass your peers.
This might seem like an audacious claim. How can someone who went to a multi-month boot camp build better skills than someone who attended a 4-year degree?
The truth is, many college classes don’t focus on building solid skills. There are college grads who are extremely skilled engineers and computer scientists. There are also college grads who attended prestigious schools didn’t learn much.
Some of the former may attribute their skills and knowledge to their degree programs. All of them have spent an exorbitant amount of time outside of class perfecting their craft.
If you took the same high-achievers in college, had them attend the same classes without giving them an opportunity to work on their own at home, they would not have attained the same level of skills as you see today.
Fear not. With enough applied effort and passion, your skills can also reach the highest levels of engineering excellence.
Learn All the Way Down
Always obsess over the problem at hand. This requires you also obsess over the solution and how your company is implementing this solution.
No matter what technology your company uses, it is important to learn as much as you can involving that tech stack. The programming languages you use in your daily job will change. Even so, it always pays off to know a technology as deep as possible. There are similarities between any technology you currently use and many other languages and tools.
The more deep concepts of programming languages you learn, the easier it is to pick up others. There are only a finite amount of core programming paradigms. If you can learn them well, you will find it much easier to use those paradigms in new languages.
The biggest challenge software developers face is discovering a way to continue learning in accordance with their learn drive.
Classes can not teach you to grow your passion in the subject. An inspiring teacher might be able to inspire a few students in her class. But for long term learning you must learn to explore and inspire yourself.
It’s only through the positive feedback of self-directed learning and solving problems will you start to build learn-based passion. The greater the passion you feel for a subject, the more you will transfer your knowledge into a long-term, consistent form.
The first step to cultivating passion is finding ways to stay curious in the stack you are using at work.
Note: learning the stack is not just learning system knowledge. Remember to focus on learning the actual programming languages and frameworks you use each day.
I have met engineers at large companies who don’t learn their tech stack in depth. These developers get by on system knowledge alone. Vast system knowledge can help you solve problems in the short-term.
If your company ever fails, the cost of not developing solid technical knowledge is a harder time finding a job.
System knowledge is important to solve problems at a particular company. But it will not help you to increase your problem solving knowledge across projects long term.
Things I would Change
After describing the lessons I learned above, I remembered mistakes I made along the way. I have curated these mistakes into a list. Enjoy them! Laugh at them! Learn from them! Do whatever it takes to avoid them.
Take breaks in between employment
I had opportunities to work on my own projects while between jobs. Even with a fair amount of savings, I worried about money and focused all my energy on finding a job. When finished, these projects could have worked to help me find better employment long term.
Finding a job is not as hard as it might seem. You only need to apply consistent effort in connecting with people and you will find opportunities.
If you have good projects and spend a bit of time each day sending out resumes, you will find a job. If you find yourself in a situation where you have time, try to work on learning some new skills and building a project that displays the application of those skills.
There is value in standing still
More than once in my career I left an inconvenient work situation after a little over six months. This didn’t hurt job prospects in the long term. But it did hurt my development ability.
Staying at a job gives you the opportunity to deploy many versions of a product to customers. You have the opportunity to see how the features you build influence sales.
Solving problems from development to release is an extremely valuable skill. It can be worth staying at an inconvenient job long enough to see a project through multiple releases.
If you switch jobs too often, you don’t get to stay with a project to maturity. You do get an opportunity to see many different codebases and implementation methodologies. Both are important to becoming a better developer.
Tell your story as soon as possible
While attending Devleague, I met a developer advocate for a big company in Silicon Valley. He told us to start blogging as early as possible. I remembered his advice and took it to heart. But I didn’t start focusing on developing content until much later.
Remember this: right now, the challenges you face in your life are valuable to someone. These challenges will not feel valuable to you.
This phenomenon is normal. We don’t know the value the story our lives can bring to others. There are people scouring the internet for your specific story to motivate them. These people might have already seen all the other bloggers’ material and think it doesn’t apply to them. Start putting yoursout earlier!
My road into the world of software development might seem wild to some. My journey through learning Chinese, serving in the military, and living abroad for years may feel exotic to some. To me it feels normal. This is because it is my life.
Your story is the same. Boring to you and valuable to others.
No matter where your skill level is or where you are in your software journey, keep learning and working on yourself!
View this article on my blog
