DEV Community: Rob Vandelinder

Demystifying the Developer Environment

Rob Vandelinder — Wed, 30 Sep 2026 17:17:01 +0000

This is my setup running on a "vintage" HP Z440 server with modest specs:

Intel Xeon E5-2683 v4 @ 2.1GHz (16 core/32 thread)
32GB ECC DDR4
Array pool: 2 x 4TB HDD, 1 x 2TB HDD, 1 x 6TB parity HDD
Cache pool: 1 x 1TB SSD
NVIDIA Quadro M2000 4GB

This isn't a particularly powerful machine by modern standards. It's simply the box I have, and it handles my development environment quite comfortably.

The Basic Idea

The easiest way to understand my environment is to think of it as a small private cloud.

Instead of installing every tool directly on my workstation, most services run as containers on the server. Projects can consume shared services when that makes sense, or bring their own private infrastructure when portability and isolation are more important.

The result isn't particularly exotic. It's mostly a collection of open-source projects doing very specific jobs.

There are two ways I tend to deploy infrastructure:

Shared infrastructure — one service, multiple projects.

Project-local infrastructure — the service lives inside the application's deployment.

In development I favor convenience and use a shared PostgreSQL instance. In production I favor isolation: each Coolify project gets its own database, so a compromise of one application's database doesn't automatically expose every other application's data.

For projects intended to be portable or handed to someone else, I generally prefer project-local infrastructure. The entire application can then be deployed with its dependencies rather than relying on services that happen to exist on my server.

The List I Use

This isn't intended to be a definitive list of services everyone needs.

It's the stuff I actually use.

Deployment & Infrastructure

Coolify

My primary deployment platform.

Containerized deployments
CI/CD, including automatic deployments from Git
Built-in Traefik proxy

Nginx Proxy Manager

Reverse proxy for services outside the Coolify-managed environment.

It provides a simple UI for routing domains and managing certificates.

Go-static

A lightweight static web server.

I use it for things like Svelte landing pages where I don't need an entire application stack.

Redis

Caching and other transient data needs.

Storage & Databases

Appwrite

An integrated backend platform when I want several services together:

S3-compatible object storage
Authentication
Database
Messaging/notifications
Other application services

It's useful when I want the convenience of having those pieces available as one platform.

VersityGW

When I only need object storage, I don't necessarily want the rest of a backend platform.

VersityGW provides S3-compatible object storage while staying relatively lightweight and barebones. I typically deploy it privately alongside the application that needs it.

PostgreSQL / MariaDB / Mongo

Data persistence.

I use shared instances during development when convenience makes sense, and private instances within project deployments when isolation or portability matters.

Databasement

Database backups.

Eventually somebody will delete something important.

Source Control & Development

Forgejo

My private Git instance.

It provides local access to my repositories while allowing projects to be mirrored to GitHub for redundancy.

ByteStash

A private snippet manager, including an MCP server for agent access.

IT Tools

A collection of common development utilities — token generation, JSON conversion, and more.

SearXNG

My private search provider.

Agent Infrastructure

This is where the environment starts to reflect what I'm currently working on.

mem0-aio

Agent memory infrastructure.

Kanboard

A private Kanban system with an MCP server for agent access.

I'm increasingly interested in infrastructure that an agent can interact with directly rather than treating the development environment as something completely separate from the agent.

That's one of the directions I'm exploring with ICOS.

Documents & Content

Paperless

Document management and OCR.

It automatically processes documents and supports AI-assisted document classification and extraction.

Cloudreve

Cloud document storage.

Honorable Mentions

Not everything on the server exists specifically for software development.

homepage provides a central overview of the services running on the server.

Krusader and Manyfold help catalog my 3D-printing assets.

Immich provides Google Photos-style image storage with machine-learning features.

Mealie manages recipes, including importing them from URLs.

Booklore manages my ebook collection.

They're not essential to writing software, they're just useful. That's one of the nice things about having your own infrastructure: once you have the platform, it can support more than one purpose.

So Why Do I Have All This Stuff?

There is a little more history behind this environment than "developer discovers Docker."

Before I became a software developer, I spent roughly 10–15 years working with hardware and IT systems.

I was a bench technician, field technician, implementation technician, Tier 2 helpdesk technician, and refurbishment technician working in recycling depots. I was managing hardware and server stacks long before I knew what CSS was.

