Be a Just in Time Learner, part I

Dear new developer,

There’s the concept of a JIT compiler. I was first introduced to it with the HotSpot Java compiler. The idea is that a compiler can look at code and find the code that executes often and optimize it, sometimes compiling it down to faster code, sometimes unrolling loops. I’m no compiler expert or even intermediate, but the results speak for themselves. JIT has spread elsewhere (python, ruby, javascript).

As a new developer, you should be a just in time learner. Just like the compiler watches to see what is used often and then optimizes the code that runs fast and often, you should do the same. That’s why I recommended you learn version control and a text editor. These are tools that, as a software developer, you spend a lot of time in. So learning them well will save you time in the long run.

But what about the intricacies of a language or framework. That’s important too. But it depends on how often you predict the issue will come up.

Here’s a great chart from XKCD.

If you spend two hours remembering how to do something but you only do it yearly, and you learn it well enough to do it in one hour, you save five hours over five years. Does this make a lot of sense?

So, basically, I’m saying optimize for the things you do often. Another way you can do that is to make what you learn do double duty:

  • When you learn SQL you learn a way to query across multiple different databases.
  • When you learn javascript, you are learning a language that you can use on the front end (in the browser) and the back end (on the server).
  • When you learn vi keystrokes, you can use them to edit a text file in a terminal on any unix machine, on the command line to navigate your history and directory structures, and in eclipse or visual studio.



Learn a text editor

Dear new developer,

As I mentioned before, the raw “stuff” of software is primarily text files. Actually, the foundation of software is ideas and information, but unfortunately a computer can’t yet run on those. So you will need to create text files.

Learning a text editor will serve you well in building software.

Why a text editor rather than an IDE? (An IDE combines a text editor with other tools that help development, including tools that help testing and tools that help debugging. It stands for “Integrated Development Environment”.) Text editors can be used for any language, whereas IDEs tend to focus on one or a few. Text editors can be run almost anywhere, whereas IDEs can only be run on your local system. And using a text editor will force you to become more familiar with the command line.

For those reasons, it’s better to become familiar with a text editor. There are many options, but two really good ones, with long lineage and a large amount of functionality, are vi and emacs. But there are plenty of good options. (Most text editors have extensions that help with certain aspects of development, and it’s worth spending some time research and installing them.)

What if you learn the wrong one? “What if I learn the wrong xxx?” is a question you’ll face many many times as a developer. Since you don’t know the future, you’re always gambling when you invest your time to learn anything. But every time you learn one thing (in this case, a text editor), you have more context and understanding about that “thing”. This knowledge makes it easier to pick up the next text editor, map its functionality to what you previously worked with, and get going more quickly. You also learn the jargon around the technology, which makes it far easier to use Google or some other search engine.

Text editors are easy to learn, but difficult to master. It is often easy to open a file, write something and save the file. But to be able to easily navigate between files, move around a file, or do a mass search and replace, you’re going to have to put in some effort.

But there is no better way to convert thoughts into files.