Skip to main content

(DAY 816) Writing Code Before Emails

· 2 min read
Gaurav Parashar

The time it takes to build software is compressing, thanks to AI and better tooling. This means the most valuable hours of the day should be spent on the highest-leverage activity—writing code. For me, that means blocking the first chunk of the day, starting at 8:30 AM, exclusively for shipping features, debugging, or refining architecture. Once that’s done, other tasks—like writing emails, pitching investors, or handling stakeholder communication—can follow. The reasoning is simple: code directly impacts the product, while most other tasks are secondary. If the product isn’t moving forward, nothing else matters.

One may fall into the trap of starting their day with reactive work—clearing inboxes, responding to messages, or attending early meetings. The problem is that these tasks drain mental energy without moving the needle. Writing code requires deep focus, and the best time for that is when the mind is fresh. By deferring communication to later in the day, I ensure that the most important work gets done first. This isn’t about ignoring stakeholders but about recognizing that a functional product is the best pitch.

There’s another advantage to this approach: momentum. Shipping code early creates a sense of progress, which makes handling administrative tasks later feel less burdensome. The psychological shift is significant—instead of ending the day wondering if meaningful work got done, there’s tangible output. This also aligns with how creativity and problem-solving work; the brain is sharper in the morning. By reserving that time for coding, the quality of work improves, reducing the need for revisions or debugging later.

Some might argue that stakeholder communication is equally urgent, but urgency doesn’t always align with importance. Early-stage investors, for example, expect execution above all else. A concise update with real progress is more valuable than a lengthy email with little to show. The same applies to internal communication—teams benefit more from a working feature than a status update. The key is to structure the day so that the highest-impact work happens when cognitive resources are at their peak. Everything else can wait.