This is my first blog ever, and to be honest, I’ve never done this before. But I want to share a glimpse of my experience on how I got into the nitty-gritty of it all. In case there are others like me who might be struggling or trying to decide if they should dive into these topics. I’m by no means a genius or a Chad of the dev world, but I do want to talk a bit about the journey of how I ended up setting up my dev environment in the first place, what I learned from it, how it helped me, what was going through my mind and what I got from it. Hopefully, this can help motivate others like me to keep pursuing.
I don’t know if there are any other Jr. Devs like me, but I sure know how to go down a rabbit hole and not come out until I’ve got it all working. Which isn’t healthy but when is finding balance ever about not falling first.
The Before
To start, I’m a self-taught dev and didn’t know much about anything. All I can remember when I started out was that I wanted to program something and see it working. In the beginning, I barely used the terminal/shell. I’ll also explain how I went from VS Code to Neovim.
A little backstory. I had to learn the Basic of Python at my college and at that time I had to use Thonny. A simple editor to literally type in some code and see the results + some other debugging stuff. My first somewhat of a real IDE was actually PyCharm. I used it quite a bit to learn Python.
It was when I started really going into software engineering with frontend development. I discovered VS Code and oh boy was it everywhere. Everyone was using VS Code. Like everyone, I went ahead and started using it as well. At times I had to use the terminal, but all I really did was use the built-in one, and I was fine by it. I had no idea that the outside terminal did the same thing.
In short, I ran into iTerm2 (for the 4th time) and ended up downloading it. I only downloaded it for the beauty of it. Like I said, I knew nothing. I had some idea of what a terminal was for, but not nearly as much as today. I knew it had potential to look better than the default shell, so I went with it.
So, I started exploring it. Saw how customizable it can be and discovered something called Vim by accident. Vim. That name sounded awful when I first heard it. Not gonna lie, I didn’t care much about it at all. I went on to learn web development, just like I planned. But along the way, I figured out the navigation inside VS Code and also found out the customizations that this IDE provides.
From VS Code to Neovim and Beyond
I started making my own keybinds inside VS Code so I can have it working the way I want it to. But I remember ignoring the hell out of shortcuts at first because I didn’t wanna spend time thinking about which or where those keys are. I basically lacked experience in typing and understanding of how important shortcuts/keybinds can be when you are actually coding. You would not know it until you really start using it. For instance, pressing a combination of keys to instantly move a line up and down or quickly jump between words and lines or copy line up or down. Searching a file right from the current file that you are working on. All that stuff. I was already doing some of that in notion.
But as I used it to code more and more, I loved it. I thought it was the best thing ever. I liked how fast it was because It always bugs me when I had to move my hand to my mouse and move the cursor to edit those sections. Or even look around a file tree to find the folder/files I want. It’s just more eye strain looking at big projects with a bunch of files. If I ever need to do that, I would place it as a secondary action. Instead, I would just search a file which is much faster but obviously requires you to remember the project/file that you are working on. It’s not an issue if you are going to be working on that project anyways. During this time, Git also appeared in my life but at first, I was lost in the trees. No idea what Git is, knew nothing about local repositories or remote repositories. This is when it all started. I got really curious and went searching for more info and other tools.
As time went by, I realized that dev utilities and workflow seemed very important because I had to switch between multiple node versions, commit things, move lots of files, and run a bunch of commands and blah blah etc. It was a next-level time saver to be able to just do everything inside the terminal.
Then I discovered an editor called Neovim. I got confused about Vim vs Neovim for a second. I’m not going to go too deep, though. It’s more about how I ended up trying to use hjkl for everything and why I care about my terminal and my IDE setup now. For those who have no idea what hjkl is, it’s basically arrow keys in Vim. I was already using Obsidian at that time and so being the crazy me of course I had to find a way to make hjkl work properly inside Obsidian as well.
Currently, I’m using a terminal emulator called Wezterm. It uses the same config language as Neovim, which is Lua. I love that because it makes everything feel the same and easier to manage from my perspective. Alacritty was my go-to for a long time. It was fast, and I had no problems with it. When I was using Alacritty, it had a TOML file used for configuration, but finding out Wezterm used Lua made me switch instantly. Before that, it was just iTerm2. Sure, configurable, but apparently not interesting enough for me. If you are using it and you love it then you don’t have to change because someone says so.
By this point, I was already deep into Neovim setups, learning, understanding the configurations, plugins, and all that + Lua language. My Vim motions were pretty decent, but I still felt like I could be faster. I remember when I saw what one could achieve with Vim motions I knew that my option/command arrow keys would not stand a chance.
Because I had to do a lot of Neovim configurations, I don’t remember exactly how, but I started looking into my .zshrc file. Learned about aliases. That led to the knowledge of dotfiles, which I had no idea about. Of course, it led me to GNU Stow, a dotfile manager. Then, I realized every app has a dotfile and a bunch of directories within them. I can keep going, but this showed me how to configure literally everything to my liking. I had this clear picture that I never had of how things worked. It even got me deeper into Github, but we'll get into that later.
The Challenges and Rewards
I went on setting up terminal customizations + shell stuff like auto-suggestions, auto-complete, terminal syntax highlighting stuff which I’d seen but had no idea I wasn’t using. I didn’t even know that was even a thing that you have to install. These are just tools that help improve your shell experience as a programmer. You see what I mean? I had no idea how important those things were AT ALL.
Once I had everything set up and glued together, it changed the way I used my terminal big time. It even affected how I used my Mac, my workflow, and pretty much everything from that point onward. I saw the value in it. I haven’t touched VS Code since, not because it’s bad, but because I found that I really like doing things in the terminal more. Neovim played a huge part in that. It even made me go back to VS Code just to set up Vim keybinds and motions that the default Vim extensions in VS Code don’t provide. But after all that, I still don’t use VS Code. I struggled to get the same experience I had in Vim. It was like I was trying to turn VS Code into Vim. I got the config really close to what I wanted, but it still wasn’t it.
Even though I could still set up debugging in Vim, I’d use VS Code maybe for debugging, but that’s it. And then Mr. Tmux came along, and Big Bro fuzzy finding came into my life, and I knew it was over. I knew I needed this.
So guess what? I configured Tmux to my liking. I went on and researched fuzzy finding with Tmux and how Telescope fuzzy finds in Neovim. It’s a lot. Lazygit, a git tool, became a thing for me as well. By this point, I was fully immersed, and honestly, I enjoyed it. It was teaching me things I hadn’t even realized were part of being a developer. Even though my Neovim setup breaks a million times (not really) , there are always ways to fix it, and so many plugins, repos, and setups that show me different layouts of Neovim that I can learn and implement from. Plus, you see how Neovim brought me into all of this and into the whole GitHub category thing because of the Vim plugins you have to understand and repos you have to read. It opened my eyes quite a bit. Don’t even get me started on the Vim Macros.
I jumped into this and didn’t stop while still pursuing my journey as a developer. I continued doing my projects with all the new knowledge I have + the better workflow, and I was flying. I finally understood why .zshrc exists, what the h*** Bash is, what Homebrew is for, prompt command line tools, and why there are all these plugins. I finally understood why terminals exist, and why some things I didn’t even know needed configuration suddenly needed it. It was the first time I learned what an LSP was, by the way. And I don't mean the expanded word “Language Service Provider”. I meant in terms of what it was built for and how it feels like without an LSP.
If you jump straight into VS Code, everything just works, and that’s it. You add extensions and go from there. But this path here? This is a different type of learning experience. Believe it or not, I may not be the smartest guy out there, but I remember running Tailwind CSS in VS Code without the extensions. I was confused where were the auto-color completions and suggestions? Someone told me I had to install an extension for Tailwind, so I did, and that was it. I still had no clue what that extension was until I found out about LSP during my Neovim battles. Then there are things like Linters such as prettier or eslint that auto formats your code and etc.
I learned so many terminal commands, navigation methods, and searching with grep. Wether it be chmod +x or what not. Key binds also became my thing. This journey brought me into the Karabiner-Elements world and its JSON format. It is a software for setting up keys on your keyboard to add different key binds or hyper keys. I had to do this because I wanted to be able to use key binds to navigate where I needed to go and I did not want it to run over other keys. I wanted that feeling that Vim gives, but I wanted it outside of Vim too. If you use Vim, then you know exactly what I mean.
I was way into it. I even found a TypeScript build that you can write for your key binds and then later format into a JSON file, so I didn’t have to write those large, humongous JayYSON codes. A bit embarrassing to say, but the truth is, I had no idea that was even possible. It got me going in loops, setting up my terminal with fuzzy find, so I could jump straight to any directory, anywhere like finding right from Tmux then quickly open up a fully functional editor to check or run something on the spot. There’s just something about it.
It even got me setting up paths in my .zshrc for Go HTTP servers and Go files to run properly. I finally understood how important it was to dive into all of this. If I was just using VS Code, switching between files and directories, learning frontend development in a traditional way, opening projects from Finder, and barely configuring anything by code or not failing a million times, I would have missed out on so much.
For example, messing up GNU Stow symlinks and losing 10+ hours of configs that I had been setting up, or breaking Neovim just because I made a syntax mistake setting up a key bind. There were so many more config and shell difficulties that came out of nowhere. If I hadn’t gone through all of this, I would be disappointed to realize later how much I missed out on.
Take Homebrew, for example. At first, I didn’t even know why it existed. I had no idea what it was for. All I knew was that it had to be installed on macOS because everyone said it makes things easier. That’s it. Then one day, I fell into the vortex of trying to get some things to work and wanted to improve my workflow. Only then I understood what it was for. It’s just one of those things for me, maybe I was too eager to dive in and skipped reading the docs lol, but you get the point. Even though you can sort of get away with Homebrew.
Reflections
I’m not saying you can’t do everything I’ve mentioned if you stick with VS Code. This isn’t about choosing sides in an IDE battle or dictating which one you should use. You can be just as fast and efficient with VS Code, or even better, if you configure it well enough. But when it comes to IDEs and terminal shells, the experience you gain from diving into this process is unique. It’s something you might miss out on if you’re only focused on doing the frontend/backend or anything without fully understanding the tools and environments you work with.
This might be different for some people, but if you feel like diving into these things and you’re a Jr. Self-Taught Dev, I’m here to tell you ,don’t wait or hesitate. I promise it won’t slow down your web dev, backend learning, or whatever path you’re on. It will probably turn you into a better programmer by at least 20–30% (idk where that number came from, but yeah).
Yes, you have to take time away from learning other things to do all of this. But if you can manage your time, and if passion and hard work exist within you, nothing is impossible. Just dive into it, and you’ll surely get something valuable in return.
I never considered looking back because of how much it taught me and what it has led me to. Even today, I find myself able to do things faster because I’m starting to know where to look. There’s still much to learn, but that’s the beauty of it you never stop learning and exploring.
Top comments (0)