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

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 🙂