How do I keep up with technology?

JavaScript ecosystem is crazy! New libraries, frameworks and even languages that compile to JavaScript pop up every now and then. Browser environment is omnipresent and the forgiving nature of JavaScript/HTML/CSS allows anyone to get their feet wet before jumping into the pool.

There are a bunch of really great programmers that I like to follow. Their contribution is absolutely amazing. Then there’s a herd of programmers who follow the latest tech and their most important skill is to learn and digest a huge amount of technical knowledge in a short time. These are the “knowledge workers”. In this post I want to write about how it feels to be one of these dudes.

0. Discovery

I usually monitor a few portals to read news:

• EchoJS is like Hackernews but with a focus on front end: a great place to find about the latest and greatest tech
• Update: Mailing lists: I’ve subscribed to a few mailing lists thanks to one of my good developer friends. He also gave me a top tip how to use them (otherwise I’d be very stressed): make a gmail filter for all these mailing lists and browse them for half an hour before you sleep. JavaScript Weekly, Node Weekly, WebOps Weekly, Frontend Focus, ES.next News, JSter, and Mozilla Developer Newsletter. I’m also subscribed to hackernews weekly and slashdot but they are not specifically front-end related and are more geek-friendly-news.
• Podcasts: JavaScript jabber is a great podcast that hosted many front end celebrities: a great place to learn about established tech from their creators. I’m particularly curious to learn about technologies that have influenced these smart people to do their great works. I work with security-sensitive web apps so I listen to security now and smashing security as well. If you’re into CSS, I recommend ShopTalk show, though I haven’t been listening to them lately since my focus is more shifting towards backend. Node up is also a great podcast that focuses on Node.js ecosystem: it shares many topics with the above podcast
• Twitter is a great place to get in touch with many influential devs. I have my own list of Node/Front end influential people on Twitter which you can subscribe there if you want.
• Medium! It’s awesome. You’re reading it right now but many people who have something to say or share their thoughts are here. I don’t have a list here but typically those twitter people are here too. My personal favorite at the moment are Victor Savkin and Dan Abramov.
• YouTube: my lifestyle (being a dad and all) doesn’t give me so much video time but when I get the chance, I really enjoy watching presentations from top frontend conferences like JS Conf EU, Google Chrome Developers and a few others. Once upon a time I used video courses too, but that’s not my thing. I personally have more performance when I read a book or blog series but people learn differently.
• Google: last but not least, I learned the biggest part of what I know through googling. I love StackOverflow and when I have time I try to give back (though my score has been just 5K for a long while).

On top of that, I get daily digests of Slashdot and weekly InfoQ. If you know of any important discovery channel, please let me know in a comment.

1. Picking a technology

There’s a bunch of new technologies and boy if you like playing, there’s more than one can handle in a lifetime! JavaScript has a healthy and active community which constantly pushes the limits of what is possible with the browsers.

Between a full time job and a family I don’t have much time to waste so I have to be very picky about how I spend my time. So here is my criteria for picking a technology to learn:

• Can it greatly improve/simplify the projects I’m already working with?
  Example: in my previous job we worked with Angular 1. So I followed the work on Angular 2 and relevant work like Aurelia
• Is it an influential technology that is going to reinvent the industry?
  Example: Backbone, Coffeescript, Clojure, Typescript, Elm, Redux, Polymer, React, Angular. Even if you don’t use them, they are influencing the industry and if you know them you can better understand the trends. This also empowers you to have better arguments when having technical/architectural discussions
• Is it out of my comfort zone but relevant?
  Example: I used to work at a company that used C#. So I took some time to learn C# because even though I worked as a front end engineer, it enabled me to understand back end devs and have a common language. Besides if something was broken I could fix it and I didn’t have to ask stupid questions about how things work.

Again: I don’t have the luxury to learn everything that is new to the market but what I pick, has a direct feasible impact on the quality/efficiency of my work, joy and salary.

Just as it is important to learn something new, it is important to define what NOT TO learn.

At the moment JavaScript is one of the most popular programming languages on the planet. Thanks to its open standards, ubiquitous environment and strong tooling like Node & NPM people flock to JavaScript from all trades. And they bring a lot of baggage and new ideas to this ecosystem. Github is full of new ideas and a quick search on the internet reveals hundreds (if not thousands) of these gems. BUT, just like any other human you have a limited amount of time and attention (no matter how smart you are, it’s limited). So it is extremely important to decide what you are not going to learn. Don’t worry, in a market of humans, this is not going to hurt your employ-ability!

2. Browsing

When I pick a technology to learn, I focus on that. For example if I’m learning React, I don’t jump on Redux or Flux. This is important because let’s say I have 2 hours to learn something, If I spread those hours on several topics and learn them in parallel, it’ll take much longer before I can be productive. Besides context-switching from one topic to another takes energy and time.

I quickly start by looking at the intro to see what this thing is about. Then I take a look at the docs to understand the structure. I may read a lot of stuff I don’t understand but the point is to know what information is available and where can I find them while I’m coding. During this phase I google a lot. For example if BaconJS talks about FRP then I’ll look it up. I may skim through the code examples to see if the API is intuitive enough to understand. For some technologies like Elm it can be quite tricky but then it takes more time to learn a whole new language. But I don’t waste too much time reading docs. I’m a hands on learner.

3. Learning & Using

Different people learn differently. It’s very important to know what works best for you. For example, many developers like video tutorials like egghead.io but for me, textual content and opinionated blogs work much better. Also my peak learning time is in the morning around 7–10 and in the evening around 17–19. For me silence is important, so I prefer to do the learning at home. If I’m at work I book a meeting room (we work at an open office) and if no meeting room is available I use one of the best gadgets in the world: Bose QuietComfort — an active noise cancelling headphone that actually works!

One of the most important secrets of a knowledge worker is to focus and draw a line on what not to learn. Due to the linked nature of the web it is very easy to end up in something relevant but not important for the task in hand. For example, you want to learn Elm, but with a couple of links you end up with a book about Category Theory. The truth is: in the information age, it is simply impossible for a human being to digest a huge amount of information and remember that. So what you do is to smartly choose a path that can quickly produce some tangible results for you. I may write more about this topic later since it is the key to be a successful knowledge worker and an area that I personally have struggled with the most.

Most decent technologies have websites with great documentation and examples. Most of the times I do the examples myself and try to type stuff right after reading an example. I try not to copy/paste because when I miss a character, my brain learns to be careful with it next time. Also setting up the initial tooling is something that I want to do myself.

After each example works, I try to modify it and see how it works. Some technologies are quite complicated so even if you change it a bit, it’ll crash. For these occasions I proceed more with the documentation to see if I can make it work quickly. Nevertheless I don’t get stuck in the examples. I don’t use advanced techniques like time-boxing and pomodoro but if I feel it’s taking too long and I’m not learning with a good pace, I’ll skip struggling with the examples.

When I learn a library or framework I try to use it to re-implement something that I have done before. For example when I learned the Swish programming language, I tried to re-implement my Sudoku algorithm from JavaScript. In this phase I try to be fluent (use the idioms from the new language/library) instead of literally translating everything from my old solutions to the new one. After all, that’s the point of a new tool right? ;-)

An important thing to note is to be prepared to unlearn what you already know. If you’re like me and have been programming for more than 10 years, there’s a good chance you’ve worked with other languages and run-time environments. Even JavaScript has changed in the past few years thanks to ES6 and all the money and effort Google & Apple (and lately Microsoft) put into competing with each other in the browser market. Don’t let your past learning stop you from learning new things. It’s a simple trap because when we learn new things, the brain tries to associate them with familiar things (i.e. stuff you already know) and when the new concepts are too different or in contradiction with what you already know, this may lead to frustration. For example, I used to work with C on small embedded systems where performance and memory was extremely important. That made me very suspicious to adopt JavaScript with its garbage collection and closures. In recent history, as an Knockout/Angular developer I was hesitant to adopt React with its JSX syntax because in all my web projects I kept the templates separate from code but React introduced the concept of keeping concerns separate from each other. In both cases when I overcame my hesitation (or fear or hatred, if you will) I realized that the new tech was actually very awesome and I should have been open to it from the start. But it’s not easy to unlearn what we already know. It’s good to be aware of it next time you really hate a dumb new technology that everyone is adopting and you just don’t get it! ;-) That is one reason why that young kid with half of your experience (read “baggage”) joins the company and does magic with higher quality, faster delivery and cheaper than the old “seniors” — because he doesn’t have much to “unlearn”.

4. Contributing

Sometimes I really enjoy working with a technology that I set aside some extra time to solve a real problem. This usually happens a few days after I think I’ve learned enough. For example when Cordova was new, I started playing with it but I ended up making an app and putting on on Google Play Store for free. I also made a couple of Chrome extensions when I was learning to work on the Chrome platform. Internet has helped me a lot in many aspects of my life, so I’d love to give back if I have something of value. I also try to answer questions on Stackoverflow.

1-Click timer for example has taken something around one months of full time work to develop but I gave it away for free and resist the occasional offers from marketers who want to buy it and inject tracking code in it. For me it’s a fun project to learn new tech. Of course I don’t have time to maintain it to be the way I want it to be but hey, it’s free! ;-)

There was a time when you had to shake hands with big publishers or media houses to spread your ideas. Today, thanks to blogs and self publishing platforms everyone who has something worthy to say can speak up and the crowd will be the judge of that with their likes, shares and follows.

Github and other open source platforms has created the same opportunity for speaking up your code. It’s an amazing era to be living in. For example, I’m not a super hard core ninja programmer, but still I had a chance to solve a problem that some people find interesting.

Once I was at a job interview and they said “we’re impressed by your skills” because we already use your library. :-D

I personally spend the bigger part of the day working on closed source proprietary projects. My Github profile looks empty. But whenever I do something on my private time, I’ll always share the code there.

5. Repeat!

When I was working with Java, I could take a long rest after learning a new technology (or dig deeper in it). I’m not saying that the Java ecosystem was static or immature. But in the JavaScript world there are just too many ways to implement something. True pluralism! For example in order to do GUI in Java I learned Swing and that was it. But in JS world you need to know at least Angular and React to be able to make a decent choice (I happen to know Knockout and good’ol jQuery way of doing things as well as RiotJS and a couple more). Then it comes CSS. I know SASS, LESS and Stylus equally well but new attributes are coming to CSS all the time (not bragging. I’m just saying this is what happens to you when you work on a bunch of web projects in the past couple of years).

That brings me to the last point: the steps above need to be repeated again and again. There is no stop! And so is the life of a web developer (or any decent developer who wants to be in the market for a long time).

Haters are gonna hate, but in nature, the creatures that adapt survive.

We’re in an era when the pace of innovation is accelerating and we have to cope with that. I don’t know how faster this thing can get but for now, we’re holding tight!

When?

Many workplaces realize the challenges of a knowledge worker and give some extra time to the programmers to sharpen their sword by learning new stuff. These are typically niche consultancy companies. But I’ve been at two companies where 20% of your paid time is yours for self-learning or personal projects. This improves employee engagement but also the company wins because its employees have a deeper and broader knowledge and can bring other top talent into the company.

If you don’t work in such cool places but have an ambition to learn, you may have to spend your personal time on it but on the long run this can affect your social life and happiness. Nevertheless, I personally spend an average of 1 hour per day learning stuff on my personal time. Our work has occasional hack days where I can team up with others and do something cool but continuous learning is something that demands more discipline.

If you ❤ what you read, please share it. Also head over to Sindre Sorhus’s AMA to get some insights about how he’s so productive.

⚡️Liked what you read? Follow me to be notified when I write something new.

On another note, ready why programming is the best job ever.