When it comes to programming, I used to think that the height of cool was coding in a terminal-based text editor. (I still think it’s the coolest thing ever.) Be it vim, emacs, or something else, it just seemed so much more hardcore to do everything just in your terminal.
It seemed even more cool because I was a complete newbie when it came to understanding my development environment. I didn’t even know that you should care about your environment.
Most of my coding was in Java, so I used Eclipse. Eclipse can do a lot of stuff, but I knew a grand total of 0 of its features. For me, it was just a text editor that could run my code and tell me when my code wasn’t working.
This continued throughout my entire time in school. After graduating, I joined a Java shop and continued to use Eclipse. It was also the main IDE that the other engineers were using.
Now, our code base was pretty big. On top of that, we were using a homegrown build tool that would automagically find your dependencies and invoke whatever command to compile your server. This resulted in some pretty terrible dependency management.1 All of our code would accidentally pull in some other massive projects, often to just access a package or two.
Long story short, Eclipse was suuuuper slow. Just pulled the latest changes? Let me beach ball2 for a minute or two.
Eventually, I decided I had enough.
Transitioning To Vim
It was time to actually learn to use vim. I learned some basic commands and learned how to customize my editor a bit. Then I was off.
I can’t properly describe how much worse I became at coding. I was absolutely terrible.
The most obvious thing was how bad I was at navigating. Most of the time, I was just hitting j and k to navigate within my file. I was barely competent at using search to jump around. I also couldn’t navigate between files very well because I didn’t know where they were.
I was bad at coding as well. I knew what I was trying to write. My problem was that I didn’t realize all the small things that I was dependent on Eclipse for. I had tons of little mistakes—typos in method names, missing import statements, failing to update callers when refactoring a method signature. At one point, another one of the engineers told me I really had to be more careful.
It took a bit of time, but eventually I started to get all of these things under control. I started to develop a mental map of how the pieces of our code base were related and fit together.
Every Character Counts
Once I got the hang of things, I could spend my mental energy on being bored. And when I became bored, I began to notice all the small things that I had to do.
The most impactful observation I had was when I was writing a package statement. I understood that package foo; meant that my class was in the foo package/directory. What I didn’t understand was why my class was supposed to be in foo, rather than something like bar.
This was impactful because it helped me realize something important: I didn’t actually understand what I was typing.
The code I had been writing was accidental. Although it worked, I didn’t understand the different elements in my code.
The moral of this story? Every character counts.