The Advantages Of Being Self-Taught

At a recent meetup event I was conversing with a small group of attendees, one of whom was an aspiring self-taught mobile developer. He was passionate and enthusiastic, but there was some doubt in his mind. He’d been following our conversation which to that point had been filled with tech-related jargon, and admitted that he was struggling to keep up. He feared that his lack of experience, or of a CS degree, meant that he was at a major disadvantage when it came to finding his first tech job.

Having been in the exact same position a year ago, the conversation led me to a realisation that none of these ‘disadvantages’ ended up being detrimental to my career prospects. To the contrary, I believe there are several advantages to being a self-taught developer.

Communication skills

An agile tech team is rarely made up purely of developers. Not only must you know how to code, but you will often need to explain complex technical problems to product managers, BAs and, depending on the size of your company, sales, marketing and even clients and customers. Within a development environment it’s easy to spend 99% of your time communicating with other developers who already have a deep understanding of your challenges. There aren’t many opportunities to gain experience in adapting your language to fit the vocabulary of your non-dev peers.

If you’re self taught, it’s likely that you’ve spent time in another industry. And whether that was serving customers in a retail outlet or presenting statistics to a room of people, you’ve already gained a huge amount of invaluable experience in being able to empathise and communicate with people from a variety of backgrounds, making it easier to keep the whole team aware of what you’re doing and why, and be able to ask questions so that you can fully understand the requirements of the business.

Learning faster

Author Malcolm Gladwell popularised the theory that it takes 10,000 hours of practice and hard work to become an expert in anything. It’s a shaky and strongly challenged theory, but the mantra ‘practice makes perfect’ has been applied to many subjects. If you apply this to teaching yourself how to code, you would expect that the time you’re putting into learning means that you’re becoming a better coder over time. What might be less obvious is that you’re also teaching yourself how to learn. You’re not following a text book cover to cover, or struggling to meet a submission deadline. You’re developing your own learning rhythm, figuring out how to grasp difficult concepts quickly, learning how to find answers to questions without the benefit of a tutor or mentor. You’re making mistakes, lots of them, and instead of having them pointed out to you, you’re experiencing their consequences and learning how to adapt to those failures.

Once you get your first tech job, you’ll be thrown head-first into things you aren’t prepared for. But the time you’ve invested in learning how to learn means that you’ll adapt quickly and be up on your feet in no time at all.

Vocational skills

I’ve spent a lot of time working with computer science graduates, either during their ‘year in industry’ or as part of a graduate employment programme. What continues to surprise me is that almost none of their university courses seem to teach the fundamental vocational skills that almost every developer needs when working within a company. They learn complex algorithms and concepts such as turing completeness, but they’re not strongly encouraged to learn things like version control, unit testing, DevOps, or how to write clean, maintainable code.

The self-taught approach leaves you without a nice juicy qualification with which to pad out your CV, so the alternative approach is to build a portfolio of published work, either having released apps to production or published your code on GitHub (ideally both). If you’ve published your own apps then you’ve had to learn the entire process, from File -> New all the way to deployment. And to maintain a portfolio on GitHub requires at least a basic level of knowledge around version control. You come up against a lot of the challenges that companies face when trying to bring a product to market, so once you’re in a job, you’ll hit the ground running on lots of these things.

Job satisfaction

The most likely reason for wanting to pursue a career in software development is because you have a real passion for coding. Teaching yourself to code is not easy, and you’ll only stick with it if you enjoy it deeply. If you get to the stage where you want to turn your hobby into your career, then getting that first job is made all the sweeter; You’ve sacrificed so much of your free time to become an awesome coder and now here you are, getting paid for doing something you love. It’s an incredible feeling, and it inspires you to do awesome work. It makes you extremely valuable to employers.

Have I missed anything out? Share your own experiences, I’d love to hear them!

My First Six Months in Software Development

When I started writing for this blog, I had just come to the end of a 3-month voluntary unemployment period, during which time I had worked hard on building up a portfolio of work that eventually led to landing my first tech job. At the time, I wrote about that journey with the aim of supporting and encouraging others considering a similar path.

Six months have passed since I took my first step onto the tech career ladder, and although it hasn’t been long, I’ve learned a huge amount that I couldn’t possibly have known before I took myself down this rabbit hole. With the benefit of hindsight, I’ve collected some observations and tips for the benefit and interest of anyone hoping to take a similar path.

Asking for help

You’ve just convinced a company to hire you, and now that you’ve started, you might feel that not knowing what you’re doing is a very bad start. Before I landed my first gig, I’d taught myself to write (and had published several) mobile apps, and I thought that I was coming into the job with a wide range of useful skills that would see me hit the ground runnin. Yet after just one day, I felt totally overwhelmed. Almost immediately, I was knee-deep in advanced Git commands, Kibana queries, setting up build servers, understanding cloud architectures, managing CI, Calabash UI tests, and so on, and so on.

