How We Learn

Graduating with a degree or training certificate last year comes with a certain level of obsolescence in your knowledge capital this year. Being a developer, you must stay current with the technologies of today and those of your workplace. That could mean knowing the latest vulnerabilities in a stack, the newest efficiencies in a programming solution, or the experimental 0.X frameworks that could someday take over everything you currently know.

Being the non-complacent individuals we are, community members at #TechMasters grow and share our resources together on a daily basis. Every week we discuss topics related to our industry, and this week we contributed techniques and ideas to improve how we learn.

Definitely not like watching paint dry

Learning by Doing

The most common learning techniques discussed were hands-on. I can attest my personal understanding of a programming language would be nothing without the prototypes I created and challenges I solved.

I learn new stuff by:

1) Saying I can do it
2) Building a project in it.

I find it is a lot easier to explore a technology by using it to explore a problem.
— Alex Flanagan

Here, Alex suggests exploring a problem as motivation for mastering a new skill. Rather than following blog posts or videos with arbitrary or abstract examples — especially those that use foo and bar examples — try building a small application that can run on its own or with as few dependencies as possible. This way, you can swiftly realise what the technology or framework is and isn’t capable of. Better yet, it’s straightforward to iterate and expand on a small project once a clear goal is established in the beginning.

Paired Programming

Pair programming is my favorite way to learn.
— Oren

It’s also my favorite unofficial eSport. I should really start something with this as an avenue for edutainment. For the uninitiated: paired programming is a development process that involves two developers; one writing code, and the other assisting with planning, implementation, documentation, and various problem-solving needs. The main advantage is to have two brains working on the same task with constant code reviews and quality assurance throughout the development process. However, from my observations it usually leads to opinion battles with repeated test-and-check runs, making both developers wrong until one of them is right. Hilarity often ensues during the cathartic moment when we all find out whose opinion was right or wrong all along.

Code Reviews

I took on a challenge to learn JavaScript by writing a line highlighting tool like Github’s for a large open source project. Getting my changes reviewed, accepted, and live was a really exceptionally good experience. One of the major things was being shown how the tests worked, and how every pull request had to have tests to go along with them.
— Jamon

Guided Tutorials

Websites such as codeacademy.com help me learn the basics of a standard language in under an hour. Their examples may not always be relevant, but is worth a try just to have an automatic trainer scrutinise your mistakes before moving on. Unfortunately, I find my knowledge retention lacking after these tutorials; so it is important to complement the lessons with personal challenges or projects.

Reading (and Writing) Documentation

This part should not be overlooked and is possibly the most important advice of all: read the documentation. I completely understand how it can be ignored due to time constraints, or that jumping into coding examples may be a more enjoyable learning process, but knowing the spec is crucial. Technical debt avoidance is a non-stop process that should live with your developments every step of the way, and proper documentation would do its best to lead us in the right direction.

Another thing that helps with learning is diagrams!! Can’t tell you the number of times I wish a developer would have a simple diagram/flow chart showing the connections between files/methods/classes, etc.
— Stephen Russett

Watching Videos / Screencasts

I love videos (I usually speed them up at least 1.5x) mostly because I have a tendency to skim written tutorials, and videos force me to not skip anything.
— Jasna

Videos drive me batty. I’d much rather have something written with screenshots.
— Angela

This one is a mixed bag. A few people mentioned their liking for videos for being thorough, but many others dislike videos for their general lack of charisma or engagement. I often say: there is no right way to do something, but there are millions of wrong ways.

To me, making an excellent video or screencast is an art. At the time of this writing, my favorite screencasts are those found on Google’s YouTube developer channels: Polycasts and DevBytes. These videos balance what seems to me as the right amount of code walkthrough, topic motivation, conversational dialogue with face time, nuances and gotchas, and forward-thinking statements to encourage further self-improvement. I find these qualities to be very engaging when timed well. I cannot always stare at a screen of code while listening to someone monotonously explain every line. There needs to be regular breaks— at least for me.

Reading Books

Books are not a popular medium; only a couple people still purchase and read programming books in our community. This is mainly due to online documentation and StackOverflow being much more accessible for fast answers.

There is a distinct pro/con scenario when learning from books: they can expose you to all parts of a language, which is a good thing. However, examples found in most books are hardly applicable to most scenarios, making it tough to reference when building your own small projects. Evidently, digital documentation is strongly favored over books since I can selectively search for the things I need fast.

