If you’re reading this, you’re probably interested in learning software development but not interested in completing a four-year degree program to get a bachelor’s degree in computer science (CS).
There are a lot of good reasons to be at the intersection of “want to be a developer” and “not want to get a degree.” So I’m going to provide you a roadmap to getting the skills you need to be a software developer.
Chances are that you already have some of the skills I’m going to talk about. Hopefully, I can point you in the right direction to gain the skills you don’t have.
You Can Be a Marketable Developer without a Degree
Some software companies are hesitant to hire outside of degree programs. But there are two big reasons they should reconsider that:
- People with non-CS degree backgrounds tend to have more interesting work & life experience, other well-developed skills, or a unique perspective that makes them valuable team members. If you’re looking to change careers, that means that as a software developer, your previous life experience will be really valuable.
- The pool of CS program graduates is generally not very diverse in race, gender, or socioeconomic status (it skews toward affluent white men). Companies that want to be diverse will have a difficult time being diverse if their hiring pipeline isn’t.
So What Does it Take to Really Learn Software Development?
Atomic (my company) hasn’t had much success in hiring outside of CS degree programs. I’ve always suspected that CS grads do better in our hiring process than, for example, coding bootcamp graduates, for two reasons:
- CS grads have spent a lot more time writing code. I’d argue that it takes a least a year of full-time work to be a competent, professional developer. You aren’t just learning some rote algorithms or a laundry list of languages and design patterns. You’re learning how to think in a fundamentally new way. This requires rearranging some neurons, and that takes time.
- While a lot of computer science classes are non-essential, there are a few crucial ones that a professional software developer absolutely cannot do without.
This idea is similar to one expressed by Gayle Laakman McDowell, author of Cracking the Coding Interview, in her blog post “So that whole coding bootcamp thing is a scam, right?”.
In the rest of this series, I’ll outline what I believe you need to achieve these two requirements without pursuing a formal degree. Part 2 will cover algorithms, part 3 programming, part 4 other domains, and part 5 community.
Assumptions
This is a broad topic, so I’m making two assumptions to narrow it down. This series will be most helpful to you if you meet these criteria.
1. You’re somewhat technical.
Maybe you learned how to use a command line that time you needed to install mods for a pc game. Maybe you’re a graphic designer who knows what website guts are made of. Maybe you were just really good at making custom Neopets websites. Maybe you learned to program in high school and are interested in turning this into a career. For brevity’s sake, I’m going to assume you know the most basic basics of programming languages.
If you aren’t technical, this guide might still be helpful to you, but you’ll need to do some legwork first. I recommend you start with an online coding tutorial. Team Treehouse is a good place to start. So is Codecademy. Whatever you do, put an emphasis on writing code and getting a feel for what it is you like about coding. If you pick a tutorial that is tedious or that gets you stuck, be quick to reach out to a mentor or to pivot to a different tutorial that might be better organized for you. Learning software development is iterative just like making software is iterative; expect to try, fail, restart, fail a little bit beyond where you failed last time, and to keep going.
2. You have some non-development work experience.
And, whatever that experience is, it informs your interest in learning software development as a second career. If you’re coming fresh out of high school and want to pursue software development, this might not be the best guide, but only because I’m really far removed from that path. I’d still be happy to help you but might not anticipate some things that would be relevant to you.
A Timeline State Machine for Gaining Skills
It’s difficult to describe a general timeline given that people are going to enter this at different levels of expertise, so let me show you a state machine (kind of a flowchart) that describes how to organize your time.
I didn’t just pull this idea out of nowhere. The most valuable classes I took in getting my CS degree were project-based and had a structure similar to this, and my learning process generally follows this state machine.
State 0: Talking
You should spend 5 – 10% of your time talking to a mentor or peers within a learning-based community. This is helpful for things like getting unstuck, getting set up with a project, or learning what you want to learn. Reading this blog post would fall into this category. I have a whole post about finding a community or mentor later in the series.
State 1: Learning
This means reading a textbook or watching a tutorial or attending a class to understand an abstract concept—like hashing, for instance. This should take up about 30–40% of your time.
State 2: Building
You should spend most of your time in this state; if you want to make software for a living, then you should prepare by making software, even if you think you aren’t good at it. It won’t be pretty. You’ll waste days on really dumb small oversights or chasing down bugs that you created yourself. There’s a lot of learning taking place even though it might not feel like it. Whereas you might have learned what hashing is in State 1, you could transition to State 2 by implementing your own implementation of a Hash Set.
State 3: Applying
Once you’ve done enough learning and building that you feel like you can apply to a job, then apply! This is the end state for getting yourself a software development job.
A Note on Setting Goals
When it comes to learning new things, I always set really small goals so that I can achieve them, and then quickly set a new goal. It’s very easy to set a goal that is way, way, too big in software development. (In the industry, we call it scope control.) Here is my rule: “Set a goal such that if it were any smaller, I would have already accomplished it.”
You Can Do This!
When I was first learning to code, I naively thought that one day I’d be able to read all the code in my computer’s operating system, and “see the matrix” or something. As I progressed through my classes, I realized just how misbegotten this notion was: the amount of code that needs to run between me writing some Java code and seeing “Hello, World!” on my screen is absolutely mind-numbing.
At first I was dismayed. There was no way I could realize the dream of understanding all the code that was running on my computer (why this was my dream in the first place is a great question). It felt like software development was this impossibly vast landscape and I would just be lost in it, unable to do anything useful, and I’d never be the master of my domain.
But I was wrong. It turns out my domain as a software developer is Learning New Stuff. For the vast majority of programming questions, I’m in the same boat you are, but I probably know how to learn the answer faster–only because I’ve spent so much time learning things I don’t know. So, no matter what language you use, or what problem you’re solving, or how fast your code runs, or how expensive your computer is, at the end of the day, you’re a maker, and you’re learning just like everyone else. So good luck and be sure to reach out for help!
If you’re working on becoming a software developer, get in touch! My home email is [email protected]. Let me know how it’s going, what worked for you, or even where you need help.
You should also check out the rest of the series:
- A Roadmap
- Understanding Algorithms
- Learning to Think Like a Programmer
- Expanding Your Skills into Other Domains
- Finding a Community
Good luck!