“Self-taught developer” is a label that carries a lot of pride, and reasonably so - building enough skill to work professionally without a formal computer science education is a real accomplishment. The alternative path is harder in some ways, requires more initiative, and produces engineers who are often better at the practical craft of shipping software than their formally educated counterparts.

But the label is also slightly misleading, in a way that’s worth examining.

The comparison that makes it seem more meaningful than it is: trades like mechanics or electricians. A self-taught mechanic has genuinely done something unusual. The knowledge base for automotive repair is relatively stable - the principles of internal combustion engines haven’t changed fundamentally in decades. The certification path exists, is well-understood, and provides a clear credential. Someone who taught themselves outside of that path did something genuinely different.

Software is not like this.

The knowledge base for software development changes so fast that formal education can’t keep up with it. The frameworks that are standard today didn’t exist when many of your professors finished their PhDs. The languages, the tooling, the deployment infrastructure, the best practices - all of it turns over on a timescale of years. By the time a curriculum is designed, approved, taught, and graduated, significant parts of it are already dated.

This means that everyone in software is substantially self-taught, regardless of whether they have a degree. The degree gives you fundamentals - algorithms, data structures, systems thinking - that are genuinely durable. It doesn’t give you current practice, because current practice wasn’t current when the degree was designed.

The practical consequence is that the learning model in software is necessarily different from most fields.

In medicine or law, continuous professional development is real but the core body of knowledge is stable enough that what you learned in school applies for your whole career. You update at the margins; the fundamentals hold.

In software, what you learned five years ago is still useful, but you’re also learning new things constantly - because the field demands it, not because you’re unusually motivated. The engineer who stops learning gets left behind by the tooling faster than in almost any other technical field.

This is neither good nor bad. It’s just the nature of the field.

What this means for how you approach your own development:

The self-taught/ formally educated distinction matters less than the quality and consistency of how you keep learning. A CS graduate who stopped updating their knowledge in 2018 is in a worse position than a self-taught developer who builds things, reads broadly, and pays attention to how the field is evolving.

The durable skills - the ones that don’t rotate out - are worth investing in deeply. Systems thinking. Understanding tradeoffs. Knowing how to read and navigate a codebase you didn’t write. Communicating technical decisions to non-technical people. These don’t appear in tutorials because they don’t have syntax.

The current skills - the specific frameworks, languages, and tools - are worth knowing well but holding loosely. The framework you’re expert in today will be legacy software in ten years. The underlying understanding of why it was designed the way it was, and what problems it was solving, will still be useful.

The “self-taught” label sometimes carries a subtle anxiety, a need to prove that the absence of a formal credential doesn’t mean the absence of legitimacy. That anxiety is understandable and also unnecessary.

What the field actually cares about is whether you can build things, understand systems, collaborate with other engineers, and keep learning as things change. Credentials are a proxy for this. A good track record is the thing itself.

And in a field where everyone is continuously self-taught by necessity, the person who learned to do it deliberately and early has an advantage that formal education doesn’t confer.