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:
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.
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.
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.
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!
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.
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.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.