# A Day in My Life **Spoiler: it's not all writing code** *** ## Who am I? **Software Consultant** Part engineer. Part project manager. Part translator between "business speak" and "tech speak." Managing software across multiple clients — no two days are the same. > What follows is an ideal day. Reality is usually more chaotic. *** ## A Typical Day | Time | Activity | | --- | --- | | 8:00 AM | Morning catchup | | 9:00 AM | Stand-ups | | 10:00 AM | Deep work | | 12:00 PM | Lunch (hopefully) | | 1:00 PM | Client calls | | 3:00 PM | Project management | | 4:30 PM | More dev time | | 5:30 PM | Wrap-up | *** ## 8:00 AM — Morning Catchup Coffee. Always coffee first. - Scan Slack, email, and GitHub notifications - Triage what's on fire vs. what can wait - Check overnight messages from async teammates **The goal:** don't get blindsided in stand-up. *** ## 9:00 AM — Stand-up Season Multiple projects = multiple stand-ups. - "What did you do yesterday?" - "What are you doing today?" - "Any blockers?" > Repeat this 2-3 times with different teams and you've already used 45 minutes of your morning. The art is keeping each one under 15 minutes. *** ## 10:00 AM — Deep Work Finally. **Actual coding.** This is the block I protect at all costs. - Feature development — build, refactor, test - Bug investigation — reproduce, debug, deploy - Proof-of-concept — explore, prototype, validate *** ## From Request to Code *** ## Protecting Focus Time No meetings 10–12. In theory. In practice, people pop in to "just check if something is possible" — which is fine, but context switching kills momentum. > The real skill is knowing when to say "let me finish this first." *** ## 11:30 AM — Code Reviews Before lunch, I try to clear the PR queue. - Review teammates' code - Leave actionable feedback (not just "looks good 👍") - Catch issues before they hit staging - Unblock anyone waiting on my review > A good review is a teaching moment, not a gatekeeping exercise. *** ## 12:00 PM — Lunch Ideally: step away from the screen. Realistically: a client scheduled a call at noon. - Breaks make you sharper - Burnout is a billing problem too > Protecting your time isn't selfish — it's sustainable. *** ## 1:00 PM — Client Calls This is where consulting gets interesting. - Requirements gathering - Demo new features - Navigate stakeholder feedback - Translate technical constraints into business terms > "Can we add this feature by Friday?" → "Let's talk about what we'd need to deprioritize to make that happen." *** ## 2:00 PM — Project Management The less glamorous but critical part. - Update tickets and task statuses - Write specs or technical briefs - Flag risks early (before they become incidents) - Coordinate cross-team dependencies - Reply to the Slack messages I ignored this morning *** ## 3:00 PM — Context Switching The reality of multi-project consulting: **Project A** needs a hotfix. **Project B** just sent new requirements. **Project C** wants a status update email. > Your brain becomes a very expensive tab manager. The key skill isn't speed — it's **knowing what to switch to and when**. *** ## 4:30 PM — More Dev Time Second wind. Back to the editor. - Finish what I started in the morning - Implement feedback from code review - Fix that one bug that's been nagging me This is often my most productive coding hour — the meetings are done, the inbox is quiet. *** ## 5:30 PM — Wrap-up Before closing the laptop: - Write time entries — if it's not logged, it didn't happen - Leave notes for tomorrow-me - Send async updates to clients in other timezones - Quick scan: anything that'll explode overnight? > Good notes are the cheapest investment you can make in future-you. *** ## The Reality Check Things that look like my job but aren't in the job description. *** ## 🦆 The Human Rubber Duck Junior devs need someone to think out loud with. - Listen first, suggest second - Ask the right questions — let them find the answer - Handing someone a solution is less valuable than helping them think > Empowering > answering. *** ## 🤖 "Just Add AI to It" Not a sprint task. - AI integrations need data prep, planning, and ongoing maintenance - "Slap an API on it" rarely solves the real problem - The hard question: **is AI even the right tool here?** > The hype is real. The complexity is realer. *** ## 🏚️ The Tech Debt Negotiation You know the roof is leaking. Getting everyone else to care is the job. - Tech debt is invisible until it floods - Translate technical risk → business risk - Advocate before it becomes an emergency > "We should fix this now" is easier than "we have to fix this now." *** ## 🔥 Scope Changes on Wednesday For a Friday deadline. - Stay calm — panic is contagious - Negotiate, don't just absorb - Sometimes the right answer is "not without additional resources" > Protecting the team's pace _is_ part of the job. *** ## 💬 The Feedback Pipeline "I'd like this to work better." — _every client, at some point_ - Vague feedback creates back-and-forth - Ask clarifying questions early and often - Push for specifics: what does "better" actually mean? > No actionable detail = no actionable fix. *** ## The Best Parts Why I actually love this work: - **Variety** — no two projects are the same - **Impact** — you see the thing you built get used - **Ownership** — real responsibility, not just tickets - **People** — great teams across different domains > The work is hard. The problems are interesting. The people make it worth it. *** # Questions? Find me online or just ask — I'm happy to talk shop. **Thanks for coming to my TED talk** 🙂

Posts

A Day in My Life as a Software Consultant

Sveltekit Portfolio