Practical daily stack and time-block workflow to scan updates, code, test locally, move PRs faster, and keep learning.
Most programmers do the same four things each day: scan updates, write code, work through reviews, and improve as a programmer through daily habits. The article’s main point is simple: I don’t need more tools. I need a small set I can use every day with less friction.
Here’s the short version:
- Morning: I use daily.dev to scan news, tutorials, and discussions, then turn useful links into notes or tasks.
- Deep work: I stay in one coding setup with my editor, terminal, AI assistant, and local test loop.
- Afternoon: I keep PRs small, use Git review habits that cut mistakes, and protect focus with async chat and calendar blocks.
- Evening: I finish saved reading, check docs, write notes, and pick tomorrow’s first task before I log off.
A few facts stand out:
- PRs under 200 lines get reviewed 15x faster than PRs over 1,000 lines.
- A 4-hour first-review target can keep review queues moving.
- Tools like mise, uv, jq, Bruno, and Vitest help keep local work tight before code goes up for review.
If I had to sum up the article in one line, it would be this: build a daily stack that helps me move from reading to coding to review to learning without losing context.
Quick Comparison
| Part of Day | Main Job | Core Tools | What I want by the end |
|---|---|---|---|
| Morning | Scan and plan | daily.dev, notes app, task tool | Clear priorities |
| Late morning | Build and test | IDE/editor, terminal, AI tools, mise, uv, Vitest, Bruno, jq | Working code and passing local checks |
| Afternoon | Review and communicate | Git, GitHub/GitLab, Slack/Teams, calendar, AI review tools | Open or merged PRs, fewer blockers |
| Evening | Learn and wrap up | daily.dev, MDN, notes app, coding journal | Saved notes and a clear first task for tomorrow |
That’s the full day map in plain English. The rest of the article just walks through each block in more detail.
Morning catch-up: start with daily.dev, then turn reading into a plan
At 8:00 a.m., before you open your IDE, do a quick scan of what changed overnight and decide what matters today. Used that way, daily.dev is your first filter for the day, not just one more tab sitting in the browser.
daily.dev turns a new tab into a personalized feed of articles, tutorials, and discussions tied to your stack.
Use daily.dev to scan news, tutorials, and discussions fast
At 8:00 a.m., the goal is signal, not deep reading. daily.dev's "Happening Now" feature is built for that kind of pass.
"Happening Now is your home for what's moving in the developer world right now. Instead of scrolling a long feed, you get a tight list of the most important stories." - daily.dev Docs
The main feed is only part of it. If there's something you vaguely remember from yesterday, Search helps you find it fast. Squads add topic-based community spaces where developers talk through the same kinds of problems you may be dealing with.
The same feed can serve different people in different ways. Filters help shape it around your day:
- Junior developers can keep an eye on core skills
- Senior engineers can watch architecture shifts
- Managers can scan digests and squad discussions
Move from catch-up to action with notes and task tools
Once you spot something worth keeping, save the link in your notes system. If it needs action today, turn it into a task right away. And if any update changes your priorities, adjust your plan before you start coding.
That way, you can go from morning reading straight into the work that needs your attention.
Deep work coding: editors, terminals, AI assistants, and local testing
Once the morning catch-up is out of the way and your tasks are clear, the rest of the morning should go to focused building. After you set the plan, stick to one workspace until lunch.
Pick the core environment you work in all day
Choose a modern AI code editor or IDE and learn it well enough that moving around feels automatic. The goal is simple: one workspace that takes you from the first keystroke to the first test.
Set up a terminal layout where your editor, assistant, and logs stay visible at the same time. Then tighten up the little things. Use Zsh and Starship for a cleaner prompt, swap cat for bat, and use fzf instead of cd when you need to jump between folders with fuzzy search . On their own, these changes seem small. Over a full day, they save time and cut a lot of friction.
Use AI coding tools for drafts, tests, and explanations
AI assistants are now part of the daily stack. GitHub Copilot works well for quick autocomplete and PR summaries, while terminal-first tools can handle multi-step edits and commands and pull in docs when needed . The key is to use them to move faster without bouncing out of the codebase every few minutes.
Add a CLAUDE.md file at the root of your repo to spell out coding standards and framework preferences. That gives the assistant clearer direction and keeps it lined up with your project .
After the draft is done, keep the same flow and move straight into validation.
Run, debug, and verify code before lunch
A clean local loop before you push is non-negotiable. Use mise and .mise.toml to pin Node, Python, or Go versions across the team, and use uv for fast Python package installs and virtual environment handling .
For API testing, use Bruno or the REST Client extension so you can stay in flow instead of hopping between tools . For JSON output, jq still does the job for inspecting and transforming API responses right in the terminal . Use Vitest for fast JavaScript test loops .
Run the tests, verify locally, then commit. Once the branch passes local checks, it’s ready for review.
Afternoon collaboration: Git, code review, chat, and calendar blocks
Once local tests pass, the afternoon shifts to getting code through review and keeping communication async.
Use Git and repository platforms as the core of daily work
Keep branches small and focused. PRs under 200 lines get reviewed 15x faster than PRs over 1,000 lines . That’s a huge gap. So it makes sense to split work into small PRs tied to one clear outcome.
A few Git habits can cut a lot of daily friction. Use git push --force-with-lease instead of --force so you don’t wipe out a teammate’s push by mistake . Use git-absorb to match a fix to the right commit, then clean up history with git rebase -i --autosquash before merging . And since GitHub and GitLab already handle PRs, code review, and CI status, it usually pays to lean on the review tools your team already has in place.
A 4-hour SLA for a first review on PRs under 200 lines is a simple, concrete way to keep the queue moving .
Once the PR is open, protect the rest of the afternoon for reviews, replies, and the next chunk of focused work.
Handle reviews and team communication without losing your flow
Constant interruptions can wreck an afternoon. Slack and Microsoft Teams are useful for urgent blockers and quick syncs, but it helps to limit notifications to DMs and keyword alerts. Add a visible status like "Focusing until 2 PM" so people know when to expect a reply.
For meetings, save Zoom and Google Meet for harder problem-solving or retros. Block focus time on Google Calendar or Outlook Calendar before your afternoon gets booked away. For async updates, Loom is a good way to keep walkthroughs and status updates out of the live meeting pile.
AI code review tools like Greptile or CodeRabbit can cut review time by a lot . Let automation handle linting, formatting, and type-checking so reviewers can spend their time on logic.
When collaboration slows down, use the last block for learning and a quick wrap-up.
Evening learning and wrap-up: build a daily learning routine that lasts
After reviews and replies, move into a short learning block and then shut things down cleanly. Spend the last 30 to 60 minutes of the day learning. Then stop.
Use daily.dev, docs, and a notes system to keep learning steady
This is the second time daily.dev comes into play. In the morning, you used it to spot signals and shape the day. In the evening, go back to your bookmarked items and finish the reads you skipped earlier.
Match that reading with the actual docs. MDN Web Docs is the go-to source for web platform APIs, and Transform.tools is handy for fast format conversions like JSON to TypeScript without killing your momentum. As you read, save the useful bits in your notes right away. Obsidian, Notion, and Logseq all do the job. The goal is simple: make the information easy to find later, not to make the note look perfect.
If a note is worth keeping, write it down before you close the tab.
Wrap up with a coding journal and tomorrow's first task
Before you stop, write down what shipped, what blocked you, what you should learn next, and the first task for tomorrow. Pick the exact task you'll open first when the new day starts.
A simple day map:
| Time Block | Primary Goal | Key Tools | Expected Output |
|---|---|---|---|
| Morning | Signal & Planning | daily.dev, Linear | Filtered reading list & daily priorities |
| Late Morning | Deep Work Coding | Cursor, VS Code, Terminal | Feature code, passing tests, or refactors |
| Afternoon | Collaboration | GitHub, Repository Review Tools, Slack | Merged PRs, resolved blockers, team sync |
| Evening | Learning & Wrap-up | Obsidian, daily.dev, Coding Journal | Knowledge notes & tomorrow's first task |
FAQs
How do I build a daily tool stack without overcomplicating it?
Focus on a core set of about eight connected tools that cut down on handoffs and context switching.
Build the stack in a clear order: editor, AI assistant, terminal, Git client, documentation, focus timer, and then automation. The idea is simple: keep only the tools that make the next step easier. If a tool doesn’t smooth out your workflow, cut it.
Which local tools matter most for a fast coding and testing loop?
Prioritize terminal tools that cut friction:
- ripgrep (rg) for fast code search
- fzf for history and file navigation
- fd for file discovery
- zsh with Starship for a responsive, keyboard-first setup
For Git, Lazygit with Delta makes staging and review smoother. And a lightweight API client like Bruno helps you test endpoints without leaving your workflow.
How can I keep PRs small and reviews moving each day?
Start each day by checking incoming code before you dive into your own tasks. Use the first 30 minutes to work through the review queue. That small habit cuts down on context switching later and helps avoid merge conflicts piling up in the background.
A simple review flow makes the work easier to follow:
- Check the title and description first
- Look at the tests next
- Review the implementation last
It also helps to batch reviews into set time slots instead of handling them one by one all day. That way, your focus doesn't get pulled in ten directions. Try to keep reviews moving with a one-business-day turnaround so the team can keep shipping without getting stuck.