Start with the Scope

I find understanding scoping rules might be the single most important thing to grasp when approaching a language. If you don’t understand its scoping and why it is that way, then you’re programming by cargo cult.
— Simon

Try Learning Something Philosophically Different

Personally when it comes to learning, I always try to maximize the amount and the rate of stuff I learn at the same time. I do this by following a couple of general principles:

1. I always stay in the grey zone between “ineffective” and “too comfortable”. When I get too comfortable with a stack or technology, I either swap out a piece of it with something else or I dig deeper into how it works (basically going one level lower). I cannot stand using a technology that I don’t understand how it works on the inside.

2. I keep my rate of learning high by introducing tools that are philosophically as different to what I’m using as possible. I’m not interested in learning Ruby as my next programming language, because I already know JS and Python, it’d be 95% stuff I already know, just wrapped in a different syntax. Instead I’m looking at either J or Idris.

2.1 After not too long, learning any new technology comes down to mapping the features and ideas it contains with the stuff you already know.. then maybe it’ll have a few unique concepts, but it’s usually a very minor part.

—Simon

Learning Through Teaching

If you take it seriously, teaching is a great way to learn anything — forces you to articulate things you tend to tell yourself you ‘understand’.
— Adam Worrall

Though there isn’t much evidence that institution-based learning is 100% effective, it’s worth trying to teach as long as you are empathetic and adaptive to your students’ goals and personalities.

I taught English abroad for one year, and I’m TEFL certified. As much as I’d like to say my training is transferable to the world of coding, I admit it was only useful to me about 20% of the time while teaching English. I tried to follow my training by the book, and it would often leave some of my students disengaged and lost. Obviously, there is a huge difference between teaching adults and children, so here are my personal takeaways:

1. Students of all ages have varying levels of knowledge retention and engagement. For example, I can be very engaged as a student, but cannot retain much information even after several repetitions. When teaching, don’t just repeat lessons; reapply them in different contexts such as speaking, listening, enacting, scheming, and group work.
2. In a classroom setting, it’s a good idea to experiment with 1-on-1 teaching, small group exercises, and independent learning. All of my students respond differently to each style on a per-subject basis, which can help expose their individualised learning styles.
3. Do not ask yes/no questions, especially “Do you understand?” Make them prove their knowledge by explaining or reapplying in their own way. Most of my students say, “Yes, I understand” because they’re too afraid to waste my time; a common misunderstanding for many students, and they may need regular reminders that the teacher’s time is for their benefit.
4. Randomly elicit knowledge from the learner. When your student demonstrates their understanding, it proves your effective teaching and your student’s net gains.
5. Give reviews of required knowledge before jumping into a new topic, and give quizzes during and after the new lesson.

Exactly how I used these techniques varied wildly in every situation. Though I’m confident with my suggestions above, I strongly advise experimenting and finding what works best for you. I have countless anecdotes, and there are likely millions of idiosyncrasies in teaching and learning.

Training/Instructional Design

Adam expanded on teaching with their experience in instructional design:

ERGA — experience, reflection, generalization, activity.
Give learners something they don’t understand, ask them questions about it (reflection), form some principles or concepts, try them out. Drawing their attention to the thing they don’t understand and then having them articulate the questions they have is important — then they get some answers and try it out to see if they have asked the right questions and gotten the right answers.

Objectives need to change scope based on how experienced people are; so if people come into a training scenario already competent in a given technology, you’re probably using higher-level verbs for your objectives like ‘debate’ or ‘justify’. [Yet], everything has a new component so even with experienced people you might need to set an objective like ‘list the different types of monads’.

The key thing is that knowing what behaviors everyone needs to be able to exhibit at every step of the way means that you never have to worry about losing someone.
— Adam Worrall

Great tips for anyone wanting to be a teacher or mentor! I will certainly take these into account as I learn and grow.

Picks

Here are some recommendations by our members that can help you learn something new:

The 40 Best Places to Learn Something New Every Day

reactjs/redux

Learn to code

10 Interview Questions Every JavaScript Developer Should Know

Chart — Bloom’s Taxonomy

Don’t Stop Learning

I’m interested in how you learn. Join the conversation at TechMasters.chat! We discuss something new every week and will feature a write-up like this one afterwards.

Technology Masters