The Career Changer’s Guide to Becoming a Software Developer

More people than ever before are entering software development from non-traditional backgrounds. The number of coding bootcamps is increasing, and there’s a broad push from the industry to attract more diverse developers. Many companies are no longer solely focused on hiring senior developers, and have realized that it may be smarter to train and upskill the next generation of senior developers instead.

Software development pays well, the industry is booming, and compared to many other careers, software developers get treated very well. But I think the thing that draws most career-changers to software development, is the search for more rewarding work.

If you’re reading this, you’re most likely considering a change in career, or want to learn more about what the journey is like. I was in the same position less than a year ago, and I know that for anyone considering a big change, it’s a scary, but exciting, place to be. I made the transition from a career in marketing and communications, to doing software development at Thoughtworks. It has been one of the most challenging life-changes I’ve ever had to make. The reward has been a more fulfilling career. I want to share some of the lessons I’ve learnt while making this transition.

If you’re considering a similar change, there’s one question that you should ask yourself, above all others: if you make the switch to software development, will you like it? Getting to a level of skill where you are hireable is  a lot of work, and you may be leaving behind a promising career in the process. The stakes are high.

If you don’t know whether you’re going to like it, build things with code. Create a Tic Tac Toe game. Start a small online business and do the development yourself. Contribute to open source. Make games. Complete programming challenges. Build a personal website and do all the design and development yourself. If you enjoy any of these things, there’s a good chance you’ll enjoy working as a software developer.

Switching careers can be an epic, challenging journey - but I hope that it will be one of the best things you’ve ever done.

There are a thousand ways to learn to program; the route you take will depend on how you learn best. You can take online courses, find a teacher or mentor, watch YouTube videos, read books, get a Computer Science degree, watch screencasts, or simply jump onto the command line and start experimenting, hitting up Stack Overflow as you go. Isis Anchalee of #ILookLikeAnEngineer fame recently put together a great summary of ways to learn to code.

I did a combination of all the above things when I was learning to code, but there were a few things that helped me more than the others:

• Have something you (passionately) want to make: Whether it’s a blog, a game, a website, a SaaS startup, an online dating website, or an app to manage your family’s finances, having a project that you’re motivated to build, will push you through the tough times when learning to program. A real-world use-case for your skills will accelerate your learning. I spent a few months working as a TA at a coding bootcamp. The students who progressed fastest with their skills were those who had something they desperately wanted to build, because everything they learned, they could apply in their project.

Photo by Dev Bootcamp (link).

• Do a coding bootcamp, if you can, and if you feel it will work for you: When I was first learning to code, there weren’t any coding bootcamps where I live in Melbourne, Australia. I took the rather drastic step of moving to Chicago for 3 months to be a part of The Starter League. It was the defining choice in my journey to become a software developer.

  A good coding bootcamp will give you a focused environment, help when you need it, and support when the journey gets tough. When you’re first learning to code, it can be really hard to know what you should focus on. In my experience, coding bootcamps have been very good at scoping this down to the essentials you need to build or design web apps.

  A good coding bootcamp will also assume no prior programming knowledge, and teach you the skills you need from the ground up, unlike many programming articles and videos, which will be written with professional programmers in mind.

  Coding bootcamps can be expensive, and they’re not for everyone, but if you feel like it might be worth the investment, I highly recommend them.

Photo by Luca Mascaro (link)

• Connect with other people learning to program: Learning to code can be difficult at times. Having a network of other people going through the same challenges can be hugely important. If you don’t know anyone making the transition, attend local meetups and talk to people there, especially if you’re focused on languages popular among junior developers (Ruby and JavaScript in particular). If you’re lucky, your local programming meetup may even host a ‘Newbies’ night now and again. Make sure to go!
   
• Find a mentor who works in the industry: A friendship or mentorship with a working software developer can also be immensely helpful in your journey. They will know what the interview culture is in your local industry, will be able to give you advice when you get stuck, help you focus on the most important skills to learn, and give feedback on your code. If you’re lucky enough to find a software developer generous with their time in this way, make sure to give back somehow, even if it’s just buying lunch when you meet. Once again, meetups are a great way to meet potential mentors. If meetups aren’t for you, or there are none in your local area, you can also find mentors on CodeMentor.
   
