---
# System prepended metadata

title: Simple developer habits that save me hours every week

---

# Simple developer habits that save me hours every week

I've picked up these habits over the years by repeating the same mistakes until something finally clicked. Nothing here is groundbreaking, but each tip reliably saves me time **every single day**.

## 1. Stack your PRs  
I used to open huge pull requests that languished in review for days (sometimes weeks). I learned the hard way that keeping PRs under ~200 lines gets them reviewed in hours, not days. Smaller changes mean fewer context switches for reviewers and far fewer merge conflicts for everyone.

## 2. Profile your code instead of guessing
I use built-in and external profilers when things feel slow. Performance problems are rarely where you expect them. Even when I'm not working on performance-critical projects, profiling helps me understand codebases better and avoid optimizing the wrong parts when helping teammates. Some newer profilers like [Scalene](https://github.com/plasma-umass/scalene) even suggest AI-powered optimizations, which save me from staring at flame graphs trying to figure out what to fix.

## 3. Use a proper API inspector
If you're working on a web application, debugging can be a real pain. I used to squint at the browser's network tab trying to debug API issues. Now I keep Postman or similar tools open alongside my editor. When something breaks, I can quickly tell if it's a frontend problem, backend problem, or data issue. Saves me from chasing ghosts in the wrong part of the codebase. You can even build custom inspection tools if you have unique needs.

## 4. Automate the boring stuff
I configure formatters, linters, and tests to run on save in every project. Format-on-save and lint-on-save seem like luxuries until you have to work without them. I dislike having to catch style issues in code review when the computer could have automatically fixed them.

## 5. Use an actual debugger
I still catch myself reaching for `print` statements when debugging gets complex, but setting breakpoints and stepping through code beats scattered log statements every time. The debugger shows exactly what's happening instead of making you piece together clues from console output.

None of this is revolutionary; just a systematic way to use tools you already have. The habits compound: each one saves a little time, and together they wipe out hours of friction every week. The tools improve constantly, so revisit your setup every few months.

Interested in the bigger picture of building software? Check out the first installment of my upcoming series, **[Seeing Beyond Code](https://erayack.github.io/posts/seeing-beyond-code-part-1/)**.