My blog has never been much of a digital garden, but this is a topic I think about constantly and my approach is always evolving. So, to be clear, this post is a work in progress, probably forever. It's a rundown of my ideas about learning and teaching, some of them incomplete.
No one way
I want to start by saying that every individual is unique, and that means their approach to learning should be as well. Our expectations in this area are wildly outdated, and that extends to the tech industry.
In particular, I'm aware of the constant debate surrounding "fundamentals", a definition that no one can truly agree on. In fact, a definition that varies significantly depending on what stack you use.
No matter, let's suppose there was a solid definition. I still do not believe everyone should learn the fundamentals first. This is for a couple of different reasons.
Curiosity. Part of what makes learning effective when you aren't being paid to do it is that you're interested in the subject or invested in some other way. You should be able to tackle whatever interests you and figure out a way to accomplish those ends, whatever the means.
Pattern matchers and visual learners and everyone else I'm leaving out. I like to think of these people as tinkerers. They start with a working thing and break it down until they figure out what makes it tick. Give them the raw materials to make the machine in the first place? No dice.
Starting from scratch
The idea of a self taught developer is fascinating to me. We all agree that in order to be in this field you must constantly grow and evolve your skillset. However, how does that relate to the idea of being "self taught"?
For me, the moniker has never really worked for what it's trying to convey. We are all teaching ourselves. And whether that's with a friend, a video, a blog post, etc we aren't sitting in a classroom.
However, I believe self taught was created to describe an experience that's wholly different. How did you learn the concept of variable assignment? The idea that mathematical expressions and those in code are not the same.
const answer = 1// cannot be 1 = const answer
My answer? I learned it in a classroom. Which means I do not meet that definition of self taught. Though many of the other things I've learned in this industry have been by cobbling together various resources and grinding it out.
That does not devalue my experience or struggle in doing so. But it recognizes that learning to read code like the example above and make sense of the rules yourself is a very different challenge.
Learning a tech stack
I find docs fascinating because they're not one size fits all. And that goes beyond the question of how people learn. It gets to the very heart of "pre-requisites".
Let's take Gatsby as an example. Who is reading our docs and what questions should we ask about them?
- Are they new to programming?
- Are they new to JavaScript?
- Are they new to React?
- Are they familiar with Gatsby?
- Are they an advanced user?
- Do they want to get a job done?
- Do they want to understand the how and why?
This list could go on for a very long time. But it encapsulates the challenges of teaching. Understanding your audience is important, but there are also a number of potential audiences. How do you break things down so that you're covering as many of them as you can?
The art of Googling
We may joke about it, but effective googling is genuinely a part of being a successful senior developer. However, it's evidence of other things.
Googling an error
If you're going to find someone else with your error you'll want to include the information you see that matches what they see. What does that mean in practice? It means you understand the stack trace well enough to recognize what comes from your code (variable names, function names, line numbers, etc) versus what came from the underlying tool.
Blurred tech
If I'm working with a chunk of JSX code and I see an error the potential culprits are numerous. Is it JSX syntax? An HTML tag API issue? CSS-in-JS? Any number of other things?
With specs like CommonJS we have functions implemented by different technologies that have the same name - see Webpack vs. Node. A successful google search likely requires the ability to isolate the technology in play.
Familiarity
We argue about this a lot. What makes a senior engineer? In my mind we always gloss over an important piece of information. Regardless of your assessed skill level in the overall industry, the person with the most familiarity in a given codebase will always be the most senior engineer for that software.
Now, there are plenty of caveats to that, and I'm sure many people will point them out, but familiarity is important to talk about. It's a great confidence builder to know a codebase well! It's a genuine skill to be able to onboard and navigate a new codebase quickly - one not everyone has. However, even if that codebase is still teaching you things, there is a point of diminishing returns.
Flexing your learning muscles and getting out of your comfort zone is important. Seeing new patterns, new examples of failure and success, are all important to your growth as an engineer.
This is not to say you can't be a specialist. You can! But a specialist in a language, area of technology, or tool is different than a specialist who has only really dove into one project.
Quicksand
You can't always be learning. This feels like an absurd statement, especially for those who are breaking into the tech field, but it's true. And if you're breaking into the industry, there is likely some value in recognizing that.
You can always be building on the knowledge you already have. Continuing to understand a tool or language. That's effective, and further enforces the things you already know.
You can't, however, jump around ad nauseam to learn things with little to no shared foundation. You'll forget the things you learned before because you aren't reinforcing them beyond your original introduction to them. You'll get frustrated by constantly feeling like you're pushing a boulder up a hill. You won't be able to pull your disparate knowledge into a related whole.
Are there people for whom this is inaccurate? I'm sure there are. But I'd suspect there are a number of people who have been swayed by the twitter "you must learn lists" and jumped from one topic to the newest thing. This is unfortunate.
You are better off learning an old tech at some depth and using those patterns and knowledge to help you learn the "new" one. Than you are learning a number of things at a very shallow level. And recognize that "shallow" changes dramatically overtime.
To be continued...
Who knows what my next walk with a podcast may prompt. I suspect this stream of consciousness is not truly over.