What I Learned (And Didn’t Learn) at Coding Bootcamp
A reflection, one year later
--
A year ago today, I had just finished week 1 of a coding bootcamp. It wasn’t my first exposure to programming, but it was the first time I had immersed myself in what had previously been a casual hobby.
To be honest, I hadn’t put much thought into the syllabus or into the learning outcomes. I had thought of it on a macro level: I already know X, and according to the internet, I just need to learn Y and then I’ll be all set.
I was wrong, of course. I assumed that if I followed the “plan”, I’d know everything I needed to know to “become” a full-stack developer. At the time, I’m not sure I had a clear understanding of what that even entailed.
I learned a lot, but the things I didn’t learn are what propelled me forward.
I learned JavaScript and Ruby. The syntax, at least.
Because of the way coding bootcamps tend to be structured (3 or so months of intensive project-based study of JS and sometimes Ruby), I learned the syntax of these languages pretty well. I was able to complete the mandatory projects with the assigned technologies. I built an acceptable junior-level portfolio.
But…
I did not learn how to apply what I learned to other projects.
I used JavaScript to pull information from an API because I was told to. I used document.getElementById because that was the syntax I was taught. I used SASS because it was a project requirement, even though the CSS was minimal and didn’t require SASS.
On another project, I used Ruby to build the back-end of something I don’t even remember at this point. I used Ruby because I was told to. Because it was a project requirement. I used Sinatra, too. Because it was a project requirement.
If I hadn’t been told which technologies to use, I’m not sure I could have pulled off any comparable projects at the time. Not independently, at least. I learned how to use specific technologies in specific situations. I did not learn how to make these decisions on my own, and I did not learn how to build upon things I had already built.
I learned how to use the terminal.
From day 1, we did as much as possible from within the terminal. Create a folder. Create a file. Navigate to the file. Make commits in git.
But…
I did not learn what I was actually doing when I ran certain commands in the terminal.
If something didn’t work — just try to sudo it! Why? Because!
Oh, we ran into an issue? Stack Overflow said to run this command in the terminal. I don’t know what exactly it did, but it worked!
This approach did not set me up for success. The terminal is not a place to cast magic spells that mysteriously fix something you have broken. It felt a bit like Dungeons and Dragons; take an action, and then roll to see if it was successful.
At bootcamp, I learned common commands, but I didn’t learn what was happening behind the scenes when I ran these commands. I’m glad that we spent a lot of time in the terminal, but I realize, in hindsight, that it wasn’t enough.
I learned how to debug.
Open the console. Oh, look. The error is on line 36. Yep. I did, indeed, forget that closing bracket. My bad. Fixed it.
But…
I didn’t REALLY learn how to debug.
Finding a typo is not even close to finding an actual bug and figuring out how to fix it. At bootcamp, we didn’t build anything complicated enough to encounter any actual bugs.
The projects in bootcamp were relatively contained, and they all included a front-end. You could literally see if you had done something wrong.
There were no infrastructure considerations. There were no staging environments. There were no instances during which we could accidentally destroy something. There wasn’t much to break, anyway, other than my own code.
Only after I realized what I didn’t know could I figure out how to build upon what I actually did know.
I left coding bootcamp after 2 months. I felt like I had learned as much as I possibly could have learned. I had the syllabus, so I knew what was coming up. I spent that time learning independently, applying what I had learned in a less restrictive context, building a portfolio, and thinking about whether I really wanted to be a full-stack developer.
The thing is… while I did learn a lot, I didn’t learn the fundamentals of computer science.
Ultimately, I decided to go back to technical writing, which I had already done for years. I had learned more about computer science as a 15-year-old technical writer than as an adult at coding bootcamp. To be fair, though, I learned more about straight-up programming at the bootcamp than I learned in my first tech writer role.
As a tech writer, I get to learn everything from new programming languages to infrastructure tools. This is how I like it. I don’t learn well from getting a high-level overview of things. I like to immerse myself.
If you really want to know how something works, try to document it.
At the moment, I’m taking a course in Google Cloud, re-learning SQL and BigQuery, and documenting complex back-end systems. I run our engineering publication, and I write internal and external documentation across multiple teams.
I don’t regret attending bootcamp.
In fact, I recommend it to a lot of people, depending on how they learn and what they hope to accomplish.
If I hadn’t learned JS and Ruby, I would have been clueless when reading code at work. If I hadn’t encountered JSON during one of the projects I did at bootcamp, I wouldn’t have been able to write documentation about it. If I hadn’t learned git, I would have been lightyears behind. And if I hadn’t learned to navigate the terminal, I would have been helpless in a professional environment.
For me, coding bootcamp was a piece of the puzzle — but it wasn’t the only piece. The things I learned at bootcamp helped me figure out what I didn’t know. My own desire to grow helped me fill in the gaps.
