The argument in brief
- The question
- How should a beginner learn when every topic seems to have endless depth?
- The claim
- Beginners get overwhelmed trying to understand the whole landscape at once. They learn better by breaking it into small pieces, building something simple, getting feedback and iterating. Confidence: A personal view from my own experience of learning and of working with junior developers. No studies cited.
- The evidence
- My own 25+ years of learning software development, which arrived in layers, one technology at a time.
- A tweet by Povilas Korop describing the same pattern in junior developers.
- No studies of how developers or other beginners learn.
- The best counter
- Some overview helps: without a rough map of the field, a beginner may not know which small piece to start with, or may master pieces that never connect.
- What would change my mind
- Evidence that beginners who start with a broad overview of a field progress faster than those who start by building one small thing.
- Open gaps
- 1 gap. Statements I haven't verified yet. Each is marked in the text.
The question: How should a beginner learn when every topic seems to have endless depth?As a software developer who started out by teaching myself C programming when I was 11 years old, I’ve seen things change quite fundamentally over the years.
Junior, mid and senior
One discussion that comes up time and time again is: what’s the difference between a junior software developer and a mid-level software developer? When hiring for roles, you really want to know what the difference is, and for the employees you do hire, ensure they have a clear pathway to progress.
However, it’s hard to articulate. At a simplistic level it usually goes along the lines of:
- A junior developer has the basic competence for programming, but needs to be mentored on how to do things. They will require a lot of support from other members of the team.
- A mid-level developer understands how things work and can implement solutions unassisted based on how things have been done before. They require minimal support from the team to help them deliver.
- A senior developer can help make things that haven’t been done before. They are pushing the forefront and often support the team in their deliverables.
As a senior software developer myself, it’s hard to remember what it’s like to be someone starting out. What should a junior developer need support with? How much responsibility can they be given without needing time from the rest of the team to support them?
For a junior developer, they want to progress, but they don’t get told exactly how to achieve it. It’s overwhelming and it’s frustrating for them.
Then I saw this tweet by Povilas Korop, and he articulated a point of view very well.
What I noticed about junior devs. They are overwhelmed by the question “How does it all work?!”
They see the sea of terms like “SPA”, “Full-Stack”, “Deployment” etc and they feel they need to understand the full picture of them from the beginning. Like a flow chart. And then they would choose what to learn, step-by-step.
As a result, they remain feeling stuck and don’t even start anything.
In reality, that’s not how it works.
You start with a small subset of that knowledge hill. Create a static HTML website. Then add CSS/JS. Then add PHP. Then Laravel. Then deploy it to server.
Of course it’s only one path, there are dozens of others, but my point is this.
Don’t get overwhelmed. Start with a smaller challenge but make it clear and achievable. Then the next one.
Ship something. Ask for feedback. Seek mentorship.
Then, piece by piece, that huge sea of terms from above will start to make sense to you.
And then you will realize you still don’t need to know it ALL. No one does.
Povilas Korop (@PovilasKorop), 7 May 2023
Layers of complexity
Being a junior developer in 2023 is very hard. There’s so much to learn. Where do you start? Each topic has an endless depth and feels like you’ll be stuck being a junior developer until the end of time.
An assumption: I am assuming that learning in layers, as the technology arrived, is part of why it felt manageable to me. I can’t separate that from simply having had more years to learn.Reflecting on how I managed to become a senior developer, it comes from 25+ years of learning. When I started, the technology was simpler. There were fewer books to learn from. You couldn’t really go down a rabbit hole as there wasn’t endless information, variations of technology, and multiple layers of abstraction.
First it was HTML, then JavaScript, then CSS, then libraries like jQuery and Bootstrap. Then it got interesting with Angular followed by React. Slowly build systems, linting, transpiling, unit testing frameworks and bundling came into the mix. On top of that the server landscape shifted to virtual servers, cloud hosting and now Docker and Kubernetes in virtual infrastructure environments. Piece by piece, the layering of complexity was added, year after year.
But to start out today, you jump right into the overly complex landscape. Everything is an abstraction of something else. Unverified: GraphQL is an evolution of REST, which is an abstraction of HTTP sitting on top of TCP/IP.Gap · needs evidence: This is a simplification I haven't checked against a source. REST is usually described as an architectural style rather than an abstraction of HTTP, and GraphQL as an alternative to REST rather than an evolution of it.
To be a junior developer, you are looking for clues for what to learn and what to experiment with. It’s overwhelming. You want to do everything, because you want to be good at everything, because that’s what you see with the mid and senior developers. They seem to “know” what’s what. Just one look at roadmap.sh and you’ll realise how deep the network of rabbit holes can go.
One thing at a time
A competing explanation: Some overview helps. Without a rough map of the field, a beginner may not know which small piece to start with, or may master pieces that never connect. A roadmap can be a trap or a guide, depending on how it’s used.So what do you do if you’re a junior in this trap? As Povilas says in his tweet, start small and build something that accomplishes something simple. Don’t try to build a thing with HTML + CSS + React + TypeScript + Storybook + Next.js + GraphQL + MongoDB + Docker + Kubernetes on your first go. Just build a simple HTML app with a sprinkle of JavaScript. Deploy it. Get feedback. Iterate. Take your time to do just one thing at a time.
And if programming isn’t the field you’re in, the same applies. Maybe you’re a videographer who wants to do sound design, visual effects, storytelling, editing, camera and lighting. Do one thing at a time.
If you’re a writer, focus on taking notes, storytelling, character development, prose and such. Don’t aim for a masterpiece until you’ve mastered the pieces.
The ah-ha moment
What would change my mind?: Evidence that beginners who start with a broad overview of a field progress faster than those who start by building one small thing.Today’s ah-ha moment is that if you’re a beginner it can be overwhelming to know how to learn what you need to learn. Claim, confidence:a personal view from my own experience; no studies cited: Break it down into small pieces that you can build upon. Learn and master those skills first. Iterate and get feedback. Take your time. Most importantly, love why you’re doing it and enjoy the process.
Don’t aim for a masterpiece until you’ve mastered the pieces.
Books behind this essay
Not sources for any claim here. These are books I have finished that shaped how I think about this question. Where I rely on evidence, it is cited in the text.
Mastery (opens audible.co.uk, external site)
Shaped how I think about the long, patient apprenticeship behind becoming good at a craft.
How We Learn (opens audible.co.uk, external site)
Shaped how I think about learning as something built up in pieces over time.
The Lifelong Learner (opens audible.co.uk, external site)
Shaped how I think about staying a learner long after the beginner stage.
Range (opens audible.co.uk, external site)
Shaped how I think about the value of breadth, which pulls against doing one thing at a time.
