I've made a series of conscious choices as a developer that I believe will pay off in the long run, even though they come with short-term pain and efficiency costs. Here are some of them:

Linux

I’ve been working in the web development industry for about five years. I started in 2020, mostly designing and building websites and polished landing pages for clients, without much understanding of what was happening under the hood. When I decided I wanted to become a "proper" web developer and began learning more traditional tools, I quickly ran into problems with Windows — the only desktop OS I had ever used. Certain tools didn’t work properly with Windows or WSL, and whenever I needed to interact with Linux servers or debug things inside WSL, I was lost.

I wanted to understand more, so I decided to try Linux. After all, nearly all the code I wrote would eventually run on a Linux machine somewhere — it felt wrong not to use it for development as well. Some coworkers at the time were enthusiastic Linux users, and their excitement spoke to me. If someone can be that passionate about an operating system, there must be something to it. I knew I’d face a lot of discomfort and pain at first — it’s a very different computing environment — but I was willing to push through and give it a real shot as my daily driver.

In November 2024, I took the leap. I went with Ubuntu, since I knew most servers ran it. I installed a preconfigured setup called Omakub by DHH (his newfound love for Linux was contagious), which was brand new at the time. It came with useful developer tools pre-installed and looked much nicer than stock Ubuntu.

As expected, the first days were rough. Most navigation was bound to unfamiliar keybindings I had to look up constantly. Many apps I relied on in Windows weren’t available on Linux, or their Linux versions were missing features. I had to either bounce back and forth between Windows and Linux or find alternatives. Any time I wanted to change something on my system, I had to learn weird terminal commands instead of relying on the familiar Windows GUI. But I could feel progress. It felt good to finally understand commands that once made no sense. It felt good to drop subscriptions I had been locked into for years and replace them with free alternatives. It felt good to truly control my own system.

After a couple of months, I already felt more productive and knowledgeable than I had on Windows. My appetite for learning grew, and I started trying out new tools. One of my coworkers was using Hyprland, and I was drawn to the aesthetics, smoothness, and control it offered. Again, I looked for preconfigured setups and found JaKooLit’s distribution. After a lot of configuring, debugging, and trial-and-error, I finally got a setup I was happy with. The first week was painful again, with new keybindings to memorize and a new environment to adapt to, but after a month I was reaping the benefits. I was flying around my system with speed and ease, tweaking things as I went, trying out tools, and confidently customizing both functionality and visuals.

Months later, I was thrilled with the move from Windows to Linux. Still, Ubuntu started to feel limiting — some newer tools weren’t compatible. I looked into alternatives, but the effort didn’t seem worth it yet, so I stayed put.

Then, in summer 2025, DHH released another preconfigured Linux setup — this time based on Arch, called Omarchy. It had everything I was used to (Hyprland, Waybar, terminal tools, TUIs) but also some new discoveries from his own Linux journey. I was hooked, especially because Arch meant almost every tool was available through the AUR. I decided to test it by buying a Beelink SER8 mini-PC and installing it fresh. The installation went smoothly, and within a couple of hours (minus some network/DNS debugging), I had a beautiful, functional, customizable Arch setup. I tweaked keybindings, added scripts, automated workspaces, installed and removed apps, and essentially rebuilt my Ubuntu setup — but better. Now I also had the benefits of Arch’s rolling updates and community-driven ecosystem. After a few days, I exported my configs and installed Omarchy on my main machine.

Now I run Omarchy on both PCs, and there’s no going back to Windows. Every morning I’m excited to start my system and see it in action. My hype may settle eventually, but I know I’ll keep tinkering and customizing for a long time.

Neovim

When I switched to Linux, I also started exploring Neovim. At first, I kept VS Code as my main IDE, but I was constantly reading, experimenting, and watching others use Neovim. I didn’t have any real issues with VS Code, but when I saw coworkers and streamers like thePrimeagen and TJ tearing through codebases with unbelievable speed, I was in awe. I wanted that.

I realized the long-term benefits of learning Vim motions, but Neovim felt like an entirely different beast. Switching to Linux was tough — but this was on another level. Even after tutorials, my brain would fry trying to do simple things like copy, paste, delete, or move text. Configuring Neovim added another layer of complexity. Tools like LazyVim help smooth the transition, but I think there’s real value in learning to configure it yourself.

Slowly but surely, I got the hang of it. After three months of practice, I committed fully and made Neovim my daily driver. This coincided with installing Hyprland on Ubuntu. Since the system didn’t come with VS Code preinstalled, I decided not to install any fallback IDE. That forced me to push through moments of frustration when I wanted to give up — if I had VS Code available, I probably would’ve switched back.

Now, I firmly believe every developer should at least learn Vim motions, though not everyone needs to use Neovim full-time. Vim motions are available in nearly every editor, and I see no downside to learning them. The upside in speed and efficiency is huge — and only grows with practice. After eight months, I feel like I’ve barely scratched the surface of what Vim motions can do. And honestly, the satisfaction of nailing a complex motion combo is a reward in itself.

Neovim configs are written mostly in Lua these days. You don’t need to fully learn Lua to configure Neovim — plenty of examples are out there — but picking up the basics is extremely useful. It makes debugging easier and opens the door to deeper customizations. For me, learning Lua paid off doubly since I also use it professionally at work.

Restraining from AI help

As a relatively new developer, it’s been tricky to figure out when and how to use AI. It’s undeniably helpful for efficiency, but it comes with downsides. First, it’s often wrong — and I don’t yet have the experience to always catch mistakes. Second, leaning on AI too much stunts my growth. If I let another entity do all the work, I won’t truly learn.

My solution is to avoid using autocomplete for things I don’t already understand. For example, when I’m learning a new language or library, I don’t let AI autocomplete my code. I’ll still use it for repetitive tasks I already know. More importantly, I use AI chat tools primarily to understand code, not write it. I want AI to act like a senior mentor — not a code monkey.

When I go to a senior colleague, I don’t expect them to do the work for me; I want them to guide me toward the solution. Only if I’ve hit a real wall after multiple attempts do I ask for direct help, and even then I ask questions to make sure I can handle similar problems myself next time.

If you ask AI for code without carefully framing your request, it often just spits out a solution. That might save time, but if you take it blindly, you don’t learn anything. Worse, it might be wrong — and if you can’t figure out why, you’ve wasted time and still haven’t solved the problem.

Hopeful about the future

Maybe I’ll shoot myself in the foot by choosing these tools and this mindset. It’s hard to measure the long-term benefits. But I genuinely enjoy using Linux and Neovim, so even if I don’t become a “better” developer than I would have on Windows and VS Code, I’ll still be happy with my choice. I also enjoy the practice of programming itself, so I’d rather keep sharpening my own skills than offload everything to AI. I’ll keep using AI as a mentor and learning aid — but always with limits.

I hope these choices will help me reach my goal of becoming an industry expert faster and more effectively. But even if they don’t, I’m okay with that.