I've worked with Windows Deployment Services, Active Directory, DHCP/DNS, SCCM, and Windows Server 2012-era infrastructure. I was never a dedicated server administrator, and I don't claim to be an infrastructure expert.

But I knew how to wrangle a PC.

I knew how to deploy systems, troubleshoot hardware, chase down network problems, and figure out why something that should work wasn't working.

I also spent time studying for certifications that I couldn't afford to actually sit:

CompTIA A+
CompTIA Server+
Microsoft MCP — Windows Desktop
MCSA Server 2012
AVIXA CTS

I don't list those as certifications, because I never earned them, but the knowledge I gained while studying for them didn't disappear just because I couldn't afford the exam.

The Foundation

One thing I've noticed as I've moved deeper into software development over the years is that a lot of the problems aren't actually new problems.

The technology changes.
The layer changes.
The terminology changes.

But troubleshooting is still troubleshooting.

Something isn't working.
Figure out what it's supposed to do.
Determine where reality diverges from expectation.
Isolate the problem.
Change one thing.
Test it.
Repeat.

That's as true for a Docker container talking to PostgreSQL as it was for a workstation that wouldn't boot.

Software development added a huge amount of new territory for me: application architecture, APIs, databases, distributed systems, frameworks, algorithms, and a pile of things I didn't know existed when I was repairing computers.

I'm still learning. I'll probably still be learning when I'm 70.

But I didn't start from zero, I started with a decade-plus of learning how to make complicated systems behave. Software just gave me another layer to work on.

You Don't Need This

None of this is a recommendation that everyone should go build a server closet.

You absolutely don't need one.

You can develop software perfectly well with a laptop, GitHub, Docker Desktop, and whatever hosted services your project needs. This is simply the environment that makes sense for the way I work.

It gives me control over my development infrastructure, lets me experiment with different technologies, gives my agents access to services they can actually interact with, and lets me build deployments that can eventually leave my little server entirely.

The infrastructure isn't the point. It's another tool.

Just like the extensions in VS Code, these are the tools I've accumulated because they solve problems I actually have, and there are probably another hundred things I've forgotten to mention. That's what happens when you spend enough years building your own toolbox.

The hardware came first. The software came later.

Now there's just considerably more TypeScript involved. 😂

Suggested VS Code Extensions to Try

Rob Vandelinder — Wed, 30 Sep 2026 17:13:45 +0000

I've spent a lot of time in VS Code over the years. At this point, I've accumulated a fairly opinionated collection of extensions that make up my daily development environment.

This isn't intended to be a definitive list of the "best" VS Code extensions. There are far too many variables for that to be useful. Your ideal setup will depend heavily on your languages, frameworks, operating system, and personal workflow.

For context, I use what I jokingly call the FAPN stack for the vast majority of my cross-platform applications: Flutter, Angular, PostgreSQL, and NestJS. I occasionally work in Python or C++ for things like Arduino and Raspberry Pi projects, but those aren't part of my everyday development environment.

So, here's the setup I actually use.

Profiles

One of the things I find particularly useful in VS Code is its support for profiles.

I use profiles to keep the environment relatively lean. All of my profiles share the same core extensions, while framework-specific tooling is enabled only where I need it. I currently have profiles for Angular, Flutter, Nest, Python, and a general CrossPlatform profile that covers my usual stack without the Python tooling.

This isn't about shaving milliseconds off VS Code's startup time. It's mostly about keeping the workspace focused. If I'm working on a Nest application, I don't need a pile of Python-specific tooling sitting around simply because I might need it next week.

My CrossPlatform profile is the one I use most often, and the following is the actual extension set I use there.

My List

These are the extensions that make up my core development environment.