Fortunately, there was no shortage of colleagues and mentors whom were more than happy to help get me on my feet. And I’ve since spoken with many other junior devs from other companies who have had a similar experience, so thankfully it seems endemic to the industry, not just my company. It doesn’t make sense to suffer in silence. Your team wants you to succeed, and understands that you won’t know everything, so they see the benefit in answering any questions you have. One particular colleague responded to my apologies for asking stupid questions with “there is no such thing as a stupid question here, only stupid answers”, and that’s resonated with me since, as I continue to soak up as much knowledge from my team as I can.

So ask, and keep asking. It’s expected of you.

The learning curve

As I alluded to in the previous section, be prepared for a very sharp spike in your learning curve. There will be a huge amount to learn not just on your first day, but constantly, as you and your team look into using new technologies or better utilise ones you’re already using.

You can give yourself a little bit of a head-start. Learn version control thoroughly, as you’ll be collaborating with other people on the same code repos, so you’ll need to get familiar with branching and making pull requests. Make sure you’ve studied unit testing, because the code you write to test your apps is more important than the code you write to build your features. Learn about mocking frameworks and experiment with different unit testing frameworks, dependent on your technology of choice. Learn to read and understand stack traces, so that you’ll be able to track down bugs easier.

But even if you master all of the above, you ain’t seen nothin’ yet. You need to be prepared for – and be excited by – the prospect of having to learn new things every day.

Imposter Syndrome

Thinking back to my first few days, I remember feeling that I’d managed to convince my new employer that I could actually do a job that I was in fact massively unqualified to do. I thought it was just a matter of time before I was found out, and politely escorted to the exit.

It turns out that a lot of people feel this way, and a lot of the time, I still do. It’s something that I’ve realised I should get used to. With technology improving and evolving faster than ever, the fact is that you’ll probably never become a master of your domain. There’s always way too much more to learn and understand. New frameworks, new ways of thinking, even new platforms. Everyone in your team, from seniors to mid-levels to you, are going through the same thing. It’s just a part of the job, so don’t worry about feeling like you don’t know everything. Because you never will. And that’s OK!

The gender gap

Before I moved into tech, I had been working in the media industry. At all of the places I had worked, women were very well represented – at my previous company, the entire workforce was 55% female, most of my successive line managers were female, and the same was reflected right up to the exec team (I’m only talking about employment figures here – I have no idea about salaries). This was immensely positive and I strongly believe it played a huge role in the company’s impressive successes.

Before I got into tech, I had heard about the under-representation of women in development/engineering roles. But it was still a shock when I attended my first engineering all-hands, where in a room packed with people, I could count the number of women in the room with just my fingers. There are very talented women in my team, and they make up about 30% of the headcount, but their roles mostly cover product management, UX design and QA – only a fraction of the coding engineers are female. A stroll down my office floor paints a similar picture.

This observation has been perhaps the only negative part of software engineering I’ve encountered so far. Reading up on the subject, I think that this is a problem endemic to the west, a cultural stigma which stereotypes programmers as predominantly male. Only 16% of computer science undergraduates in the UK are female, a shocking statistic, whilst in India the balance is more like 50-50. I think our academic systems need shaking up, and many more young people should be exposed to and encouraged to take an interest in engineering and logic-based activities from an earlier age.

This is an eye-opening read: https://www.theguardian.com/lifeandstyle/2017/aug/08/why-are-there-so-few-women-in-tech-the-truth-behind-the-google-memo

A career for life

I made a mistake when I began applying for jobs. At the top of my CV, below my email address, I added my phone number. At the time I figured that it’s just something everyone does, after all it’s much easier to answer any questions a potential employer has if you can converse with them directly. Unfortunately I had underestimated the demand for developers. Tens of recruitment companies grabbed my public CV within hours of me posting it online, and in the beginning it worked in my favour – by the end of the following day I had secured 3 face-to-face interviews and a few telephone interviews, and by the end of the following week I had a choice of job offers. But despite wiping my CV from all of the places I had posted it, 6 months on I still receive a phone call at least once a week, and receive a couple of direct emails per day, all asking if i’d be interested in new opportunities.

It’s a bit annoying, but I don’t mind it so much. It can be very insightful and interesting talking with some recruiters, who are happy to spend time talking to you even when they know you’re not looking to move on any time soon. It gives me a lot of confidence that when the time comes for me to move on from my current job (which I don’t intend to do for a while), all it should take is a few calls and emails at most. I’m in a lucky position, where employers (generally speaking) compete for candidates, rather than the opposite. It also presents the possibility of taking a break from my career, to perhaps travel or learn something new, and then being able to get a job once I’m ready to. It’s very comforting.

Share your experiences

Have you had any different experiences? Do you have any other tips for new techies? Please, share them in the comments, or feel free to ask questions!

Image credit: Tirza van Dijk