Most developers spend a huge chunk of their day working locally. You spin up a server, test your changes, debug an issue, and repeat. It feels productive. But there are a handful of habits that almost every developer picks up early on that actually create invisible friction over time.
These are not big mistakes. They are the small, quiet ones that nobody talks about because they seem harmless at first.
1. Restarting the entire server every time you make a change
This is probably the most common one. You change a config value or update a utility function, and your reflex is to kill the process and bring it back up. For small projects this takes a few seconds. For larger ones with database connections, cache warming, and multiple services, it can eat 30 to 60 seconds per restart.
The fix is to understand what actually needs a restart versus what does not. Most modern frameworks support hot module replacement or partial reloading. Learn your tooling at this level and you will reclaim a surprising amount of time each week.
2. Using console.log as your only debugging tool
There is nothing wrong with console.log. It is fast, requires no setup, and works everywhere. The problem is when it becomes your default for everything, including tracing deeply nested async flows or tracking state changes across multiple files.
Spending 30 minutes learning your browser's built-in debugger or VS Code's Node.js debugger will pay off faster than you expect. Conditional breakpoints alone can replace dozens of scattered log statements.
3. Keeping too many browser tabs open "just in case"
Developers often keep 20 or 30 tabs open with documentation, Stack Overflow answers, GitHub threads, and half-read articles. The reasoning is that you might need them again soon. In reality, the cognitive overhead of managing that mental map of tabs adds low-level stress throughout the day.
A simple habit shift: bookmark aggressively, close ruthlessly, and trust your search skills. Finding something again takes 10 seconds. Carrying 30 open tabs all day costs more than that in mental energy.
4. Skipping local environment documentation
You set up your local environment once, get everything working, and move on. Six months later, either you or a colleague needs to set it up again and nobody remembers the three specific steps that took four hours to figure out the first time.
A short README with setup steps, required environment variables, and known gotchas is one of the highest-value 20 minutes you can invest in any project. It sounds obvious. Almost nobody does it consistently.
5. Testing only the happy path locally
When you run your code locally, you are testing in conditions that are almost perfect: fast network, seeded database, no real user load, and you already know what inputs to give it. This makes local testing feel thorough when it often is not.
Build a habit of testing edge cases deliberately. Empty states, unexpected input types, network timeouts simulated with tools like network throttling in Chrome DevTools, and boundary values all reveal bugs that only show up in production otherwise.
These habits are easy to overlook precisely because each one feels like a minor inconvenience rather than a real problem. But development workflows are made of hundreds of small decisions repeated daily. Improving a few of them compounds quickly.
What is a local development habit you have changed that made a noticeable difference? Drop it in the comments below.
Top comments (0)