You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!
Being a responsible speaker, I have started preparing my talk – A tour of the language landscape – for NDC Oslo months ahead of time! When I first came up with the idea for this talk, I asked on Twitter if anyone else thought it was a good idea. Phil made a great point about including some information on how I go about learning a new language.
I came across this TEDx talk by Josh Kaufman a while back and found it useful in helping me formulate a learning strategy that works for me.
Truth about the 10,000 hours rule
In the talk, Josh debunked the often misquoted 10,000 hours rule. When the study was first published, the finding was that it takes 10,000 hours of deliberate practice to reach the top of an ultra-competitive field. But through a collective Chinese whisper the message was warped into ‘it takes 10,000 hours of deliberate practice to be good at something’.
Instead, Josh found that researches suggest 20 hours is all it takes for you to be reasonably good at something so long you make those hours count.
This is important, because for us busy programmers – who, by the way, have a tendency to work long hours – the time to learn new skills is both limited and necessary given how fast our industry moves.
4 steps to learn
Josh proposed these 4 steps to learning anything.
Deconstruct the skill
Most things we consider as skills are actually bundles of skills. The more we are able to break them up into smaller skills the better we can decide which of them actually helps us achieve what we want out of our learning. We can then prioritise the skills that are most useful to us and improve our ability in the least time possible.
For learning a programming language, you can deconstruct most languages into smaller chunks:
- variable assignment
- common data types
- control flows (if-else, loops, recursions, etc.)
- working with collection types
- working with strings
- error handling
Most introductory books and tutorials follow this structure already.
Learn enough to self-correct
You should first focus on getting to the point where you can self-correct and self-edit as you learn. For learning a programming language, I interpret this point as:
- know how to compile and run your code
- able to put simple programs together, and tweak it to start getting a ‘feel’ of it
Again, most introductory books and tutorials follow this pattern already and have you build a Hello World example very early on.
Remove practice barriers
Remove distractions – TV, internet, twitter, etc. – so that you can focus on learning. This can be hard when distractions are all around us and so readily available!
I once heard a story about John Carmack that, before a new project, he’d check in to a hotel with a bunch of good books and literally cut himself off from the outside world for days so he can soak up the ideas and inspirations before starting any work on the project.
I’m not saying that you should do the same, obviously different approaches work for different people. Personally I’m most effective between the hours of 10PM and 2AM because my wife goes to bed early and I’m able to just zone out.
I’m not a heavy Twitter user, or any other social network for that matter, so they’re not a problem for me.
On the other hand, comic-based TV shows is my poison – The Flash, Gotham, Arrow, Agents of SHIELD, etc. To limit the amount of disruption these bring, I binge watch them in one night so I can have the rest of the nights that week for more constructive uses.
Practice at least 20 hours
Josh raised a good point that, for most things you learn, there is a frustration barrier – the moment when we become consciously incompetent and realise how little we know and how much more we need to learn.
It’s not a great feeling as no one likes to feel stupid, and this is often the point where we lose our momentum and derail our hard-earned progress.
Which is why it’s important that we pre-commit at least 20 hours of our time, so that if and when we hit this frustration point we have a good reason to push on since we already budgeted 20 hours anyway.
Set your goal
Before you start investing a minimum of 20 hours into learning a new language, it helps if you could decide what you want to get out of the process. Depending on your situation and needs this could be quite different, e.g.
- are you looking to move to a different language stack and trying to make yourself employable?
- are you trying to understand the hype around a new language and see what it’s all about?
Personally, most of my learning is aimed at expanding my horizon and allowing me to see beyond the possibilities and options I have at my disposal with the stack that I work with day-to-day.
Other times I might have specific goals of what I want to be able to do in that new language, for instance:
- I learnt Elm to be better acquainted with functional-reactive programming (FRP) and with the aim of being able to make games using FRP
Prioritise learning a new paradigm
One mistake that I see many people make is to choose to learn a new language over a new paradigm. For example, making the jump from C# to Java is a relative easy one, but at the end of day you have learnt a new syntax without necessarily taught yourself a new way to solve problems.
Learning a new paradigm on the other hand, fundamentally change the way you see programming and allow you to see new ways to solve problems. From personal experience, each time I ventured into a new paradigm – Functional Programming, Aspect-Oriented Programming, Functional Reactive Programming, etc. – has allowed me to see programming in a new light.
If you’re interested in exploring some less travelled roads, check out these three paradigms recommended by John Croisant.
And finally, I leave you with a great quote from none other than Alan Perlis.
A language that doesn’t affect the way you think about programming, is not worth knowing.
– Alan Perlis
- Don’t learn a syntax, learn to change the way you think
- TEDx – the first 20 hours – how to learn anything | Josh Kaufman
- 3 mind-blowing paradigms from StrangeLoop
- Evan Czaplicki on different kinds of FRP at StrangeLoop 14
- 4 stages of competence
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.
Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!
Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!
Are you working with Serverless and looking for expert training to level-up your skills? Or are you looking for a solid foundation to start from? Look no further, register for my Production-Ready Serverless workshop to learn how to build production-grade Serverless applications!
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are wrong about serverless and vendor lock-in
- You are thinking about serverless costs all wrong
- Just how expensive is the full AWS SDK?
- Many faced threats to Serverless security
- We can do better than percentile latencies
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong
- Top 10 Serverless framework best practices