A Long Time Coming

I’ve always had a knack for tech. My dad was a network administrator back in the 80s and 90s, so I picked up a lot through osmosis, crawling under desks, watching him troubleshoot hardware, and listening in on conversations about token rings and IRQ conflicts. I had plenty of time as a teenager to dive deeper, but I didn’t take it. I was interested, sure, but I never got serious about learning the internals or writing code. Not yet.

Life moved fast. I started college in 2001 for accounting, joined the Army in 2006, and spent seven years in the infantry. In 2013, I went to flight school and became a Blackhawk pilot. That same year, while I was in flight school, my wife was diagnosed with cancer. It shook our world. Not long after, we took in our niece, who was just seven at the time. Four years later, we formally adopted her. Throughout all of that, I chipped away at my degree one class at a time, working through semesters between deployments and duty stations. I finally earned my accounting degree in 2022.

The following year, I got an email I couldn’t ignore. The Army was standing up a new program focused on emerging technologies, cloud, AI, app development, and they were looking for interested soldiers from any background, regardless of rank or Military Occupational Specialty (MOS), which is basically what the Army calls your job. I had already grown disenchanted with the cockpit. I was ready for something new, something I had always wanted to do. So I jumped at the opportunity.

Since then, I’ve been pursuing a second career that challenges me in completely different ways. I’m currently working toward a Master’s in Applied Business Analytics. I also care for my wife, whose health remains a central concern, and I try to be the best dad I can for our daughter, now a teenager. In case you can’t tell, I like to stay busy. Life didn’t slow down just because I changed lanes, which means the tools I use to get through my workday can’t slow me down either. They have to be sharp, simple, and efficient. I don’t have time for fluff.

Crash Course in Everything

The program I got into wasn’t just another Army training pipeline, it was a year-long executive education course at Carnegie Mellon University, hosted in the Gates and Hillman Centers. For those not familiar, that’s one of the top-ranked computer science institutions in the world. Walking into those buildings each day felt like stepping into the heart of innovation. Researchers, developers, and future tech leaders were all under the same roof, solving problems I hadn’t even learned how to ask questions about yet.

The program wasn’t just about absorbing material, we were also part of a research effort to refine the course itself. During the feedback sessions, I often brought up a simple but important truth: I didn’t know what I didn’t know. And I wasn’t alone. Our cohort was one of the most diverse groups I’d ever worked with. I was an aviation warrant officer with no formal technical training, but I was learning alongside a corrections officer, an Air Defense Artillery (ADA) warrant officer, a few military intelligence professionals, a couple of infantry officers, a PsyOps non-commissioned officer, and a handful of signal warrant officers. Some had never written a line of code. Others had experience in adjacent fields but weren’t used to working in cloud-native environments. That meant assumptions couldn’t be made about anyone’s level of technical savvy. The curriculum had to meet us where we were. That mindset, of asking better questions and not pretending to have all the answers, became one of the most valuable lessons of the whole experience.

It was also a blessing to be in the program right when generative AI was exploding. When I started, people were still wrapping their heads around GPT-2. By the time I finished, GPT-4o was right around the corner, and the pace of innovation was staggering. We watched breakthroughs unfold in real time, not just from OpenAI, but from Anthropic, Google, and others racing to define the future. Being in that kind of environment while trying to keep up with a high-tempo curriculum made the whole experience feel alive, like we were being trained not just for today’s problems, but for tomorrow’s.

The experience was unlike anything I’d encountered in the military. Because there wasn’t a base nearby and Pittsburgh doesn’t have a large active-duty presence, we were authorized to wear civilian clothes during the program. No uniforms, no formations. Just business casual and laptops. It might sound like a small thing, but it was a signal that we weren’t just in a different city, we were stepping into a different mindset. And that carried over even after training. Once we transitioned into our new roles, we kept the civilian dress code. Every day, I show up to work in business casual, not a flight suit or the Army Combat Uniform (ACUs). It may seem minor, but for a soldier, it’s a meaningful shift. It helped me internalize that I wasn’t just learning new tools, I was stepping into a new identity.

The curriculum didn’t pull punches. Cloud administration, practical Python, DevOps pipelines, cloud-native app development, data engineering, and AI model integration were all packed into a single year. It was intense, but it was also the kind of opportunity that makes you sit up straighter and lean all the way in. In the second semester, we were assigned a capstone project designed to have real-world impact. These weren’t sandbox exercises, they were solutions built for actual operational use. My team built a computer vision tool using YOLOv8 to detect and classify objects in images. For model inference, we used gRPC to serve results efficiently and with minimal latency. To connect that system to the larger application being developed at the Army’s Artificial Intelligence Integration Center (AI2C), we wrapped it with a FastAPI service that handled frontend interaction and exposed a RESTful interface.

The crazy part? When I started the program, I didn’t even know Kubernetes was a word. Less than a year later, I was building and deploying microservices with real-world users interacting with them in a production-grade environment. That tool is still being actively developed and is currently undergoing live testing. I was constantly learning, constantly adapting, and constantly looking for tools that would help me get through the firehose without getting overwhelmed.

That’s where VS Code came in. It was sleek, free, and incredibly beginner-friendly. GitHub Copilot made it even better, like having a patient senior developer looking over my shoulder, ready to autocomplete or suggest a pattern when I got stuck. It helped accelerate learning in a very real way, especially early on. But it also revealed the limits of generative AI. You could only lean on it so far before it started looping or giving half-baked answers, which inevitably pushed me into the documentation. That tension, between suggestion and verification, actually made me a better developer. I installed VS Code on my local machine and on my Azure Virtual Desktop (AVD), which the Army had set up as our development environment. It became my lifeline, until it wasn’t.

