The Difference Between a Coding Bootcamp and an Apprenticeship: Part 1
Emptying the Cup
This week, I started an apprenticeship with 8th Light — a software consultancy in which every Software Crafter begins as an apprentice. I also completed a coding bootcamp — App Academy in San Francisco — earlier this year. Though it’s only my second day as an apprentice, it’s already pretty clear how different the next six months will be than the three months I spent as a student at App Academy.
In order to get better acquainted with the concept of apprenticeships, I’ve been reading Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The book has helped illustrate some of the principal differences between learning to code as a student at an intensive bootcamp and as an apprentice at a software consultancy. I’ll be reviewing each chapter of the book and relating it to my experience as a bootcamp graduate.
In their book, David H. Hoover (Dave) and Adewale Oshineye (Ade) understand that most software developers don’t start their careers as official apprentices. They provide a series of contexts, problems, and actionable solutions to embrace apprenticeships even at jobs that don’t explicitly treat new employees as apprentices. Given what I’ve read so far, I think that anyone considering a bootcamp or an apprenticeship can benefit from familiarizing themselves with these concepts. Although a bootcamp might facilitate some concepts (such as picking a first language), some just aren’t feasible in a bootcamp environment. Still, keeping these concepts in mind would have undoubtedly helped me make the best use of my time in the few months after the end of the bootcamp.
Emptying the Cup
Dave and Ade introduce an analogy that details the need to empty one’s tea cup in order to obtain fresh, new tea. In short, in order to learn, you must be willing to learn. To be accepted into a bootcamp, you’ll have to demonstrate that you can independently learn some coding fundamentals. You won’t need to know object-oriented programming or a full tech stack, but you will need to know basic loops and methods (typically in JavaScript, Python, or Ruby). At an apprenticeship, though, you’ll already be expected to know OOP or possibly a tech stack to create an application like Tic Tac Toe. Before you get to that step, though, you must learn a computer programming language.
Your First Language
Dave and Ade give a lot of great advice about picking a first language. For instance, they suggest having “an actual problem to solve” as a way to help learn a first language (14). The lack of a problem to solve hindered my drive to code the three previous times that I tried to learn to code on my own prior to enrolling in App Academy. A bootcamp will provide you with daily projects and challenge you with a number of showcase projects to facilitate solving problems. In my case, I felt that the daily projects had little flexibility, as we often created them against pre-written tests. The showcase projects, however, provided me with the opportunity to begin tackling a problem. The primary showcase project was a clone of an existing website. Though we had little flexibility with the visual design (as we aimed for a pixel-perfect clone of a small number of features), we had more freedom to design database schemas on the backend as well as React component hierarchies and Redux state shape on the frontend.
On their own (especially as a new developer), SQL, Ruby on Rails, JavaScript, and React-Redux won’t really help you create much. But the artificial problem that a bootcamp creates will help drive you toward putting those technologies together to build a real web application. Despite making it through the eight-week instructional curriculum, I didn’t feel comfortable enough to claim that I understood these languages and frameworks until I experienced firsthand how they worked together.
Dave and Ade also suggest receiving feedback from a mentor in order to help select a first language (16). Very few bootcamp students have a degree in Computer Science, and many of them have had little exposure to coding before coming into the program. They often worked in industries without software developers nearby. Naturally, many students don’t have close peers to discuss the benefits or drawbacks of a particular language. Researching languages and frameworks online often results in reading highly opinionated and uncompromising endorsements of a language or tech stack at the exclusion of any other (the exception being JavaScript, which is universally suggested for any aspiring web developer).
That’s precisely where I found myself every time I tried to learn a new language. I credit part of my success at App Academy in having relinquished control of this decision and allowed App Academy to dictate which tech stack I would learn as my “first language.” However, I’m following Dave’s and Ade’s advice to “wear the white belt” and “take a step toward ignorance” as I’m learning Clojure (19). Clojure is the first functional programming language that I’ve ever learned. If I’m going to learn a completely new paradigm, I will have to embrace my ignorance and seek out my mentors when I struggle.
Expose and Confront Your Ignorance
At a bootcamp, the limited amount of time (a little over three months, in my case), makes it difficult to follow some of the apprenticeship patterns. Simply put, you won’t always have the time to “wear the white belt” at a bootcamp that requires nine hours of time in class with an additional three to five hours of homework and study each night.
Bootcamps and apprenticeships both foster an environment that encourages you to expose your ignorance. When you are surrounded by 75 peers struggling through the same material, there’s little stigma in admitting that you are lost. At an apprenticeship, you are brought onto the team with the expectation that learning is your full time job. Naturally, your peers are aware that you are ignorant of certain concepts or technologies. However, bootcamps and apprenticeships foster different approaches to confronting that exposed ignorance.
As a student, I vividly recall pair programming with a former student who struggled with understanding Ruby bracket methods. The syntactic sugar would allow us to access an element inside of a two-dimensional array as [0, 3] rather than as [0][3]. Believing that the core Ruby concepts — classes, instances, and instance variables — were a more worthwhile focus, I suggested that we simply move one and accept that the code works. With assessments that determined whether or not you stayed in the bootcamp never more than a week or two away, I often found myself satisfied with the how over the why.
It wasn’t until after the bootcamp was over that I began to understand the consequences of this tradeoff. At one of my first technical interviews, an interviewer asked me why I assigned a variable to a JavaScript function’s parameters and manipulated that variable rather than manipulating the parameter directly. I was caught off guard by the question, so I answered honestly: “I was taught that this was a best practice.” Despite agreeing with me, he — rightfully — didn’t seem satisfied with my inability to justify why I made the decisions I did.
The Deep End
When confronted with a difficult problem or a difficult job offer, Dave and Ade suggest that you “grasp it with both hands” (30). Coding bootcamps certainly instill that attitude in in their students. After all, the majority are entering the job search with no software development experience. You are expected to sell yourself on your ability to learn and adapt quickly. While you’ll certainly learn quickly by diving into the deep end and taking a software development role immediately after graduating from a bootcamp, the possibility of burning out can have long-term consequences for your career.
Becoming an apprentice certainly doesn’t mean you’re jumping into the shallow end. It’s closer to steadily swimming — rather than sprinting — the 1500 meter race.
