Let’s talk about physical tools for a moment. If you are a handyman and you need to drive a nail into a wall, there is a number of ways you could do that. You could try to drive it in with your fist or your shoes or even a stick. But there is also a tool that was build for the job of driving nails into wall: A hammer.
Now, there are different types of hammers. Wooden ones, ones made of steel, some may be magnetised and I am sure there is a whole list of other kinds of hammers that I don’t even know about. If you want to drive a nail in the wall, you will probably choose a hammer that is of a strong enough material and it will then allow you to accomplish your task.
It will probably not matter for about 95% of the cases which exact material the hammer is made of, which special features it has, which brand it was produced by and how expensive it was. It will get the job done and is therefor a good tool for the job.
Let’s now switch the topic to software development. There are also some tools that are made to help you perform certain tasks in this area. When you want to write code, you will need a text editor of some kind. If you want to execute programs, you will most likely need a terminal emulator and a shell. As with hammers, there are a lot of editors, terminal emulators and shells out there. I probably have tried too many of them.
Since starting university 7 years ago, I tried out: Notepad++, Sublime Text, Atom, VSCode, vim, neovim, VimR, Oni, Emacs, Spacemacs, MacVim, WebStorm and probably a few more I forgot about. I also tried some shells: Bash, zsh and fish, alongside some terminal emulators: Terminal.app, iTerm2, Alacritty and hyper. I even tried several window managers.
In January of 2018, I was staying in the office for two additional hours every evening for almost the entire month, because I thought I needed to switch to vim and wanted to make up for the lost productivity throughout the day. It was total madness
Writing code is not the bottleneck of my productivity
Calling it madness now is easy. But I really only had the best intentions. I wanted to be more productive, to write code faster, to have more output. To be better at my job, really. Here is the thing I did not understand: The speed at which I am writing actual code does not matter all that much. My productivity is not limited by writing down the solutions I came to, but by coming to those solutions in the first place. This is something that does not happen inside a code editor for the most part.
But instead of focusing on this part of my job, I was just chasing the next editor. Sometimes because someone smart showed off how productive they were in that certain editor. Sometimes because I saw it on a screenshot and thought it looked cool. Sometimes just because it is easier to be busy instead of being productive. In reality, every time I switched my environment, I was being slowed down by it. I needed to learn the new quirks of whatever thing I was swathing to with the goal of being more productive. I was working against my own intentions without realizing it.
Recently, a colleague was sitting at my desk at work and was looking over my shoulder while I worked. We talked about editors and setups a little and they said how they were really good at Sublime Text but did barely know anything else because they have been using one and the same editor for most of their career.
This was when the gist of this essay came clear to me: The tool does not matter at all. They all are good for the job. They differ, but you get the job done with every single one of them. Plus, you can also be editing at similar speeds in all of them when you know them well. Yes, maybe a very good vim user might be a little faster in editing text than someone of equal skill in Atom, but in the end, this metric is not what matters. What’s more important is this: When you have mastered one tool, you will always be more productive than someone how knows a lot of editors decently, but has mastered none of them.
What does that mean for me?
The conclusion from this is straight forward: I need to stop switching editors. I should choose one from the pool of “good” editors and master it. It doesn’t matter, which one. After all, the creator of Ruby on Rails is productive with TextMate.
I personally opted for Sublime Text. While I think I am more familiar with vim than with Sublime Text at this point, I was not feeling at home with vim. It always felt like something I just had to use because I spent so much time learning it initially.
So this is it. Sublime Text is fast and performant, it is on the market for quite some time now and has a large user base and ecosystem of extensions. This was important to me, and while it was true for other editors as well, I was just feeling most confident with Sublime when I made the decision a few days ago.
This does not mean that I will not change or improve my setup in the future. But I will not jump on every new editor or terminal emulator. I will change things that are having an actual negative impact on my productivity. I will not use something because someone on Twitter said it was cool. I want to be good at programming, not good at as many editors as I can be.
At this point I want to also acknowledge two things:
- I seem to be quite out of the norm with this behaviour. At the company I work for, most (if not all) people are having their personal setup and have been using it for a long time. But maybe someone out there is going down the same road I was and this will prove helpful.
- When I was in university and I first told Timo I wanted to learn vim, he told me that it was probably not going to boost my productivity as much as I thought it would. Turns out he was right.