• Focus your learning: If you’re hoping to do backend programming primarily (the engine of most apps, not the visual presentation), focus on learning one language and one web framework as well as you can. Also aim to be somewhat familiar with JavaScript, HTML and CSS, as many roles will have you working with both the frontend and backend of an application. If you’re aiming for a front-end role, focus on JavaScript, HTML and CSS. You might also focus on a popular JavaScript MVC framework like React or AngularJS.
   
• Be prepared to invest in your career change: You can spend a lot on the transition; books, courses, classes, and screencast subscriptions can add up to hundreds of dollars a month, and many boot camps are over $10,000. Despite the hype around programmer salaries, you can expect to make between $40k and $60k as a junior developer, with higher starting salaries available in startup hubs like San Francisco and New York. At first, it might seem like you’ve invested a lot in this career change without much financial reward. Over the long term though, this investment should pay off, with developer salaries steadily rising into the six figure territory as you gain experience.

Photo by Bryce Bradford (link).

• Don’t worry if your journey isn’t linear: Learning to program is tough; it takes time. If you’re juggling a pre-existing career and other commitments, it may be difficult to focus on it for more than a few hours a week. You may have doubts, you may get distracted, and you may stop progressing for days, weeks, or months. In my case, there was almost a two year gap between attending a coding bootcamp and getting a job in software development. It could have happened much sooner, but life, and my own doubts, got in the way. Trust that if software development is truly what you want to do, you’ll find your way eventually, even if you end up taking the scenic route.
   
• When it comes to your GitHub profile, be selective about what you show: GitHub is an online hosting service for git repositories, best described as version-controlled programming projects. When a repository is public on GitHub, anyone can read through your code. Many hiring managers will check the GitHub profile of applicants, to get an idea of how they write code when nobody is watching. When evaluating junior applicants, the hiring managers may not be looking for amazing code, but instead looking for enthusiasm, work done on multiple projects, willingness to try out new things, and a sense of play. Your GitHub profile is a great way to show this, but keep in mind that hiring managers may only have a few spare minutes to review your profile. For this reason, it’s a good idea to make only substantial or interesting projects public. For projects which you were just using to learn, , it might be worth making them private to give your best stuff the limelight.
   
• It’s hard sometimes: Self-doubt is a common trap for junior developers, especially those from groups who are underrepresented in the software industry. If something feels hard, it’s not necessarily because you’re not cut out for this. It might be because you have more to learn, or perhaps, because the thing you’re working on is actually hard. You may also be concerned when something you find challenging seems easy to someone else, especially when that someone else has a similar level of experience. But stick with that person long enough, and you’ll likely encounter something they struggle with, that you find really easy. We’re all different, we bring different pre-existing skills to the table, and we all practice differently. Programming is like any skill: you can become good at it if you persist long enough and care about getting better. Avi Flombaum, co-founder of the Flatiron School, says “I absolutely believe that anybody can learn how to program in the same way that we know anyone can learn how to read and write.”
   
• Be aware of your blind spots: By all accounts, career-changers have been making waves in the development community. They’re self-starters who’ve sacrificed an existing career, and sometimes a higher salary, in order to become software developers. However, we do have blind spots. The inner-workings of computers and the internet are mind-bendingly complex, especially to anyone from a non-technical background. Mastering one programming language, one web framework, JavaScript, HTML and CSS might take up all your available time. However, when you’re starting out as a junior developer, you probably won’t realize that these things are just a small slice of the technologies you work with every day.
   

  Think about the answers to some of the following questions:
  How does your code get run?
  How does your language’s interpreter or compiler know when it encounters a syntax error?
  How does typing a URL into your browser toolbar result in a web page being rendered on your screen?
  How does a web server work?
  How do you stay logged into websites even after you close and reopen your browser?
  How does your app run on a web server?
  Your project is hosted on Heroku or AWS, but what do they use under the hood?
  When people say an object is ‘in memory’, what does that mean?
  How do you SSH onto a server?
  How do you set up and use a build pipeline?
  How does your operating system run on your computer?
  
  Of course, this list could be much longer. There’s so much to learn that it can feel overwhelming. The good news is that you don’t need to know the answers to all these questions in order to be hired as a junior software developer, but you should try to learn them as you go further in your career. You can’t get really good at software development unless you have a working understanding of the tools that you work with every day. Increasing your understanding will empower you to make better choices, become better at debugging, and make better design decisions.

