My four stages to learn new tech stuff
Tags: learning, careerbuilding, career
Published: 2019-10-07 04:29:45

---
title: My four stages to learn new tech stuff
published: true
tags: learning, career-building, career
canonical_url: 
cover_image: https://thepracticaldev.s3.amazonaws.com/i/mi7p8tznirk4fhkvtuf0.jpg
---

Over the last 15 years that I have been a professional software developer now, I learned more than 16 programming languages and several frameworks, database systems and other tools that helped me in my path to master software craftsmanship.

Some of that I learned because I needed it in a project for a client but some of these technologies I was just curious about. If you are a software developer you know how fast our world moves on to new technology to solve new types of problems with it.

So you need to get going with new tech fast and know how to learn efficiently. Here’s how I learn today, a play on four stages:

# Stage 1: syntax/terminology

![some JavaScript minified code]
(https://thepracticaldev.s3.amazonaws.com/i/mi7p8tznirk4fhkvtuf0.jpg)

The first thing you need to learn about a new programming language or tool is syntax and terminology. If you already know another language or tool you learned a certain way to solve problems in this language but now you have to look out how to solve similar problems in this new language and need to learn the concepts behind it.

To be honest, I learn syntax once and forget about it later anyway. I have to Google that stuff like A LOT. In my regards the best way to learn about it initially is to look out for Koans.

Koans are small exercises where you have to fix or write small parts of code and often they are backed by unit tests which you have to pass in order to move on to the next one. Have a look at [Laura Diane Hamilton](http://www.lauradhamilton.com/learn-a-new-programming-language-today-with-koans)’s comprehensive list of Koans for that.

Most tools come with documentation and contain a simple tutorial to accompany you taking your first steps with it. Eg. if your intend to learn Docker, there is a great example in the [official Docker documentation](https://docs.docker.com/get-started/).

Third-party docs may be very useful, too. When using Go, I always have to Google stuff like how to let goroutines communicate with another using channels and I always end up using [Go by example](https://gobyexample.com) which is another great example. A great list for other languages can be found at [Learn X in Y minutes](https://learnxinyminutes.com/).

But most of the time, I don’t set out to learn just the syntax of a new language. I wanna play around and explore. What helps me in this regard is [Code Wars](https://www.codewars.com). By solving small problems, it forces me to learn syntax and explore idiomatic ways to solve the problem efficiently.

# Stage 2: ecosystem

![the ecosystem](https://thepracticaldev.s3.amazonaws.com/i/w1jabhpvpntalo8lur4q.jpg)

> “If I have seen further it is by standing on the shoulders of Giants.” - Isaac Newton

So you know about syntax and terminology, but where to go next? Learning about the tooling and libraries of a new language or database system is very important (and exciting) IMO. No matter if you need logging, recording metrics or a client to connect to a specific database system there are (open source) libraries that you can build on and you need to know them if you want to build something useful with a new programming language.

Luckily there are so-called “[Awesome Lists](https://github.com/sindresorhus/awesome)” for that on GitHub that contain everything you need for every language you can imagine.

At this stage, I try to do something useful with it. That means I can use the tool I build or at least learn something from making it. More often than not I will throw that away afterwards. Don’t ever get too sentimental with code! After all you will write lot’s of it in your career and very few of it will get to production or stay there long.

So most of the time, I will just rewrite a Unix program in my new language. I have written `cat` in C, Go and Kotlin - `tail` in Python, PHP and Java and many more. I never use them of course but they were tools I know very well and wich are documented very well so I had a clearly defined goal to go for.

Apart from that I often try to solve problems I had solved in the past with another language and try to solve it again in a new language in a more simple way, which is a compelling task sometimes.

# Stage 3: best practices & experience

![an old wise man](https://thepracticaldev.s3.amazonaws.com/i/bdoqw9uqjg6d6q9xheoa.jpg)

When it comes to adopting a new language, syntax and libraries aren’t just enough to build stable and reliable software with it that is also maintainable and can be easily extended. You also need to gain experience with that new piece of technology.

Usually that means to run it in production, get caught up in problems and get to know how to fix them. But there is another, less harmful way to get that by learning from others and by learning about best practices upfront. This stage is all about the idiomatic way to use a language or system.

There are two main paths for me here: first, there is Google. You can find a lot of content on best practices in (official) documentation or blog posts which can help you discover best practices. And it helps a lot to hear talks at conferences where people are talking about their experience in using that technology.

# Stage 4: unlearn old concepts and habits

After learning a new tool or language, you shouldn’t forget to unlearn things, too. If you embrace and accept technical change (which I guess you do if you came here), you should also accept that you have to unlearn old habits, patterns and terminology at some point. After all in our industry, there is a lot of change going on all the time and at a very fast pace.

So to not get confused when learning about new tech and it’s terminology you should simply forget about old tech. An example: “table” must have had another meaning before there were relational database systems and people had to forget about that in the 1970s, when those RDBMS where new and cutting-edge technology.

That’s my four stages of learning. I don’t think this will be the last iteration of it, as I won’t stop learning and therefor evolving my learning process. I would also be very happy to hear about your learning process for inspiration.