Non-CS-Major Developers Are No Different
December 12, 2020
Translated from the Korean original.
⚠️ Everything here comes strictly from my own point of view, and it isn’t aimed at any particular group or person. It’s drawn from a fairly narrow slice of experience, so if something in here rubs you the wrong way, I appreciate your understanding in advance.
Before I begin
Here’s my own take on the vague fear or misunderstanding people carry around “not majoring in CS” when they start out in development. The CS knowledge I bring up along the way is something every developer needs to pick up eventually. That’s not in question here. What I actually want to get into is when you learn it, and how you approach learning it.
You’ll regularly run into questions like “I didn’t study CS, so where should I even start?” from people just getting into development. Plenty of bootcamps market themselves with titles like “a developer course built for non-majors.” Some job postings even list “a degree in computer science or related field” as a requirement.
Framing things this way, splitting people into “majors” and “non-majors,” quietly assumes two things:
- You can’t become a developer without knowing things only CS majors know.
- CS majors and non-majors absorb the same development knowledge differently.
Misconception 1: You need to know things only CS majors know
Let’s start by defining the term. What actually counts as things only a CS major would know? I can’t read anyone’s mind, but my best guess is it means the coursework from a CS degree: operating systems, networking, data structures, that kind of thing.
None of that is unimportant, to be clear. If anything, looking back on my own short career, I sometimes wish I’d paid more attention in those classes. That’s how much it matters.
What you need depends on the moment
This varies by field, but you don’t need to have mastered everything in a CS curriculum just to start writing code. Early on, it’s probably more useful to understand what a variable or a function actually is, think carefully about the code you write, and focus on solving whatever problem is in front of you.
Knowledge you don’t put to use fades, like some box shoved in storage until you forget it’s even there, let alone what’s inside.
I think it matters to know why, when, and how a piece of knowledge gets used. My motivation to study hasn't come from "I might need this someday," but from wanting to fill in whatever knowledge I was missing to solve the situation in front of me.
If you run into a specific gap, whether directly while solving a problem or indirectly through something happening around you, it’s not too late to learn it right then. You can’t know in advance what you’ll need, so instead of hoarding knowledge just in case, let the problem in front of you decide what you learn. It’ll stick with you far more, and it’ll actually feel like yours.
Say you’re chasing a performance fix, staring at a waterfall chart and a response header, and you go look up networking concepts just to understand the terms in front of you. That’s not too late either, and I’d bet knowledge picked up that way is far more likely to actually stick.
What you need also depends on the field
“Development” is really too many different fields to lump under one word.
Take algorithms. If the field or product you’re chasing leans on algorithms directly, then yes, that knowledge needs to become yours right away. If not, I think it’s completely fine to study something else first. In other words, whether you need algorithms on day one depends entirely on the field.
Job hunting is a slightly different story, since some companies do run algorithm tests, but I don’t think you need algorithms just to start learning to code.
Sure, grinding algorithm problems can make you a bit more comfortable writing code. But I think you get far more of that comfort from building a bunch of side projects.
Algorithms are just one example. The real point is: don’t study everything first and pick a field later. Design your own roadmap around wherever you’re actually trying to go.
Misconception 2: CS majors and non-majors understand things at different speeds
I suspect this is exactly the assumption behind why so many technical courses market themselves as “for non-majors”: that people without a CS background will struggle with terms like variable or function, and that everything needs to be explained “slowly,” step by painful step.
Honestly, that’s neither right nor wrong. How fast anyone understands something just varies by person. Majors and non-majors alike hit a moment where they meet a concept for the first time, and how quickly it clicks comes down to the person, not the degree.
Majoring in CS doesn’t guarantee you’ll instantly follow a dense, jargon-heavy explanation, and skipping it doesn’t mean you can only learn through endless hand-holding. It’s a shame that something shaped by each person’s own experience and disposition keeps getting filed under a major/non-major label instead.
Misconception 3: Developers who came from a non-CS background are impressive(?)
You can find no shortage of YouTube videos and blog posts on “how someone coming from a non-CS background became a developer.”
That word “coming from,” tossed around so casually, actually carries a fairly loaded meaning at its root. Can “non-major” really be someone’s “origin,” like a social status? The intent is probably just to capture how lost or uncertain it feels to start a developer career from a field with nothing to do with development. But it’s worth stopping to ask whether a word we use without thinking twice is quietly feeding a frame of discrimination.
None of this is meant to downplay the effort of people who became developers without a CS background, or to say it isn’t impressive. That effort is enormous and valuable, but it doesn’t mean people just starting out as developers need to carry a vague fear because of this word.
There’s nothing you can’t do because you didn’t major in CS, and nothing you’re automatically good at just because you did.
Wrapping up
This post doesn’t speak for everyone. It’s just a short reflection on a handful of things I’ve noticed around me, a small note about fear. And if the vague fear you carry when you’re starting out curdles into helplessness, that’s no different from starting a race with a sandbag strapped to each ankle.
I’ll close, once more, with this post’s own intro.
Here’s my own take on the vague fear or misunderstanding people carry around “not majoring in CS” when they start out in development. The ‘CS knowledge’ I bring up along the way is something every developer needs to pick up eventually. What this post actually covers is when you learn it, and how you approach learning it, not whether CS knowledge matters in the first place.
