How theory meets daily reality
After three posts discussing various editors and IDEs, the obvious question: what do I actually use? Here's an honest breakdown of my day-to-day workflow, including the pragmatic compromises that come with real work.
The Reality of Tool Selection
Despite trying virtually every editor available, I haven't settled on one perfect tool. Instead, I use a small rotation of editors, each serving a specific purpose. It's not elegant, but it's effective.
Think of it like a workshop. You wouldn't use a hammer for every task just because hammers work well. Different tools serve different purposes.
Visual Studio: Primary Tool for Professional Work
When I use it: Any substantial .NET development—web APIs, desktop applications, solutions with multiple projects.
Why it works: After years of use, I can navigate complex codebases without conscious thought. The debugging experience remains the benchmark: conditional breakpoints, object inspection, stepping through async code, parallel stacks for concurrent debugging. When I'm tracking down a race condition or investigating unexpected behaviour in a distributed system, Visual Studio's debugging tools are often the difference between a quick resolution and a lengthy investigation.
The IntelliSense for C# understands context deeply. When refactoring a class used across dozens of files in multiple projects, the "Find All References" and rename tools handle complexity reliably.
The tradeoffs I accept: Slow startup. Significant memory consumption. Occasional mysterious re-indexing. These fade into background noise when I'm focused on solving actual problems.
Professional context: Most .NET teams standardise on Visual Studio. Using the same tools as your team has real value—shared configurations, consistent build processes, straightforward collaboration.
VS Code: Secondary Tool for Lighter Work
When I use it: Configuration files (JSON, YAML, Docker Compose), documentation, quick Python scripts, frontend work, anything that doesn't require full IDE capabilities.
Why it works here: Speed. It opens instantly. I can edit a file and close it before Visual Studio would finish loading. The extension ecosystem provides exactly what I need without unnecessary overhead.
For web development and file formats that Visual Studio doesn't handle well natively, VS Code is the obvious choice. The integrated terminal, Node.js support, and lighter footprint make it practical for tasks where a full IDE would be excessive.
My configuration: Minimal customisation. Docker extension for container management. GitLens for repository context. A colour theme I find readable. I've learned that extensive configuration often becomes its own time sink.
The position it fills: VS Code occupies the middle ground between too simple and too heavy. It's capable enough for real work but light enough that I don't hesitate to open it for a quick edit.
Neovim: Primary Tool for Personal Projects
When I use it: Personal hobby projects. Terminal-based workflows where I'm already working with command-line tools. Configuration files when I'm in a terminal session. Any personal coding work where I'm not constrained by team standards.
Why I use it: Once Vim motions become automatic, editing feels more direct. Not dramatically faster—the "10x productivity" claims are overstated—but noticeably smoother for certain tasks. The efficiency compounds over time.
More importantly, Neovim fits my personal workflow. For hobby projects, I work in the terminal: tmux for session management, command-line tools for building and testing, Neovim for editing. Everything stays in one environment. There's no context switching between terminal and GUI applications.
Transferable value: Vim keybindings are widely supported. VS Code has a Vim mode. Visual Studio has Vim extensions. Many terminal tools use Vim-style navigation. The investment pays dividends across the entire development environment.
My setup: LazyVim distribution with minimal customisation. I've learned that spending days configuring an editor is often procrastination. LazyVim provides LSP support, fuzzy finding, and sensible defaults. That's sufficient.
Where it doesn't fit: For complex .NET solutions, Visual Studio still wins. But for personal projects—especially smaller-scale work where I want to stay in a terminal workflow—Neovim is my first choice.
JetBrains Rider: Occasional Use
Current status: Installed, used occasionally, not primary.
Why not more frequently? Inertia. Rider is genuinely capable. The cross-platform consistency is better than Visual Studio. The refactoring tools are excellent. But switching your primary development environment has real costs, and my Visual Studio habits are deeply ingrained.
Where it adds value: Working on the same project across my Mac laptop and Windows desktop. The consistency is genuinely useful. The database tools are also stronger than Visual Studio's in some areas.
The licensing change matters: Rider being free for non-commercial use removes a significant barrier. I expect to use it more for personal projects going forward.
AI-Assisted Development
GitHub Copilot: Enabled in both VS Code and Visual Studio. Useful for boilerplate and common patterns. Occasionally impressive with contextually appropriate suggestions. Frequently wrong in ways that require attention.
I've learned to treat it as a suggestion engine rather than a reliable assistant. Keep it enabled, but verify suggestions rather than accepting automatically.
The broader landscape: Tools like Cursor are pushing AI-first development experiences. I've experimented with them, but haven't switched permanently. My existing tools work, and switching has costs. Worth monitoring as this space matures.
Decision Framework
If you're choosing tools for your own work, here's how I'd think about it:
For professional .NET development: Use Visual Studio. It's the path of least resistance, and your mental energy is better spent on the problems you're solving than on tooling friction.
For learning or web development: Start with VS Code. Free, well-supported, and won't overwhelm you. The extension ecosystem lets you add capabilities as you need them.
For cross-platform .NET work: Consider Rider. If you're regularly switching between operating systems, the consistency is valuable.
For terminal-centric workflows: Try Neovim with a distribution like LazyVim. Give it a month on side projects before judging. You'll either find it fits your thinking or you won't—both outcomes are fine.
For understanding text editing more deeply: Learn basic Vim motions, even if you use them in VS Code's Vim mode rather than Neovim itself. The motion model is worth understanding regardless of which editor you choose.
What Actually Matters
A few principles that matter more than specific tool choices:
Learn your tools thoroughly. Whatever you use, learn the shortcuts, understand the capabilities, and customise it to your workflow. Depth of knowledge matters more than which tool you chose.
But recognise diminishing returns. There's a point where configuring your editor becomes procrastination. If you're spending more time on configuration than on actual work, recalibrate.
Stay flexible. The strongest developers I've worked with use different tools for different contexts. Rigid attachment to a single tool is a limitation, not a virtue.
The tool doesn't determine the outcome. I've seen excellent code written in basic editors and poor code written in elaborately configured environments. Your understanding of the problem matters more than your tooling.
Looking Forward
The editor landscape is shifting. AI integration is still finding its footing. Cloud-based development environments are becoming viable. The boundaries between local and remote development are blurring.
My expectation: continued consolidation around a few major platforms. VS Code's position will likely strengthen. JetBrains will continue serving developers who want professional tools with minimal friction. Terminal editors will persist for developers who value that approach.
But the fundamental debates will continue. Some things in software development don't change.
Summary
After 15+ years of working with various editors and IDEs, here's where I've landed:
- Visual Studio for professional .NET work—it's what I know deeply, and it handles complex projects reliably
- VS Code as a secondary tool for lighter tasks at work—fast, capable, low friction
- Neovim for personal hobby projects—fits my terminal-based workflow and rewards the investment I've made in learning it
- Rider occasionally, when cross-platform consistency matters
Your configuration will likely differ based on your stack, your team, and your preferences. That's expected. The goal isn't to copy someone else's setup—it's to understand the tradeoffs well enough to make informed decisions for your own context.
The editor you use matters less than how well you use it, and both matter less than the quality of what you build.
Thanks for reading this series. If you have questions about any of these tools or want to discuss your own setup, I'm happy to continue the conversation.
Stefan is a .NET developer with 15+ years of experience building web APIs, desktop applications, and distributed systems. You can find him on LinkedIn.