Sandra SpanikI've recently celebrated my 1 year anniversary of picking up coding. A lot has changed in the past year, and I've been fortunate enough to recently get hired by a tech company for my very first software engineering role.
I know, I know... There's a plethora of advice articles like these out there, as was the case a year ago. Despite having read many myself when I was starting out, I remember being dismissive of some their advice, especially in cases where it was misaligned with my pre-existing intuitions. Umm, how about I ignore 24 different articles I've read that advise me to do a thing and instead proceed NOT to do it, thanksss. 💅
For example, having an online presence seemed a yucky and unnecessary waste of time. I'm now glad I re-examined my stance, because I was approached for my current position by a recruiter on LinkedIn. This wouldn't have happened, had I stubbornly clung to my notion that I can do this my own way without resorting to what I at the time considered to be nauseating concepts such as digital self-marketing.
So, in full acknowledgement that the body of literature is already vast, I'll add another voice "from the other side", in the hope that I might convince someone as stubborn as I was to give the below advice some consideration.
Without further ado, here's the advice I'd give my younger self as well as anyone else starting on their coding journey.
1. Consider Whether a Bootcamp is Right for You 🗺️
Do you need to attend a bootcamp in order to learn to code? Absolutely not. Are all the resources you need to learn to code available online for free? Absolutely yes. So, will you still benefit from completing a bootcamp? 🤔 Also yes! A curriculum designed by expert teachers will make it easier to learn things in the right order and avoid diving into topics that require pre-existing knowledge. For example, you should really start by learning vanilla JavaScript and regular DOM manipulation before exploring React. Otherwise, your mental model of how the frontend works will be lacking.
But bootcamps are a GIANT commitment. Before you dish out money and scale back other responsibilities to make time for what is a very intense experience - please make sure you actually like coding. This might seem self-explanatory, but there is a surprising amount of students who invest money and time prior to making sure they have a long-term interest in the subject.
Thankfully, a lot of cheap Udemy or free Youtube tutorials exist to help with this. Having a solid mental model of a programming language will set you up for success and make it easier to keep up with a bootcamp's fast pace. I started with Colt Steele's Udemy Modern Python Bootcamp, then continued with his Web Development Bootcamp before enrolling in an actual bootcamp. I could go on about what an excellent teacher with equally excellent pet-naming conventions Colt is (his chicken is called Stevie Chicks, guys, need I say more), but I'd only sound like a silly fan-girl. Instead, I will leave you with the names of some equally great instructors who also offer high-quality free or cheap courses: Angela Yu, Andrei Neagoie, Jose Portilla, but the list goes on.
2020 might have brought a pandemic, Zoom meetings and Cyberpunk 2077, but it has also graced us with an ever-increasing amount of online content creators putting out accessible courses. Take your pick!
2. Choose the Right Bootcamp 💻
If you are going down the bootcamp route (and your success doesn't by any means hinge on this, there are other ways), a word of warning: choose your bootcamp carefully. I could write a whole article on solid criteria to judge a bootcamp by (should I? Let me know in the comments), but ultimately, some of these will be subjective. Different teaching styles and curriculums suit different circumstances and learning styles. Personally, I was glad to have steered clear of bootcamps that either don't have an entry exam, or have an extremely easy one (e.g. "write a function that returns the sum of 2 numbers", or "return the first item in this array"). Bootcamps typically last anywhere between 3 to 9 months, and I am mistrustful of curriculums that promise to teach you all you need to know in a junior role within this time period without requiring any pre-requisites on your part.
I'm also sceptical of bootcamps that teach more than 2 languages - you might end up replacing depth of understanding with breadth and leave the bootcamp not feeling confident you can actually fully utilise the tools you now list on your CV. A good way to judge the quality of a bootcamp is to find graduates and look at their projects or portfolio sites - you might need to do some LinkedIn, Github or Twitter stalking to gather a large enough sample size to conclusively determine a bootcamp's quality. Connecting with and speaking with ex-students is also a great idea.
Lastly, check out SwitchUp and Coursereport for rankings and reviews.
3. Create a LinkedIn Profile - Early 👔
Whether you've chosen to do a bootcamp or are a brave self-learner, do not underestimate the power of networking. This one was the toughest piece of advice for me to digest, and I kept putting off creating a LinkedIn profile until my bootcamp's career service basically forced me to. For many of us, networking feels icky, digital self-promotion is a nauseating concept, and creating a LinkedIn profile feels akin to selling our soul to the devil. I, too, felt this way, and to a certain degree still do - I don't like living in a world which incentivises us shouting about our achievements from the top of our lungs and essentially marketing ourselves as products.
But LinkedIn also got me a job and connected me with many seriously impressive people. There's no two ways about it - if you're trying to break into tech via an unconventional route, you will benefit from having a LinkedIn account. Make sure your bio is well-written, concise and that you list any previous experience you might have, regardless of whether or not it is tech-related. The idea is that by the time you are ready for a job, you will already have a network of contacts and a history of consistently demonstrating your tech capabilities online, be it via deployed applications, posts or articles.
4. Write About Your Learning - Early 🖋️
This was another oft-repeated piece of advice I was initially sceptical about. What could I possibly contribute to the body of coding literature that hasn't already been said, by people a million times more qualified than me, a lowly degree-less peasant? I started writing articles about my learning relatively late, once I had already moved on from most backend topics. So from the outside, my online presence seems focused exclusively on frontend, and I had to convince my future full-stack role employer that I was equally, if not more, interested in backend.
If I could do it all again, I would definitely start writing way earlier. If you're put off by the fact that you don't know much yet and might make mistakes - don't be. No matter what you write about, chances are, someone out there will read your content and find it informative. More importantly, by writing about topics you're not expert on, you (hopefully) end up researching them more in-depth than you would otherwise.
Plus, if you make a mistake, people will let you know in the comments, and you'll have the opportunity to correct your mistake and learn. I cannot stress enough how helpful it is to write stuff out - I really wish I had started earlier, and my aim will be to continue writing, even as I transition into a full-time role, because I now know that it's an excellent way to solidify new knowledge.
5. Learn Version Control - Early(ish) 📁
Having a history of committing your code on Github is the easiest way to demonstrate your skills to recruiters. At some point, you will want to start uploading the exercises you complete to Github. Even though I started coding in April 2020, I didn't upload much to Github until November 2020, which is when my bootcamp started encouraging me to do so. What a waste, by then I had created a fair few full-stack applications that the world will never get to see! (They're terrible. The world lucked out.)
I should have started earlier, perhaps 2 months in. Learning Git can be confusing at first, so I would wait until I have a basic understanding of a programming language in order not to overwhelm myself. But a couple of months in, Git becomes a necessity. Once again, Youtube comes to the rescue.
6. Focus Your Energy Where It Matters ⏱️
If you're not just coding for the fun of it, but also aim to transition into the industry professionally, consider scaling back as many other commitments as you are able to. I'm aware this won't always be possible, for example, if you're a parent or relying on income from a full-time job (in which case you're an absolute trooper and my admiration for you doing all that AND re-skilling has no bounds). In my experience, there will come a time when you will start feeling compelled to make some tough decision about whether or not to give up other areas in your life to focus more on coding.
In my case, half-way through my (remote-first) bootcamp, I had to give up not one, but two part-time gigs that were keeping me afloat and rely on government assistance instead. It felt risky, and I also felt like I was letting people down by leaving my roles, but it has proved to be the right long-term move and I am proud of myself for having let go at the right time. It's a tough thing to do.
As with any skill, the more time and energy you spend on learning it, the better. It's a bit of a no-brainer, really. The difficult part is recognising, in real time, what truly matters and what can be filtered out. I hope it helps to know that if you're struggling to meet all your commitments alongside learning to code - you're not alone, many of us have been in a similar situation. There's no shame in letting go of jobs, hobbies or relationships that eat up our time and energy without giving much in return. In fact, it's a brave thing to do.
7. Taking Breaks is Key 💤
Having said this, increasing coding time doesn't always proportionally translate into more success - there is a limit, in my experience, to how much brain power one should devote to coding per day. This might vary on a case-by-case basis, but for me, this meant disengaging in the evenings and taking weekends off. We all operate optimally at different times of the day, so by all means follow your own circadian rhythm, but bear in mind that an overworked brain rarely produces good code.
As you can see, I take my breaks very seriously. I took Christmas off, and I barely ever code on weekends. This strategy will hopefully help me, in the long-run, prevent burnout and help me retain my child-like fascination for writing code.
What I was initially terrible at is knowing when to stop. There were days when I kept staring into my screen, frantically fixing fearsome bugs at night-time, after already having worked since the morning. Reliably, I'd fix a bug I was stuck on for many evening hours the previous day within the first 30 minutes in the morning. Equally reliably, next time, I'd tell myself that this time is different and this time I'll fix the bug in the evening, if I only spend 10 more minutes on it. Giving up and calling it a day was a difficult skill to learn - one that I am still perfecting.
8. Mindset Matters More Than You Might Think 🧠
You can learn anything, if you only believe it. This is not a vapid platitude, but our actual current scientific understanding of neuroplasticity. Each time you learn, your brain forms, strengthens or rearranges neural pathways. This means you have the power to actively and purposefully shape the physical outline of your brain - how cool is that. The belief that people can't change is not only archaic and wrong, it is also dangerous and leads individuals to accept malleable traits and skills as unchangeable constants.
There is a slight snag though - in order to learn best, it is beneficial to adopt the belief that you CAN, indeed, learn. Dismantle limiting beliefs such as "coding is similar to Maths and I'm just not a Maths person" or "I will never be expert at coding because I started too late in life", and you will have a better time learning.
Intelligence is not set at birth. Trust me, I wrote a dissertation in Psychology. Or don't, because let's face it, writing a dissertation in something years ago doesn't make you an expert. But do trust current academics. While there is an ongoing debate about the extent to which our genes predetermine our cognitive ability, the fact that any individual can greatly shape their intelligence is no longer disputed - not even a little. Having the belief that intelligence is not fixed but can instead be developed through our own efforts is also referred to as the growth-mindset. That's the mindset you want to apply to coding as well.
9. No, Programming is Not Easy, And That's Great 🏃♀️
Another beneficial expectation to keep in mind is that programming is hard. Don't expect it to be otherwise. It's really not easy to pick up coding from scratch, especially for someone who has never done anything like it before. It's a completely new way of thinking, and the ability to reason effectively about abstract concepts takes a while to develop.
Don't get discouraged by this fact - it's completely normal to struggle and to need to revisit concepts you thought you already mastered over and over again. With time, you will get better at asking the right questions and knowing exactly what it is you don't know, but don't ever expect yourself to know all the answers off the top of your head.
10. Let's Normalise Tears 💧
This final piece of advice is intended for me as much as it is intended for you. It's okay to feel things as you code, especially as you encounter challenging situations - of which there will be many. It's okay to feel joyous at successfully deploying an app, and it's equally okay to feel sad when CORS strikes again and things don't work.
Different people have different emotional spans. For cultural and, frankly, sexist reasons, the industry has typically attracted a certain type of person. You wouldn't normally associate this type of person with displaying a wide array of emotions. (An oversimplified generalisation, but it will do for the purposes of this article).
Nowadays, things are changing, and as a more diverse workforce enters the industry, I hope we gradually normalise feelings in a software engineering context. I, for one, feel things intensely on either end of the emotional spectrum, and I want to rid myself of the notion that displaying either positive or negative feelings is in some way shameful, or a sign of weakness. On the contrary, bringing feelings and empathy to a coding context is a bonus, because after all, the people using our software are just that - people, and being able to put ourselves in their shoes can only enhance a product.
Conclusion
I hope you will find the above advice useful. I recognise that we're all unique individuals, and as such our "best coding practices" might vary. What worked for me might not necessarily work for you. If, for example, you're the kind of person that doesn't mind working long hours and weekends, you might be able to get where I am now in half the time. But on average, I believe above advice to be general enough to apply to a large proportion of people reading this.
Thanks for reading, and happy coding! Or sad coding, for that matter. Your feelings are valid, whatever they might be.
