15 Oct 2017
Constant learning is a necessity in software development, especially if you're a generalist by nature, or doing anything involving javascript. It's also a lot of fun. Here's how I do it.
I like to ship things. A learning project, like any other, should have a start and an end. If it's too big, it should be sliced into smaller pieces. A target might be "get production-capable with React and Redux", or "start writing modern well-structured CSS", or "do something, anything, with golang".
To learn, you must do. I define a project - an actual piece of working code - that will be complete by the time I've learned these skills. It's not necessarily a particularly useful piece of code (though it's nice to scratch an itch, and I have many, many "would-be-nice-to-have" tools on my backlog).
Unlike normal development, it doesn't necessarily need to be done in the most pragmatic way. Redux is massive overkill for a simple todo list, but it's still a good learning project.
I think about coding in unfamiliar domains in two speeds - "get it done" (write code that works, even if not fully understanding how it works), and "fully understand" (including right down to what the framework code is doing, and why). Production code could be either of those two, but learning code is always the latter.
Learning requires hard focus, much harder than executing. I block out a few hours and lock the door.
('Locking the door' might just mean turning off all notifications, or it might be an actual physical door. Either way it's important; even the fear that you could potentially be broken out of focus is enough that you won't generate it in the first place).
Unless the skill to be trained is right out at the cutting edge (which is possible), the learning process is a matter of absorbing knowledge, not creating it. This is study, not research. This means that the resulting skill won't be any better than the sources it was learned from.
I take some time to identify some data sources, and select a coherent set. I want multiple perspectives, but I don't generally want them to disagree much. At the 'master' level you learn all the ways of doing something and the reasons why - at the 'beginner' level you want one sensible way of doing it.
If possible, the sources are mainly text. Video is slow, even watched at 1.5x+.
It's nice to include at least one human being (if they're a subject-matter expert and available on low latency) in the data sources. Rapidly checking understanding can save time later.
A second output from the learning process, apart from the actual code, will be an article explaining what was learned. This is for two reasons:
To truly understand something, you must teach it. Nothing exposes gaps in your understanding like trying to explain something. Peer-review of the resulting article afterwards will also expose things you got wrong (or at least generate interesting discussions)
As a generalist swapping through many skillsets, there might be a long interval between the first time I use this and the second. The article allows for spaced repetition (via regular review), and rapid lookup (via nvAlt). There's no point in learning something if it doesn't stay learnt.
Learning is often a tree. To understand sample redux code you need to know arrow functions. To understand arrow functions you need to know the difference between ES6 and ES5. To be able to play with ES6, you need to be familiar with Babel ...
I've used both breadth-first and depth-first, and a mixture, to explore the tree - but either way, it's important not to get lost. If I encounter a concept I'm unfamiliar with, I'll make a note that looks like either:
EXPLORE: 'arrow functions'? Something to do with ES6.
or
SWITCHING to 'arrow functions'. RESUME: Redux sample code at http://example.com/....
Other useful things to keep track of:
"unanswered questions", since it's not always efficient to context-switch to answer them immediately.
"out of scope" - learning like this needs to be a laser, not a lamp. Prevent digressions by keeping track of what you've decided not to pursue (for now).
Target: "Structuring modern css"
Project: "Make gwynmorfey.com pretty, with maintainable css"
Time: 10:30am - 5:00pm today
Data sources: There's lots of out-of-date material. Filtering down to posts written in the last year seems to help. Some starting points:
https://zellwk.com/blog/css-architecture-1/ http://getbem.com/ https://abookapart.com/products/css3-for-web-designers https://smacss.com/
Output: