The curse of staying up to date with new technology

Keeping up to date is a major part of the job of a software developer and why we love it. Most developers are curious and love to tinker, so learning a new technology pushes all the right buttons.

Still, trying to absorb all the news from your source of choice, be it Twitter, Reddit or Hacker News can be a curse in itself. You’ll learn about all the new cool tools from browsing those sites, but on the other hand, the sheer amount of information to handle adds stress and confusion to your life. Are you really keeping up? Can anyone keep up?

Nobody really keeps up with everything, even if we wish we had time to learn it all. New technologies are created as you sleep: you have to give up some things or you’ll burn out from the frustration and overwhelm.

Nobody will come to tear apart your programmer’s card because you took a break from all the hype. You can’t hope to be a specialist in every little thing. Choose a few areas you would like to focus on and don’t worry too much about the rest. Loving to learn and wanting to grow doesn’t mean that you must be at the mercy of every new fad.

If you focus on the soft skill that really matters, like understanding the needs of your user and communicating with your team, technology is an implementation detail. You’re the one in control of what you’re coding, not Hacker News. Take the time to think for yourself about what’s best for your project instead of worrying about what the world thinks.

Core technologies such as CSS or HTML move surprisingly slow if you compare them to the neck-breaking pace at which JavaScript frameworks and libraries comes out. If you focus on what stays the same and on mastering the basics, you won’t be as vulnerable to change. True experts are not the ones that hurry to follow the latest trends: they blaze their own path.

The technology you choose when you got started on your current project is good enough for a while. You’re allowed to complete a project without migrating a library every two week because a new version came out. You need to focus on what’s really important: making software that works.

When you’re ready to catch up again, the world will still be there, and there will always be new fascinating skills to learn.

Embrace the limitations to complete projects

As makers and creatives, we hate it when bosses and clients put limits on what we can do when we build new software. We believe that we should be free to try anything we want with the code and the features, and that we would automatically build and innovative software that could rival Apple’s if only we had a bit more freedom.

Yet, somehow, it’s the project with deadlines and strict requirements at your day job that end up shipping, while your own unfinished side projects languish on a GitHub repository. The code of your side project is elegant, with 100% with a complete test suite and all the latest technologies. Unfortunately, nobody uses it while old legacy code you’re ashamed of keeps going!

It’s counterintuitive, but limitations are important and will teach you how to build software that works. A large project where everything is wide open and that has no clear deadline will often end up with you in the weeds, polishing a useless detail to perfection or upgrading just one last library.

My best learning experiences were at work with projects that HAD to ship: the stakes were higher and I had to get moving. I would learn the basics and then get started working immediately on the most important parts of the project. I could learn just in time what was required, without focusing for hours on theory or parts of the framework that were not very useful in the end.

Somehow, this is really hard to put in practice when we’re working on our own projects for the sake of learning. There’s always a better way to do things, or one last missing feature, and with nobody to stop us this can go on for a while.

If you’re working on a project by yourself and don’t see any progress, creating your own limitations can help you complete it. You don’t want to take on a project that never ends, so choose the technologies you’ll use and what features you’ll implement before getting started, keeping it small and simple. After this, put your head down and work on your first version, making sure you don’t let yourself be distracted by new shiny technologies that don’t add to your project.

Upgrades and new features can wait until you’re done, and you should welcome any occasions to reduce the scope of your application. Since you’re working on this alone, limitations are your friends and will help you reach your goals.

You can’t remember every detail, so stop trying

There are more details involved in writing an application that anyone can remember. You can’t hope to retain everything you’re told: it’s easy to slip and forget something important.

What can you do so you don’t feel overwhelmed when you’re sitting down alone at your computer? You don’t want to ask your clients or colleagues for help too often since they have their own tasks, and they’re not always available to answer. If you’re working on an existing feature you can always get an idea by looking at the code, but knowing what was done won’t help you figure out why it was done. Besides, if you’re working on a brand-new feature, you won’t have any code base to guide you.

What can you do in the future so you don’t put yourself in this situation again? You should take copious notes about the project when you get new information, using a pen and paper. Some people have the impression that they’re rude if they’re taking note instead of staring at the person who’s talking. You must stop worrying about this: it’s a lot more annoying to make people repeat because you didn’t bother to take a few seconds to jolt something down.

When you’re back at your desk and you start doubting your memory, you can pull your notes and validate if you were right. Seeing your notes will help you remember better what was discussed, even if your writing and diagrams are crappy. Taking notes on a laptop is not the same thing as writing on paper: the action of writing down what you wish to retain will help you, and chances are that you won’t even need your notes.

But, didn’t the Agile Manifesto say that any form of documentation was useless and evil? Can’t we just improve iteratively? It says that unnecessary or outdated documentation should be avoided, not that you should give up on writing things down. You can’t keep all this information in your head and hope to remember everything over the course of a large project. Having to remake a feature that took a few days or weeks to code just because you didn’t make sure to remember the information you received is an expensive mistake.

You will never be perfect: you will always have questions, and you’ll most likely need clarification about a few key points even if you listened perfectly. When you get to this point, you’ll now be ready to ask those questions without feeling dumb that you missed something obvious.