• When you’re struggling, take time to appreciate the unique skills you have that computer science graduates may not have yet: If you’ve attended or scheduled a work meeting, been given tricky feedback at work, been through a performance review, or led a team, you already have valuable skills that recent computer science graduates may not have. You may be more at ease talking with stakeholders, better at meetings, planning and organization, simply through having more experience. Most importantly, you may have better perspective. After all, if you’ve previously worked as a nurse in an operating theatre, a bug in production might not seem so overwhelming. After all, nobody is going to get (physically) hurt!

Photo by WOCinTech Chat (link).

• Get experience with pairing: Pairing is the practice of having two developers share one computer and work on the code together. One developer will write code, while the other watches and does some of the following things: makes suggestions, asks questions, catches errors, and thinks more broadly about how the code being written, fits into the larger program. Since both roles are fatiguing, they will usually swap anywhere from 15 minutes to every few hours.
   

  Pairing is a common practice in the industry (and especially at Thoughtworks), and even more common in the coding interview process. You don’t need to be an expert, but pairing for the first time can be a little intimidating, especially when pairing with a senior developer. Despite this, pairing can actually be really fun, and is a fantastic way to learn. If you can, get some practice with pairing before you begin doing coding interviews. If you have a mentor, pair with them. Otherwise, you can find opportunities to pair at hackathons and hack nights in your local area.

Photo by HackNY.org (link)

• Set up a mock programming interview: Programming interviews are likely to be quite different to the interviews you took to get a job in your current career. They often involve coding challenges, writing pseudocode on a whiteboard, pair programming, and feedback on your code. Learn as much as possible about coding interviews by researching them online. Then practise them with a friend. Find a whiteboard and solve simple problems by writing your code on it. Get your friend to ask you common programming interview questions. It doesn’t matter if your friend is non-technical. The experience will really help when it is time for your real coding interview, as they can be a little intimidating at first!
   
• Before test-driven development, practice error-driven development: Errors will be your constant companion when learning to code. You’ll be breaking stuff all the time, and will be face a lot of error messages. As once non-technical people, error messages can be scary. Before learning to code, they may have meant that you wrecked your computer while installing a game, or bricked a phone while trying to unlock it. An important mindset when programming, however, is to see error messages as helpful.
   

  When many developers encounter an error message, they react a little like they’ve been slapped on the hand, quickly navigating away from the  browser or shell window and peering at the code they  just wrote, trying to figure out what might have made the computer so angry. In most cases, the computer is already telling us, via the error message it just printed, but we need to slow down and read it before we can reap the benefits.

  Jeff Cohen, an instructor at my coding bootcamp, encouraged us to practise error-driven development. This method goes beyond slowing down to read error messages, and instead, lets a succession of errors guide you forward in your development. Call a method that doesn’t exist, see a ‘no method’ error, and then write the code to bring that method into existence. Reference a view that doesn’t exist, see a ‘no view’ error, then create the view. Errors are not to be feared, in fact, they can guide you. Just not in production!
   

• Learn about and practise test-driven development (at least a little bit): Once you’re comfortable with error-driven development, test-driven development is the next step in your learning. Test-driven development is a sought after skill in the industry, and familiarity with it is a requirement to get hired at some software companies. It’s the practice of writing code to ‘test’ how your program behaves, and to drive out a better design for your program. If you’ve ever added some functionality to a program, only to have it break something else that was previously working, this is one of the things that test-driven development (often abbreviated as TDD) can help with!
   

  Few programming resources for beginners focus on TDD, mainly because it can be a difficult concept to teach. When you aren’t sure how to write good tests, it can feel more difficult than writing code. You may encounter a situation where you know exactly how to write the code that will solve a problem, but designing a test around it takes an hour because you’re not sure of the appropriate way to exercise the code with a test. Learning TDD will slow you down at first, but you’ll be repaid with confidence - confidence that your programs work, and confidence that if you break something, you’ll know immediately. Tests are an incredibly useful safety net for junior developers.

  You don’t need to be an expert at testing, but some familiarity with TDD will put you ahead of many other junior applicants, especially those coming from traditional Computer Science backgrounds where test-driven development is still not always taught. Bonus points if you can eventually articulate the difference between a mock and a stub.

Photo by Domy Kamsyah (link)

Your Journey Begins

You’re about to embark on a journey that might be one of the hardest, most rewarding things you’ve ever done. Don’t be afraid: be excited! The end goal is a satisfying and rewarding career and the opportunity to make the world better through technology. No small prize.

Your future is bright. Good luck!

This article was originally published at CodeMentor.