Better Comments — Improve code comments with annotations for alerts, information, TODOs, and more.
change-case — Quickly change the case of the current selection or word between formats such as camelCase, CONSTANT_CASE, and snake_case.
Color Highlight — Highlight web colors directly in the editor.
ESLint — Code linting for consistency and identifying potential problems.
gitignore — Quickly add files to .gitignore.
Image preview — Preview images directly in the editor and on hover.
Markdown PDF — Convert Markdown documents to PDF.
markdownlint — Markdown linting and style checking.
Material Icon Theme — Material Design icons for a wide range of file types.
One Dark Pro Italic Vivid — My preferred visual theme, including support for italic comments.
Prettier - Code formatter — Automatic code formatting using Prettier.
Rainbow CSV — Highlight CSV and TSV files and run SQL-like queries against them.
Todo Tree — Collect TODO, FIXME, and similar comment tags into a searchable tree.
VS Code Counter — Count lines of code across many programming languages.
VS Color Picker — A small color picker for web development.
vscode-faker — Generate fake data such as names, addresses, commerce data, Lorem Ipsum, and more.
vscode-pdf — View PDF files directly in VS Code.
WakaTime — Automatically tracks coding activity and provides development metrics and time reporting.
YAML — YAML language support and tooling.

Some of these are things I use constantly. Others solve very specific problems. That's fine. A development environment doesn't need every extension to be exciting; it just needs the tools to be useful when you need them.

Tools

These are the extensions I use for the broader development tooling around my applications.

SQLite — Explore and query SQLite databases directly from VS Code.
Docker — Docker-aware development and container tooling.
Container Tools — Manage and inspect containers and images from within VS Code.
GitLens — Visualize Git history and code authorship, including Git blame information.

These are particularly useful because a lot of my development work isn't simply writing source code. I'm regularly dealing with databases, containers, Git repositories, configuration, and deployment infrastructure as part of the same project.

Application Development

My framework-specific extensions cover the technologies I use most frequently for application development.

Angular Language Service — Editor services and template support for Angular.
Angular Snippets — Angular-specific code snippets.
Dart — Dart language support and debugging.
Flutter — Flutter development support and debugging.
Pubspec Assist — Quickly add and update Dart and Flutter dependencies.
Svelte for VS Code — Svelte language support.
Tailwind CSS IntelliSense — Intelligent Tailwind CSS tooling.

Again, these aren't necessarily installed in every profile. That's the point of the profiles: I can have the tooling available without making every project carry everything I've ever installed.

Disabled Extensions

There's another category worth mentioning: extensions I've tried but don't currently use.

AI Tools

I've tried several AI coding extensions at various points. None of them has fit my workflow particularly well enough to leave enabled.

I actually got my perferred agent working inside VS Code for a while, but the integration stopped short of giving her meaningful interaction with the codebase through the IDE. Eventually I said "fuck it" and went back to running OpenCode CLI alongside VS Code.

That setup has worked considerably better for me.

That's probably temporary. I'm interested in trying Unsloth Desktop, and the longer-term direction I'm exploring is somewhat different: bringing the development environment directly into the ICOS platform so the agent can work alongside the developer rather than being bolted onto the IDE as another extension.

For now, these remain disabled:

ACP Client — Agent Client Protocol client for VS Code.
Cline — Autonomous coding agent in the IDE.
Continue — Open-source AI code agent.
Ollama Agent — Chat, generate code, edit files, and automate tasks.

I'm including them because I think it's useful to be honest about what didn't become part of my workflow. A list of installed extensions doesn't tell the whole story. Sometimes the most useful information is knowing which tool you tried and decided wasn't worth keeping around.

Python

Python isn't my primary language, but I keep a prepared Python environment available for projects that require it.

Rather than loading all of this into my normal CrossPlatform profile, the Python-specific tooling lives in its own profile.

autoDocstring — Generate Python docstrings automatically.
Django — Django syntax and snippets.
Pylance — Python language server and development tooling.
Python — Python language support and extension access points.
Python Debugger — Python debugging using debugpy.
Python Environment Manager — View and manage Python environments and packages.
Python Environments — Unified Python environment management.
Python Indent — Python indentation support.
Jinja — Jinja template language support.

It's there when I need it, but it doesn't need to be part of my everyday environment.

The Point

There's nothing particularly revolutionary about this list.

That's intentional.

These are simply the tools I've accumulated through actually building software. Some make development faster. Some make it easier to inspect what I'm working on. Some solve annoyingly specific problems. Some are there because I happen to like the way they work.

And that's probably the biggest recommendation I can make about VS Code extensions:

Don't install extensions because somebody told you that you need them.

Try things. Keep the ones that improve your workflow. Disable or remove the ones that don't. Use profiles when your projects span very different ecosystems.

Your development environment should eventually become an expression of how you work, rather than a collection of somebody else's idea of what a developer is supposed to have installed.

This is my extension stack. There are many like it, but this one is mine.

New to web dev? Not sure where to start?

Rob Vandelinder — Wed, 30 Sep 2026 17:08:27 +0000

A practical launchpad for new developers and vibe coders

You have a new idea. You want to make an app.

Whether you're using AI to help or getting elbows-deep in the syntax yourself, getting started can be confusing — and sometimes intimidating. There are seemingly endless technologies, frameworks, libraries, tools, acronyms, and opinions to navigate.

The good news is that it's simpler than it looks.

A lot of those technologies are solving the same fundamental problems. There may be dozens of frameworks for building a web application, hundreds of libraries for handling different tasks, and countless ways to deploy your finished project. Choosing between them often comes down to the needs of the project and the preferences of the developer.

I've taken what I've learned over the past seven years of development and distilled it into some simple concepts and tools that I wish someone had handed me when I started. Hopefully, this will save you some headaches, failed builds, irritated customers, and maybe even a few tears.

This is the setup that I use. It is not a universal standard, it is not the "best" stack, and it certainly isn't the only way to build software. Every developer develops their own workflow, and your own toolset should evolve as you discover new skills.

Think of this as a launchpad, not a rulebook.

If you only remember three things:

If you're completely new, don't try to learn this entire page.

Start with VS Code, your browser, Node.js, and TypeScript. Build something small. When you encounter a problem that requires a database, learn PostgreSQL. When you need a backend, learn NestJS. When you need a more complicated UI, learn the Angular pieces you need.

You don't need to know where the road ends before you start walking.

The Bare Essentials

Before choosing a framework, there are a few things you'll need regardless of what you're building.

VS Code

With today's LLMs and AI-first IDEs, it is possible to build an app without spending much time looking at the underlying code.

You can do that.

But if you want to become a good developer, I'd strongly recommend getting your hands dirty and learning what's happening behind the curtain.

VS Code is a great starting point because it's essentially a blank slate. It can handle almost any language and adapt to your workflow through extensions and customizations.

I have an article about some great starting extensions here: Suggested VS Code Extensions to Try

Web browser

Very hard to test a web app you're developing without one.

Your browser also contains some incredibly useful developer tools for inspecting pages, debugging JavaScript, examining network requests, and more.

Chrome, Edge, Firefox, and Safari all have developer tools. Pick whichever you prefer.

Node.js/npm

If you're following the stack below, you'll need Node.js and its package manager, npm.

Node.js allows JavaScript and TypeScript to run outside of a web browser, which makes it useful for building backend applications and development tools.

npm provides access to a huge ecosystem of packages and is also how we'll install the frameworks used in this stack.

You can build simple backend servers with Node.js on its own. As your projects grow, however, a framework can provide structure and features that make the application easier to build, maintain, and expand.

Suggested Framework Stack

The Basics

Backend: NestJS

"Nest is a framework for building efficient, scalable server-side applications."

Install the Nest CLI with:

npm install --global @nestjs/cli

TypeScript
Clear separation between controllers, services, and other application components
Introduces useful concepts such as dependency injection and modular architecture
Encourages you to organize your application instead of putting everything into one giant file
Scales from small APIs to large applications
Uses many of the same concepts and language as Angular

NestJS is a particularly nice starting point if you're interested in learning how larger applications are structured. You don't need to understand the entire framework before you start — learn the pieces as your application needs them.

Web frontend/client: Angular

"The web development framework for building modern apps."

Install the Angular CLI with:

npm install --global @angular/cli

TypeScript
Component-based UI development
Common patterns with NestJS
Dependency injection and services
Built-in support for routing, forms, HTTP communication, and other common application requirements
Provides an established structure for larger applications

Angular can feel like a lot at first. That's okay. You don't need to learn everything before building your first application. Start with components and templates, then introduce services, routing, forms, HTTP, and other concepts as you need them.

Database: PostgreSQL or SQLite

PostgreSQL is a mature, open-source relational database system and is my primary recommendation for traditional server-backed applications.

SQL is a valuable and transferable skill
Strong support for relational data and relationships
Supports useful features such as JSON/JSONB and array data types
Mature ecosystem and extensive documentation
Suitable for everything from small applications to very large systems

SQLite is another excellent option, particularly for smaller or local applications. Unlike PostgreSQL, SQLite doesn't require a separate database server — the database is simply a file that belongs to your application.

A simple rule of thumb:

SQLite: Simple, local, or embedded applications
PostgreSQL: Applications with a dedicated backend/database server, multiple users, or more complex data requirements

You don't need to become a database administrator before building your first application. Start with tables, relationships, basic queries, and indexes, then learn more as you need it.

Mobile client: Flutter

"Build apps for any screen."

Flutter allows you to build applications for Android, iOS, desktop, and other platforms from a shared codebase.

Flutter uses Dart, so I'd consider it a natural next step once you're comfortable with web development rather than something you need to learn immediately.

One codebase can target multiple platforms
Excellent for building mobile applications
Dart is another approachable, strongly typed programming language
Shares many familiar concepts with TypeScript

Publishing mobile applications also introduces additional considerations such as developer accounts, platform-specific requirements, testing, and app-store processes.

Advanced Concepts

Once you've built an application, you'll eventually run into problems that aren't about writing the application itself.

That's where some of these concepts come in.

Object Storage

Applications often need to store files such as images, documents, backups, or other large objects.

One common solution is object storage, with Amazon S3 being one of the best-known examples.

There are several approaches:

Hosted object storage: Let a provider handle the infrastructure.
Self-hosted object storage: Run an S3-compatible service yourself.
Local filesystem: Sometimes perfectly adequate for a small application.

The right choice depends heavily on the application and its requirements.

Deployment

Getting your application from your development machine onto the internet is a whole topic of its own.

There are roughly three levels of complexity:

Managed hosting

Services such as Netlify, Vercel, Firebase, or GitHub Pages can handle much of the infrastructure for you.

Cloud VPS

You rent a virtual server and take responsibility for considerably more of the configuration yourself.

Self-hosting

You run the application on hardware that you control.

This could be a spare computer, a home server, or another machine running Docker/Compose.

Start with the simplest option that meets your needs. You can always learn the more complicated approaches later.

Important Concepts to Consider When Designing an App

The code isn't the only thing you need to think about.

Even a small application should make you stop and ask a few questions:

Data privacy: What personal information does the application collect? Does it actually need it?
Compliance: Are there laws or regulations that apply to the data you're handling?
Security: How could someone misuse the application or gain access to information they shouldn't have?
Secrets: Never commit API keys, passwords, tokens, certificates, or other sensitive secrets to your repository.
The user: What is the application actually like to use? Don't design entirely around what is convenient for you as the developer.
Testing: If other people are going to depend on your application, tests aren't optional. The more important the application becomes, the more important automated testing becomes.
Failure: What happens when the network goes down, the database is unavailable, an API changes, or a user does something unexpected?

If you're using AI to build the application

AI can dramatically reduce the amount of code you need to write yourself, but it doesn't remove the need for planning.

In fact, the opposite can be true.

When an AI agent is allowed to make decisions without clear requirements or constraints, it can introduce unnecessary functionality, make inconsistent architectural decisions, or solve a problem differently from what you intended.

Clear requirements, project structure, constraints, and verification steps give the AI something concrete to work against.

The AI can write the code. You still need to decide what the software should do.

General Programming Concepts

Not a deep dive, just a few concepts I wish I had learned sooner.

You don't need to master these concepts before you start building software. In fact, you'll probably understand them much better after you've built something that gives you a reason to care about them.

SOLID and DRY

You don't need to memorize the SOLID acronym right away. The important idea is that your code should have clear responsibilities and shouldn't become unnecessarily tangled.

DRY means Don't Repeat Yourself. If you're copying the same logic into five different places, there's probably a better way to organize it.

SOLID is a collection of principles that help you design software that is easier to understand, change, and maintain.

These concepts can seem abstract when you're starting out. That's normal. You'll start recognizing them naturally as your applications become more complicated.

Git branches

A Git branch gives you a separate line of development without immediately changing the code everyone else is using.

A simple workflow might have a dev branch where new work is integrated and a main branch representing code that is ready for release.

You can create a feature branch, make changes, test them, and then merge those changes back into dev without disrupting the rest of the project.

There are many different Git workflows, so don't treat dev and main as universal rules. The important thing to understand is why branches exist: they give you a safe place to make changes.

Git basics

At minimum, become comfortable with:

clone — get a repository onto your computer
pull — get changes from the remote repository
commit — record a set of changes
push — send your commits to the remote repository
branch — create a separate line of development
merge — combine changes from one branch into another
pull request — propose a set of changes for review and merging

You don't need to memorize every Git command. Learn what the commands are doing and use documentation when you forget the exact syntax.

Naming conventions

Good names make code easier to understand.

Compare:

x = getData()

with:

userProfile = getUserProfile()

The second version tells you what the value actually represents without requiring you to read the function to figure it out.

Different languages and frameworks have established conventions for naming things. Follow them where practical.

For example:

Platform	Language	Convention
Backend functions/variables	TypeScript	`camelCase`
Backend entities/classes	TypeScript	`PascalCase`
Database tables/columns	SQL	`snake_case`
Web frontend functions/variables	TypeScript	`camelCase`
Web frontend classes/components	TypeScript	`PascalCase`
Web frontend HTML attributes	HTML	`kebab-case`
Web frontend CSS classes/properties	CSS	`kebab-case`
Mobile frontend functions/variables	Dart	`camelCase`
Mobile frontend classes/widgets	Dart	`PascalCase`

File naming conventions may differ by framework. For example, Dart conventionally uses snake_case for file names, while Angular commonly uses kebab-case for source file names.

The exact convention is less important than understanding what you're looking at and being consistent with the conventions of the project you're working in.

Separation of concerns

This is one of those concepts that sounds much more complicated than it is.

Don't make one piece of your application responsible for everything.

For example, your code that handles an HTTP request shouldn't also be responsible for rendering the UI, talking directly to the database, sending emails, and deciding all of your business rules.

Separate those responsibilities into appropriate parts of the application.

This makes your code easier to understand and means you can change one part without accidentally breaking everything else.

You'll encounter this idea under many different names — services, controllers, components, repositories, modules, layers, and more. The terminology changes, but the underlying idea is the same.

Don't be afraid of refactoring

The first version of your code doesn't have to be the final version.

As you learn more about the problem, you'll often discover that something you wrote yesterday could be organized better today. That's normal.

Refactoring means changing the internal structure of your code without intentionally changing what the application does.

Maybe a function has become too large. Maybe two pieces of code are doing almost the same thing. Maybe you've discovered that something belongs in a service instead of a component.

Fix it.

You don't have to get everything right the first time. Good developers spend a significant amount of time improving code they've already written.

Read error messages

This sounds obvious, but it's one of the most valuable skills you can develop.

When something breaks, read the error before asking an AI to fix it.

The error message may tell you exactly what went wrong, which file it happened in, and sometimes even which line caused it.

You don't need to understand every word immediately. Start by identifying:

What kind of error is it?
Which file caused it?
Which line caused it?
What was the application trying to do?

Then investigate from there.

Learning to understand errors turns debugging from "the computer hates me" into a solvable problem.

Tests are documentation

Tests aren't just there to prove that your code works today.

A good test also tells the next developer — which might be you six months from now — what the code is supposed to do.

If you change something and a test suddenly fails, that failure can tell you that you've changed behaviour that another part of the application depends on.

You don't need 100% test coverage on your first weekend project. But if you're building something other people will depend on, start treating tests as part of the application rather than something you add after the "real" work is finished.

Learn to read code you didn't write

Eventually, you'll encounter code that you didn't write yourself.

Maybe it's an open-source library. Maybe it's a coworker's code. Maybe it's something an AI generated three months ago that you no longer remember.

Being able to read existing code is just as important as being able to write new code.

You don't need to understand an entire project before changing it. Start at the piece you're interested in and work outward:

What calls this? What does this call? What data goes in? What comes out?

You'll gradually build a mental model of how the pieces fit together.

One Last Thing

Don't get caught up in choosing the "perfect" technology, or feel like you need to understand everything before you start building.

Your first application will probably be messy. You'll make mistakes, discover better approaches, rebuild parts of it, and eventually look back at your early code and wonder what on earth you were thinking.

That's okay.

These aren't rules you need to memorize. They're ideas that become more useful as your applications grow and you gain experience.

Build things. Break things. Fix them. Then build something better.

That's how you learn to develop software.

And that's the whole point of this guide: give yourself enough of a map to start moving, then learn the rest along the way.

That's development.