Hee-haw… Here we go. I have been coding for almost a decade now. And, for anyone who spends two-thirds of his day doing so, his toolchain matters. Let’s go for a walk down the memory lane. This article is going to be different.
Disclaimer: Today’s content is going to be subjective, so, please read with an open mind.
Sometime Around 2010 — Notepad Grade
I was dabbling in Notepad++ to learn Java development as a young, clueless potato. At that moment, I didn’t even understand what an editor was. To me, it seemed like a Notepad with extra buttons.
The focus was on learning programming, not DX (Development Experience). The only intriguing thing was that I could run code using a plugin by pressing one of the function keys. It gave me a big advantage over writing in Notepad and running Windows command prompt.
Key points
- It's good to have a place to write and execute code together.
Two Years Later — Eclipse
I could decently code in a couple of languages now. One of the books I was reading recommended the next shiny thing, Eclipse. Eclipse had hit quite the right spot. For the first time, the toolchain was becoming addictive. The joy of coding, building, and running those Java Swing apps without diving into the build and execution system was simply… muahhh.
Internet was not big, so I often would go through offline docs and figure my way out. It got tedious at times, but there wasn’t another way out. For the first time, I wondered why this software didn’t behave like the previous one. No, I didn’t know the word IDE yet. I only knew that Java runs on three billion devices, and I had to be good at it.
Key points
- It’s better if your software can handle the configuration work for you.
- It’s even better if your software can tell you what to write next.
2014 — Meeting Linux and VI
I got this new blue laptop. The sticker says, “Ubuntu.” What the heck is this thing? Where is my DVD with pirated Windows and activation key written on the back of it? Went to the school library, and boy, that book on Unix gave me tremors of joy. I decided to shift to Linux permanently (and I never touched Windows ever since).
I couldn’t understand why weirdos on the internet always suggest editing random config files using something called VI. Who on god’s green earth would open a terminal, navigate to a file, and enter into that creepy vi thing from where one can’t even quit?
Sadly, it was a part of the college curriculum, and I had to write in it. The good thing is that after you press ‘i’, vi becomes “normal.” I hated it so bad that I wrote a gedit config, so my professor thought I was coding in the terminal.
Key points
- Never push for a product/outcome. You may push for an idea and see if people resonate with it.
- Every developer should use Linux. No exceptions. (Personal take: I also consider macOS a Linux distro.)
2017 — Sublime Art of Coding
Now, things were taking shape. I had decided my career path as a web developer. I often built small utility apps. Again, the book I was referring to told me that the Sublime is the next shiny thing. Ahoi! I was on board.
There is something about it that feels close to my heart. It was JSON configuration, and I spent the whole week tweaking things in the settings file. It was a near-magical experience to copy a JSON file on a USB drive and make my friend’s machine like mine. Lowkey dotfiles, hehehe.
At that point, my Sublime started to look like a different application to regular Sublime users. To this day, I am a hardcore ricing fan (a fancy term for customizing your software). And yes, I am immune to that pop-up asking me to buy Sublime, just like good old Winrar.
Key points
- Sublime was fast for the kind of things it can do.
- The only reason it “failed” was due to VS Code’s similar pitch, corporate backing, and excellent community support. Developers moved to VS Code, and no one develops tooling around the software they personally don’t use. Vim is nowhere close to Sublime's power (all mighty GUI), but the community stuck to it, and it became awesome over time.
2019 — The Rise of VS Code
I felt like I was getting ancient and even started working professionally. Sublime text was like the back of my hand now. Every keybinding and config option lived in my mind. Not to mention the plethora of extensions, well customized for my workflow.
At that point, losing my Sublime config folder was more of a worry than the laptop itself. Just kidding, I knew git by then. The office was asking to work in VS Code, so again, there were no options. Spent a month tweaking it.
In the end, I wondered what a Frankenstein’s monster I had made. It looked like Sublime, responded like Sublime married to VS Code, and started heavy like my old friend, Eclipse. The worst part was that the senior guy scolded me every time he tried debugging on my machine. Usual hacker problems, no big deal.
One thing I love about VS Code is its zero-config extension ecosystem. And it overall felt smart under the hood while coding. I could feel that it had something that Sublime lacked. To this day, VS Code has been my favorite coding software. If something can be coded, it will eventually be in VS Code. I feel it is like the modern version of emacs.
I felt the difference between strict and dynamically typed language firsthand. I worked on Ruby on Rails those days and dynamically typed languages are a nightmare for any editor. Shoot me, but I hate Ruby, Python, JavaScript, etc., even though I code in them daily for one reason. Maybe for that one reason, I knock on the doors of JetBrains from time to time.
Key points
- VS Code had a vision of being an omnipresent editor, and the community made it happen.
- Its core is rigid and well-thought-out, on top of which people make what they want.
- Its blessing proves to be its curse. Since anybody can easily write anything, people write them without much thought and later blame VS Code for being slow.
2021 — Oops, I Have a Bit of a Perfection Problem
What’s this OCD-looking thing, you ask? It’s a condition where you are a bit too strict about how things should be. You may say, wow, that’s a good thing, but then if your table’s edges don’t match your laptop’s, you get a shiver of anxiety.
Also, I get distracted fast, so I need a focused environment. I left this article to get the above image, and now I am back after reading about the movie this meme came from. OK, cool, we are on the same page now. See, we aren’t much different after all!
I like both environments, outside and inside the laptop, to be ultra-mimal. Check out the screenshots at the bottom of this page; there aren’t even close icons on application windows, if possible. From letter spacing in fonts to the inner padding of a popup, everything is a trigger. To be honest, it makes me happy to do this kind of stuff, and if you search for “Unix ricing,” you’ll get blown away.
On the other hand, literally on the other hand, I started getting wrist pain due to constant jumping from letters and arrows. Grinding 80 hours a week comes with its own perks. 😅
I was googling about this wrist pain condition, and funnily enough, one of the tips was to use Vim (-mode) on your computer. That sneaky VI, I couldn’t even understand was the same thing until I opened it. I had some residual hate towards it.
For server work, I was using Nano. Later, I moved to micro, which was closer to VS Code bindings. Every stunt it takes to avoid my arch nemesis, Vi. I realised that literally every tool I use has that weird Sublime and VS Code hybrid keybindings.
Gosh! I hate myself. Can’t even use another person’s computer running a pure version of that software. To support the no terminal mindset, over the years, I forgot all my appreciation for awk, sed, grep, etc. Things needed to change; I couldn’t live in this denial.
Key points
- Do what you enjoy and not necessarily what keeps you abstracted from the real problems.
- Everybody spends time in denial. It's normal as long as you are ready to come out of it after realization.
- Learn core (gnu-) Linux tools. You’ll understand the benefits in the long term. For example, I’d have been much better at regex if I had just continued using grep and sed for finding and replacing.
2022 — Adopting Vim Motions
For the first month, I used nothing more than hjkl.
I resolved to use Vim. Not because it’s any better for my specific workflow but because I wanted to break my dependency on VS Code.
I knew I couldn’t drop into Vim for my day job. So, I settled on the middle ground of using Vim bindings in VS Code. Courtesy to a YouTuber called Ben Awad, who showed this peaceful path of adopting Vim. I always wondered how he could magically teleport to random places when I could only move there really fast.
On the safe side, I’d automatically turn it off in all my office project folders. Nothing in Vim particularly amazed me then because I had a similar shortcut in mind for VS Code. Yet, the constant tussle between both was getting hard. By the end of the year, I could fluently navigate in VS Code using Vim keybindings. After almost a year of usage, I started seeing the ergonomic and functional benefits*.*
Key points
- Be practical, you son of a gun. Learn to walk before you run.
- Temptations to achieve what others flash is a good motivation. Personal willpower won’t be enough to explore unchartered territories. We need some rocket fuel to kickstart the process.
2023 — The Final Migration
It was darn stupid of me to think that one day I’d uninstall VS Code and move to Vim someday because I could navigate there similarly. I didn’t realize I was using Vim bindings for doing VS Code things; the workflow part was still a miss. All that I learned was a few keyboard shortcuts.
I moved anyway. One day I had to find and replace a few words in a project. I couldn’t do it, so welcome back home. VS Code, at this point, had become my identity. I could fly through code blazingly fast in VS Code, and my friends knew me for that. So I settled back in, leaving Vim.
I was happy I could do whatever those Vim nerds could do, yet I knew I was still in a big comfort zone bias. My problem was that I was using VS Code with a hybrid keybinding, and now I replaced even that with something else. What kind of a solution was that?
Luckily, I got a break from office project work sometime back, and I knew this was the chance to transition my configs. I realized I had no trouble in moving from Sublime to VS Code; it was a happy process. I started working in raw Neovim, and yeah, it was painful, but I had a plan. Whenever I missed something, I would “read Neovim docs” and add it.
Makes me happy I understand and have written every single line of my editor config myself. Took two months but now I have my own sweet little PDE (Personal Development Environment).
This covered everything from default indentation size to a file tree to language servers. Earlier, I watched a YouTube video from ThePrimeagen on Neovim setup, and it overwhelmed me so badly that I had to take a week’s break from thinking about my own configuration. 😂
Key points
- Acknowledge the iceberg theory. One gets attracted to what floats and not the work it will take to create and understand the base. My suggestion, if you ask, is simple. Respect it!
- My biggest motivation for making the final switch was the aww factor surrounding Vim as a software. All you see in the screenshots below is text on a terminal window, no images, no real buttons, and no GUI of any kind. They aren’t even real icons. It’s really hard. Imagine you can’t even change the fonts or the size of it. Every single thing is carefully manipulating text on a black terminal window. That respect for the people who build it keeps me going.
Today
Now that I have fully moved my workflow to Neovim, it doesn’t even feel any different. I was already used to Vim bindings, only the aesthetics have changed. Yet the good part is I understand how these moving pieces work. I understand how that in-line error message shows, from where these fancy auto-completions come, how each line gets formatted, and much more. Looking back, I could have peeped into the source code of VS Code or its extensions, but the mindset was to use it and not learn it.
The biggest shift is that I look at software in general from the mentality of the builder rather than a consumer. Now, when I see something, I ponder how to build it rather than use it.
After all, I am an engineer and my identity revolves around two main things: how well I understand softwares and what I (can) build
Some Snaps of My Coding Setup
Terminal using iterm2
Neovim landing page
AI code suggestions
Language-based completions and documentation
Fuzzy file and content exploration
Change tracking (can rollback to things changed days ago, no git needed)
Unfortunately, I can’t go through every screen and utility, but if you like the setup, I can write an article on how everything is set up from scratch. A detailed tutorial of sorts on the basics of terminal and Vim customization. Do drop a comment if you’d like me to.
FAQs
- Will using Vim make me a better developer? — Yes, I take the guarantee.
- How hard is the transition? — It’s pretty easy. Just a few hundred keybindings, lol. (I have a super secret ninja way to learn them all in 30 minutes)
- Why does it even matter? It’s just an editor. My work goes with what I write in it. — You want to be an engineer or a writer. Figure out fast! Good that you chose engineer. Now think again: how many fundamentals of engineering do you get exposed to that your day job abstracts from you. You don’t want to be an engineer with a weak core, do you?
- It seems too hard to get started. Will I grab it? — Took two years, multiple quits, and it only worked when I started from scratch and incrementally added functionality. It’s your child now. You won’t say anything bad about it. Remember that you don’t choose your interests; you raise interest in things you put effort into.
True Story…
Want to Connect?
Top comments (0)