One day, GitHub Copilot just stopped working on the AVD. It still worked fine locally, so I knew the issue wasn’t on my end. After some digging, I learned that a policy change had caused it to be blocked on dev AVD. That policy change ended up having a bigger ripple effect than I expected. VS Code had become tightly intertwined with Copilot, especially since they’re both owned by Microsoft, and its absence highlighted how much of the editor’s flow had come to rely on that integration. Without Copilot, VS Code didn’t fall apart, but it definitely felt clunkier. The workflow that once felt streamlined now felt oddly fragmented. It was still usable, but not nearly as effective. It honestly felt distracting at times. That shift got me thinking about alternatives, something leaner, faster, and more independent of cloud-based assistance. I needed something more stable, more terminal-native. Something that didn’t rely so heavily on cloud-connected extensions or services that could be pulled without warning.

Enter Neovim

I first encountered Vim during an LTAC administrator course, which I took as part of my onboarding into the Infrastructure and Platforms portfolio. LTAC stands for LEAP-Tactical, which in turn stands for Lower Echelon Analytics Platform – Tactical; because, in true Army fashion, we’ll never miss a chance to acronym an acronym. LTAC is a key component of the Army’s Big Data Platform (BDP) and was expected to play a central role in our edge capability initiatives. As the new guy on the team, I was tasked with learning as much as I could about the platform, which included getting comfortable with terminal-based workflows and tools like Vim.

So when I started looking beyond VS Code, I wasn’t starting from scratch. I already had some basic navigation and muscle memory from that course. I mentioned to a coworker that I was thinking about trying to do my dev work in Vim, and he immediately pointed me toward Neovim instead. He explained that it had better plugin support, stronger community backing, and a much more active development cycle. That gave me the nudge I needed to dig deeper. Neovim is a modern, extensible fork of Vim that supports lazy-loaded plugins, lightning-fast startup, and full keyboard-centric control. It looked lightweight, powerful, and completely customizable. It checked every box.

At first, I just experimented, opening files, poking around tutorials, trying to get a feel for it. Then another member of my cohort pointed me toward NvChad, a modular, pre-configured framework that comes with sensible defaults, built-in LSP support, and a clean plugin manager. That sealed the deal.

The learning curve was steep, but not discouraging, especially after the training I had just had. Every keystroke felt like an investment. The more I stuck with it, the more I appreciated the precision and control. I wasn’t fighting my editor anymore. I was shaping it. For the first time, I was building my own development environment from the ground up, and it felt like mine.

What Makes Neovim Work for Me

First, it’s fast. Really fast. There’s no UI lag, no bloated startup, no spinning up dozens of extensions before I can even start typing. It launches instantly, even on lower-spec machines, which makes a big difference when I’m jumping between projects or working in a constrained environment.

Second, it’s modular. Plugins only load when they’re needed, which keeps everything lean and efficient. I’m not dragging around a bunch of features I don’t use. I get exactly what I need, exactly when I need it, and nothing more.

It’s also terminal-native, which matters more than most people realize. When you’re working in secure environments where graphical interfaces are limited, or not even an option, being able to live inside the terminal isn’t a luxury, it’s a necessity. Neovim fits into that workflow perfectly.

And finally, it demands focus. There’s no sidebar full of distractions, no floating buttons or visual clutter. It’s just me and the code. That clarity has helped me stay grounded, especially when I’m juggling deadlines, schoolwork, and family life. When I open Neovim, I know why I’m there, and it keeps me on task.

But It’s Not All Smooth Flying

Let’s be clear, Neovim isn’t exactly beginner-friendly out of the box, but it’s not a black hole either. You’ll Google a few things. You might have to look up how to copy/paste or how to get your language server running. But for me, most of what I needed to get up and running I learned in a single workday. I was even able to throw in a custom keybind to yank code to the Windows clipboard from the WSL terminal, not because I had to, but because I could.

It’s not plug-and-play, but it’s not punishing either. And the trade-off is that you get something tailored to your exact workflow. Once you spend a little time with it, you stop configuring and start coding. That’s when it really starts to feel like your own.

Would I Recommend It?

If you’re someone who thrives on building your own tools, if you’re working in secure or minimal environments, or if you’re just tired of the bloat in GUI editors, Neovim is absolutely worth exploring. You don’t need to be a power user to get started, but a willingness to tinker definitely helps.

That said, if you’re learning the ropes of development, VS Code is a phenomenal option. It’s fast, well-supported, and has an incredible extension ecosystem. Honestly, it helped me learn a ton, and I still recommend it to friends. The difference is less about beginner versus advanced and more about what kind of experience you want. Neovim gives you an incredible sense of ownership. You’re not just using a tool, you’re shaping it to fit your exact workflow. And there’s something deeply satisfying about that. When someone walks past your terminal, sees Neovim running inside WSL, and says, “Wow, you’re serious,” it sticks with you. Neovim didn’t just improve how I write code, it reminded me why I love this work. The joy of understanding, building, and taking full ownership of the process.

More Than a Workflow Shift

Switching to Neovim wasn’t just about escaping a broken Copilot setup or optimizing my terminal. It was about reclaiming a bit of focus in a chaotic, demanding chapter of life. It was about taking the time to build something with my own hands, configuring it, breaking it, fixing it, until it started to feel like mine.

Even now, I’m still getting used to the workflow. But there’s something rewarding about the process. Neovim reminds me that progress doesn’t always come from convenience. Sometimes it comes from friction, from wrestling with complexity, and from finally understanding something you once found intimidating. If that sounds like your kind of journey, Neovim might be worth your time. And if not? That’s okay too. There’s no one right tool for everyone, just the right tool for you, right now.