My first two weeks flew by. Lessons learnt. I think…
Almost a conversation with myself.
Luckily really early in my life, my dad drilled one simple idea into my little thick skull:
It’s ok to not know, as long as you are willing to learn what you don’t know.
Get used to not knowing. My first weeks where less stressful than they could’ve been, just because I had the above quote running through my head.
The only way to gain competence in the field of reducing competence is to get accustomed to a concept of ‘Just-in-time learning.’
An Outline.
Originally I wanted to post weekly, but unfortunately unpacking is far more time-consuming than you could ever imagine, as indeed, is everything. Although this is one of the lessons of the past two weeks. Everything takes longer than originally anticipated. No exclusions!
The article below will probably read better as a collection of statements and some little further explanation. Please note that whatever is said confidently at this moment might completely change later as and when I’m getting proved wrong.
There are really two big major learning topics intertwining this week:
- Learning Technology
- Learning Learning.
Initially Pete (our Principal Dev and my mentor) and I sat in a meeting and made a short outline of the things I need to do.
First two weeks were dedicated to learn the basics of React and the next week will mark the start of C#.
What isn’t used is lost, or how to learn and not forget.
Having worked as a teacher I learned one thing. If a student is ever to succeed in whatever they learn, they have two options: be a prodigy (rare) or nail learning itself. Yes, learning learning is a thing. I intentionally use it tautologically, as it seems super clear and simple to me, when is put this way.
The best way to learn is to try to stay mindful about the learning material, even when you’re not getting it. Focus, do what helps you concentrate and if you notice a minute later that an hour disappeared and you’ve done something — well, you know the recipe, just reproduce it.
When you start learning, outline initially the goal of you learning. Learning for learning is past time, learning for application is a tangible objective. The metric you can use to measure effectiveness of your learning, is how quickly and effectively the knowledge you’ve acquired can be implemented in your target project.
This is the workflow I found effective.
Observe → Imitate/Recreate → Embrace → Rethink → Create → Repeat.
How hard should it be?
Surely you can ask me: “But Michael, this is all good, but sometimes I just don’t get it. So how much should I struggle before moving onto something new, whether it is a technology or a learning material? You know, I just don’t have an eternity. I need to get things done!”
Well, I’ll try to answer quickly and then expand below. With technology, it’s all about finding a suitable abstraction. A lot of physics laws and definitions are really convoluted and formalised and when you get used to them you appreciate how succinct and elegant they are, but for beginners it’s just dross.
Just compare these two:
a) The acceleration of an object as produced by a net force is directly proportional to the magnitude of the net force, in the same direction as the net force, and inversely proportional to the mass of the object.
b) The harder you push things, the faster they go.
You may have recognised Newton’s Second Law in the first definition. And the second is its very simplified abstraction.
Yeah, sure, I hear you, the second definition is missing out a lot. But which is easier to understand for a beginner? Which would a suitable learning step?
The metric you can use to measure effectiveness of your learning, is how quickly and effectively the knowledge you’ve acquired can be implemented in your target project.
On when to move on:
The answer is very individual. Keep a diary of materials you’ve studied with. Review it weekly and think about effectiveness, using the metrics I wrote about above. Generally don’t really trust yourself. Believe in your abilities, but don’t trust yourself. I love Richard Feynman’s quote on the subject:
“The first principle is that you must not fool yourself — and you are the easiest person to fool.”
On asking for help:
Don’t ask for help or explain your problem in a generic way, unless people aren’t interested in helping you. “I have a problem understanding React” and “I have a problem with identifying appropriately levelled learning materials for React” are two different propositions, despite us using the first when we actually mean the latter. People usually are very willing to help, but a generic question can only get you so far. Try to tackle some problems and then when asked tell what you’re struggling with. Now you have a clear problem, and more experienced people tell you ways to overcome them. The most useful problems aren’t the ones with a clear answer, it’s the problems which require approaches rather than answers. Problem A — solution B isn’t that useful in the long run, the most beneficial is Problem A — approach B, results in solutions C, D, E.
Oh, almost forgot. Keep an open mind and try to avoid assumptions.
Learning Technology.
Yes, and when you go further down the individual technology, it doesn’t get any better! Just go checkout the React topics on Quora.
Daily breakdown of used resources:
Quick overview:
- Team Treehouse — once gone through hands-on coding, get your teeth into a little project alongside someone experienced.
- Pluralsight — get yourself to a professional level.
- Code School — good for getting the gist of what’s coming.
- Facebook guide — whenever in doubt, just go there for a healthy dose of creator’s wisdom.
- Codecademy — good for reinforcing basic ideas and syntax
Sometimes you just need to chill and see where the flow would take you.
Have you had some experience with React or you are studying it at the moment? Feel free to suggest your favourite learning materials and courses. 🙇📖💻👩🏻🎓
For quick daily snippets of my journey, you can always check out me on Twitter: Michael Rybintsev with #jundevdiary.
