Introduction
Learning new things, and then making effective use of that new knowledge, is key to our work as technologists! I used to haphazardly learn new things: either what was demanded of me from work, or just digging in on stuff I found interesting. Then I became a parent, and my free time went out the window! No longer could I just stay late at work, bail on friends, or pull an all-nighter to catch up. So, I married a few concepts from some really great books on reading, learning, problem solving, and habits. None of this is ground breaking, but sometimes hearing things in someone else's package and then going from there is what people need to make progress. It worked for me, maybe it can work for you!
Reading
How To Read A Book is probably my favorite non-fiction book. It's written with such a clarity and directness that I truly appreciate (probably a product of coming out of the 1940s), and really goes deep on a matter that many of us take for granted. Some of you may be thinking: How To Read a Book? Uhh, just read! Seriously, give it some consideration.
The author details four levels of reading (each step leverages/consumes the previous step as part of its approach):
- Basic Reading - What we all already mostly do, start to finish, plodding along.
- Inspectional Reading - Scan the structure of the book - table of contents, index, references, etc- and skim the points of interest in a targeted fashion. Start thinking of what questions you'd ask the author if it were a live conversation.
- Analytical Reading - Now you're fully in conversation mode with the author. Writing detailed notes as you go of each section, answering your questions. Fully dissecting the book to its core. This is an active activity, not a spectator sport. Really consider the author, their biases and background, and whether you agree or disagree.
- Syntopical Reading - The final stage of reading. This is where you are effectively applying a bit of a Breadth-First Search to your personal research. This method means selecting multiple sources/books on the topic and comparing/contrasting their approaches, usually storing your combined and synthesized notes in a master notebook or commonplace book. Sometimes we need multiple takes on a topic before it cements. A modern-day interpretation of this would be reading a book's chapter on something, next a blog post, and then cross-referencing those with WikiPedia, YouTube, or Khan Academy.
Some steps in this may be "common sense" for you, but the deliberate and formalized approach will yield you more consistent results than if you do some steps of this inherently.
A final note on reading and books: don't fall victim to the cost aversion of not reading an entire book cover-to-cover that you buy. A book is like taking a calculated bet on your life. You could read one thing in one chapter that changes your life or opens your mind in a way that is way more fruitful than the 10-20 bucks you spent on it. I've noticed that myself, and many peers in computing over the years, will give blog posts more leeway than books. Treat each chapter in book (or even subsection) as a more formalized, more rigidly constructed blog post, and take what you need.
Learning
Ok, cool. You extracted a bunch of data from a source, or sources, that spoke to you. Now you have to make it stick! Spaced repetition is the key here. Regularly test your knowledge via recall. Make sure you can explain it to someone else, ala the Feynman Technique (if you can't explain it to someone in basic terms, you don't know it well enough yet).
A Mind For Numbers, or it's companion course on Coursera, Learning To Learn are great at cementing this approach. As you continually test and recall, the concepts will cement themselves.
For applications to programming, this is where you want to write your test applications or clone applications mimicking the features you've learnt. Next-level would be a side project you're passionate about that leverages the newly-discovered concepts. For things that a little more esoteric, you can setup an Anki/Flash card deck to drill the high level concepts while also writing the code for a practical implementation.
Problem Solving
The best book on this, IMO, is G. Polya's How To Solve It. It's another classic, and it's the template for how to approach a problem in a very structured manner. It's very similar to applying the Scientific Method to problem solving.
The basic gist of the Polya approach is:
- Understand the Problem - know it fully and deeply. Restate it to others. Drill down until you have zero ambiguity in what you're trying to accomplish.
- Devise a Plan - Polya suggests many different ways to distill a problem down to a simpler problem, consider special cases, draw diagrams, etc. There's also an encyclopedia of problem solving strategies that follow after the problem solving template is detailed in the beginning of the book.
- Follow the Plan - pretty straight-forward, stick to your plan, and be deliberate
- Reflect on the plan - look back at what you did and note what worked and what didn't. If the problem still isn't solved, consider if you fully understood it or if you need to devise a new plan.
Habits
One of the quotes in Refactoring that I really liked was "I'm not trying to be a great programmer. I'm trying to be a good programmer with great habits".
It's hard to be consistently great...and the reality is that many of us aren't going to be naturally great with little effort...but if we can build our habits such that doing things well becomes second nature, then the compounding effect of your habits over time will mean you're a solid, reliable, and effective software engineer wherever you work. A great book on habits that I geeked out over big-time was Atomic Habits. The author does a fantastic job of distilling the little changes you can make in your life and approach to thinks that are easy to implement and really start to compound. I can't recommend it enough!
Conclusion
So, maybe many of you already do some (or all) of the things I mentioned automatically as part of your implicit process. If you do, that's great! For me, I really had to formalize explicitly a way to execute learning new stuff as quickly as I could due to my outside responsibilities growing so much as a new parent. This template/approach should work for anyone who wants to get the most out of their time and get back to writing code and solving cool problems. Hope it helps!
Top comments (0)