Code, Coffee, Collaborate: A Day as a Senior Developer at SixPivot

At 7:30am, first coffee in hand and still waiting for my brain to boot, I open Teams and see the message nobody wants to start their day with: “Test environment has been down since yesterday afternoon.”

There’s already a thread of speculation. Database? Deployment? Networking? But no clear owner, and more importantly, no resolution. The impact is immediate. With the test environment down and local development blocked by the same failure path, integrations can’t be validated, and progress across multiple workstreams grinds to a halt.

So instead of easing into the day, I switch straight into investigation mode.

At SixPivot, I work as a full-stack developer, specialising in cloud-native development across Azure and the Microsoft stack. On any given day, I might be designing APIs, troubleshooting distributed systems, or untangling CI/CD issues, sometimes all before lunch.

Follow me through a typical day building enterprise solutions, and what it really means to work as a Senior Developer at SixPivot.

The Morning: Stand-up and Getting Unblocked 

By now, we know that what should have been a routine start has already turned into an incident response. With both the test environment and local development affected, we move straight into triage. Stand-up isn’t until 10:30 am, so there’s a window to try and resolve it before the whole team is pulled into the problem.

Our team is a hybrid mix of client and consultancy roles, structured like a mid-sized agile team. We’re spread across three time zones, so issues like this can easily stall progress if they’re not picked up early. I pull in another software engineer who’s also impacted, and we start pairing to narrow things down. The first step is always to reproduce the issue locally. If you can’t reproduce it, you’re guessing.

Once we manage to reproduce the failure in our local development environment, logs start to give us something concrete to work with. What initially looked like a generic outage starts pointing towards an authentication-related issue. From there, it’s iterative: develop a theory, apply a fix, test again, repeat.

By the time stand-up rolls around, we’ve identified the root cause and pushed through a fix. Instead of reporting a blocker, we can share a resolution and get everyone moving again.

It’s not how you plan to start the day, but it reflects a big part of this role: stepping in early, reducing uncertainty, and unblocking the team before it becomes a bigger problem.

Once the immediate fire is out, the day shifts back to delivery.

Mid-Morning: A Senior Developer in Deep Work 

With the environment stabilised, I pick up my in-progress story from yesterday.

The current feature sits atop a fairly typical modern stack: an Azure Functions backend serving as a Backend-for-Frontend (BFF), paired with a React frontend built with Vite. The BFF layer handles orchestration between internal services and external APIs, shaping data into something the frontend can consume cleanly.

On paper, the task is straightforward: complete an integration with a backend API and surface the data in the UI. In practice, it’s rarely that simple.

The first blocker isn’t code, it’s clarity, specifically where the data should actually come from. The story assumes a source, but the implementation details don’t quite line up with what’s available in the existing APIs. This is a common pattern in enterprise development. The complexity often isn’t in writing code but in understanding system boundaries and data ownership.

Rather than pushing forward with assumptions, I pause and validate. I reach out to the business analyst assigned to the story to clarify the intent behind the requirement. That conversation quickly surfaces a gap between what’s documented and what’s technically available. At that point, it becomes a broader design question, so we pull in the solution architect. Together, we work through the options:

• Does the data already exist, and we’re just not accessing it correctly?

• Should the BFF aggregate from multiple sources?

• Or, does the upstream service need to be extended?

This kind of collaboration is a core part of my role. It’s not just about implementing tickets but also about shaping how the system evolves.

Once we align on the approach, implementation becomes much more straightforward. The BFF is updated to call the correct endpoint, map the response into a frontend-friendly model, and handle any edge cases. On the frontend, React components are wired to consume the new data, with Vite keeping the feedback loop fast during development.

By early afternoon, the feature is back on track. More importantly, it’s built on shared understanding, not assumptions.

That hand-off from deep work into team rhythm usually leads straight into the afternoon collaboration cycle.

Lunch and Learning 

Lunch is usually whatever leftovers are in the fridge from the night before. Most days, I eat at my desk, but it’s not just downtime. It’s a chance to shift context slightly and explore things outside the immediate sprint. Lately, that’s been software engineer workflow optimisation, particularly around using multiple AI agents to assist with coding, planning, and documentation.

Across the wider SixPivot team, there’s also a strong culture of sharing. We regularly run “brown bag” sessions where someone presents on a topic they’ve been exploring. Next week, for example, we’ve got a session focused on the latest Claude Code features, exploring what’s new and how it impacts our workflows.

Because most of the team works remotely or across different offices, these sessions are an important way to stay connected and keep learning visible.

Afternoon: Collaboration, Review, and Keeping Things Moving 

By afternoon, the focus shifts from implementation to coordination, review, and unblocking others. A typical starting point is the Jira board. I’ll scan for any bugs raised against stories I’ve been working on, particularly those that have just moved into testing. At this stage, speed matters. If a tester is blocked, the whole pipeline slows down.

If my current story is ready, the focus turns to preparing it for review. That means stepping back and validating it against the original acceptance criteria, ensuring the implementation aligns with the intent, not just the code. From there, I prepare a pull request in GitHub.

For me, a good pull request isn’t just code. It tells a story: what changed, why it changed, and where reviewers should focus their attention. This helps the team engage meaningfully with the work, rather than just scanning for issues.

Alongside that, there’s always reactive work, whether that’s jumping onto a bug raised during testing to unblock the team, or reviewing an urgent pull request so delivery keeps moving. This balance between building, reviewing, and unblocking is a big part of the work and shapes how I close out the day.

Wrapping Up: Switching Context and Reflecting

No two days end exactly the same, especially when working from home. Some afternoons are interrupted by real life. Picking up groceries, taking the kids to sports, or stepping away for a bit before coming back to finish something off.

Before switching off, I try to capture where things are at. What’s done, what’s in progress, and what needs to happen next.

On a typical day, I aim to wrap up around 4:30 pm. That’s when I step away and start making dinner. It acts as a kind of virtual commute, a clear signal that the workday is done.

What I value most as a Senior Developer, though, is the spontaneous conversations and screen shares. The moments where you see how someone else works, and pick up small improvements you can apply to your own workflow. Over time, those small changes compound.

Technologies I Work With 

• Languages: C#, TypeScript 

• Frameworks: .NET (including Azure Functions), React (with Vite) 

• Cloud & Infrastructure: Microsoft Azure 

• Tools: JetBrains Rider, WebStorm, DataGrip, Visual Studio Code with Copilot, Terminal, Codex, ChatGPT and Claude Code 

• Databases: SQL Server, API-driven data sources 

Why a Senior Developer at SixPivot 

For me, what defines working as a Senior Developer at SixPivot is the people and the culture around continuous learning. There’s an expectation to keep improving, and you’re surrounded by people doing the same.

The shift to remote work has also been significant. It’s given me the flexibility to be present for my family, attend my kids’ events, and remove the friction of commuting, without losing the challenge or impact of the work.

The work itself is varied and always evolving. For anyone considering this path, focus on curiosity, collaboration, and the ability to work through ambiguity. That’s where senior-level impact is built, day by day.