4 Things You Can Only Learn By Leaving Your Coding Bootcamp
Worried by the rapid obsolescence of my skills as a copy-writer in the age of ChatGPT, last year I decided to upskill within the coding school I work for — the folks whose name you can read up there as the, ahem, “author” of this article — and I signed up for a Part-Time Data Science bootcamp.
In retrospect, I may have gone into it with a touch of megalomania. I expected that I would learn to code, and I did — I just didn’t fully understand what ‘learning to code’ effectively entails. I wasn’t opening a can of worms as much as uncovering a football field of them.
The fattest of these worms (and I realise the metaphor is not the most pleasant in the world, but I’m almost done with it) turned out to be the lessons I learned once I started working on a coding project of my own, independently.
I quickly realised that there was an entire constellation of lessons which bootcamps — or for that matter universities — simply don’t have a hope in hell of teaching, no matter how well designed they may be.
Today I want to share the ones I learned — or those I learned so far! I very much expect these will be only the first of many more to come.
Lesson #1: Do Not Underestimate The Non-Tech Crowd
A bootcamp always has you working under the supervision of an instructor, or else alongside your fellow students. This means you’ll only work with someone who is much better at coding than you are, or else roughly at your level. But you never work with people who know little or nothing about it.
I was building my project partly during my Christmas holidays of 2022, which I spent together with my family. During one lunch, my mother asked me what I was doing all day on my laptop. With no other intent but to make conversation, I gave her a quick overview of what my program was, and how I was trying to get it to work.
When I finished explaining a particular for loop, she asked: “But shouldn’t you be dividing those results by a factor of 3 rather than 2?” I won’t branch off into an explanation of what exactly the loop in question was doing, suffice it to say that she was right — I had made an idiot mistake and failed to factor in a third variable in one of my operations!
Now, my mother knows nothing about coding. But she knows how to think logically, and the simple process of explaining the concept I was working on allowed her to catch a mistake I was making. Had I responded to her question by saying “It’s technical stuff, you wouldn’t understand it,” then goodness knows how long it might have taken me to spot my error and debug my program.
Here’s the thing: if you need help, it isn’t only your seniors who can lend a hand. Ask for help to those who are less qualified than you are, and don’t underestimate their input. Turning to non-developers like I did may be a bit of a drastic measure, but at least sharing your problems with junior developers shouldn’t be beyond the pale.
As long as you don’t confuse your juniors with jargon, they may very well be able to contribute. In any case, explaining your problem to them will help you understand it as well. So go for it.
Lesson #2: The Best Work Hacks Are Absolutely Unteachable
‘Bootcamps’ derive their name from military training grounds for a reason — they are notoriously intense. You’ll spend a lot of time in front of that console, hacking at one problem after another, dealing with an avalanche of new concepts.
What you don’t get the opportunity to do in bootcamps is slacking, procrastination and being a good old couch potato.
I may get crucified for saying this, but there is value in procrastination. I don’t mean ‘taking breaks’, which in and of themselves optimise productivity, I mean letting your productivity go down, I mean not being your best self for a short while. It’s part of how your mind disconnects and resets its thought processes. An excess of slack will be bad for you, naturally — but then so will an excess of work.
When I started working at my own pace rather than that of the bootcamp, my learning rate and productivity plummeted… AND YET! During those days when I didn’t switch on my laptop, I started casually jotting down some of my code on paper — not sketching a general plan or an outline, which of course is very common, but literally writing the same code I had on my console, only on paper.
I was simply toying around with my thoughts — in fact the process was rather desultory — but I was astonished to find what this did for my lucidity and my problem-solving ability. Both were distinctly, rapidly boosted. I think this has to do with the fact that I am a writer, and for years I have developed a habit of jotting down my first drafts on paper.
The working hack that I uncovered is subjective and I doubt it would be helpful to many of you. I’m not saying you all should get a pile of papers and start writing Python code on it. My buttons and switches are not your buttons and switches.
The real lesson here is not that writing code on paper helps, rather that each of us has distinct triggers which activate our productivity, and precisely because they are so subjective, it is impossible to teach them.
The only way you will unearth them is to work by yourself, at your own pace. Sometimes that pace is really slow, much slower than you would be allowed in a team or in an office. And guess what, that’s fine.
Lesson #3: You Forget Much, Much Faster Than You Think
I took one of the school’s part-time programs, meaning I was working my regular day job and then learning to code in the evenings and weekends. The experience as a whole was incredibly rewarding — there’s something truly empowering about learning the language of computers — but I don’t need to tell you that it was also exhausting. I came to graduation day looking like Tom Hanks in the rescue scene from Castaway.
So I hope you’ll be indulgent with me when I confess that after the bootcamp I took 3 weeks off from anything software (except videogames, obviously — I binged The Witcher 3 like a 10 year old). I’d heard all the proverbial wisdom about how the most important thing about coding is consistency, how you should code just a little bit but very frequently, and so on, but I thought mine would be a reasonable break.
Well, goddamn. The sheer sense of illiteracy that I felt when I first reopened my console catapulted me into one of those “amnesiac protagonist” adventures I was binging in my games.
Fresh bootcamp graduates are, in this sense, a bit of an edge case — because of course they absorb in a few months what may otherwise be learned in a few years. Even so, I was baffled by how quickly my brain had pushed all of my new learning to the back of my mind (and I mean the far, far back), and I never felt so grateful for all the notes I took while studying (methodical note-taking had, thankfully, been previously recommended to me by another part timer).
It took some time and effort to bring myself back to speed, certainly a lot more than I would have wanted.
If you have a modicum of experience with coding, this ‘lesson’ will probably not come as news to you. I expect you already learned it, and the same way I did, which is the only way it truly can be learned: not in a classroom, but on your own skin.
Lesson #4: Ugliness Is Actually OK
This is certainly going to be the most contentious of these points, and if a senior developer responds in the comments by aiming the verbal Death Star at me, then I’ll be open to listening (and potentially to being vaporized like Alderaan). I am, after all, still a beginner, and I know this better than anyone.
But hear me out for a minute. When you’re taught to code by somebody who is good, there is a very high risk that you will end up overestimating the importance of elegance.
Come to your instructor with a problem, and even if they don’t share the solution directly but simply assist you in finding one, you will end up with something a lot more concise and efficient than whatever it was you were trying to do at first.
While coding exercises are only a part of the bootcamp syllabus (much of it is project work), those will also reinforce the perception that every problem should have a solution as perfect and self-contained as a crystal.
Taking that attitude into my project led me rather quickly to developing unexpected feelings — like a potent ambition to join an anarco-nihilist punk rock band.
My project was about simulating strategy outcomes in my favourite board game, and at one point I had to get my system to calculate the number of points scored by a player based on a certain number of actions taken. Those two variables were not directly proportional to each other, so I spent a stupid number of hours trying to work out a mathematical formula that would return one based on the other.
Eventually I went for an epic ragequit and decided instead to write an elif (else-if) loop in which every possible number of actions was mapped onto the precise number of points that would score. The result was a block of 24 lines of code which in the hands of a more skilled programmer could probably have been just 2 or 3.
But my solution worked. And it allowed me to move on — among other things past my frustration — and actually make some progress with my project.
The takeaway here isn’t that as long as something works, then it’s case closed and you no longer have to ask any questions about it. If something works and you don’t understand why, then of course you must return to it and figure out what’s going on.
But as long as your code works and you understand what it’s doing, then elegance really isn’t that big of a priority. In any case it certainly isn’t worth compromising your progress over it. If it’s so important to you, you can always go back to the code later and refine it. If the result isn’t perfectly legible, well, leaving comments that explain what’s going on will be much faster than coming up with a solution that would make Alan Turing proud.
Again, I may be totally wrong about this. But elegance wasn’t working for me, and this did.
Let’s Wrap This Up: The Lessons Of The Real World
I feel like bootcamps have been the ‘hot new thing’ in the tech industry for long enough that we really should drop the ‘new’ from that title. By now they are a valid and proven path to finding a job in tech, particularly among career switchers.
But like any other learning path you choose, they cannot exhaust the impossibly, overwhelmingly, oceanically wide field of modern programming. The truth is that some lessons, by their nature, you will only be able to learn when you leave the coding bootcamp.
This doesn’t mean that you have more work to do, but that you have more treasure to find. If you discover yourself to be ignorant, rejoice — that’s what it feels like to be learning!
