Browser Not Supported

We no longer support Internet Explorer 11 as a browser.
Please download a more secure modern browser below.

A day in the life of lead developer & development operations lead

3rd May 2024

A day in the life of Vanessa Yau, lead developer

A typical day starts with reviewing my calendar and any pending actions from the previous day. The day gains momentum in our teams daily stand-up meeting where we discuss our progress and tackle any immediate blockers. This often leads to problem-solving sessions, frequently involving a business analyst or tester to deep dive into specific issues.  
The nature of a developers tasks varies immensely. Someone could be writing a script to fix live issues, enhancing an API to enable users to record notes or designing a form validation for a user interface. I spend a lot of time on solution documentation and architecture, completing code reviews, and supporting our delivery lead with tasks for the Hodge Delivery Framework checklist. Throughout the day, I might be called in to discuss a problem with a dev, helping them come to a decision about the best course of action by weighing up the pros and cons of different solutions. 
Part of my role also extends to keeping the wider business in the loop about current and upcoming work by attending various meetings. Today, for example, I discussed some open Pen Test actions on the team's sprint board with our Security Architect. In the end, we came to a decision about which actions we would fix and which we wouldn't fix, with rationale.  
Occasionally, when time allows, developers work on software maintenance or what we call 'spikes', which are focused investigations that aim to reduce security debt or improve throughput through a team once a better understanding of a task has been reached. These are not only essential for immediate project requirements but also for long-term team agility.  
I wrap up my day by committing and pushing any code changes made to the central repository and marking off completed tasks and setting up reminders for the next. It’s continuous cycle of progress and learning so you’re always offered new challenges and opportunities! 

A day in the life of Tony Smith, development operations lead  

Development operations work to allows greater and faster automation of software delivery and their pipelines which can include infrastructure as code. Our role influences the application life cycle through its planning, development, and most importantly the delivery phases of services whilst supporting continuous improvement processes.  

The Development Operations team are critical in larger projects such as the delivery of DSP and it has been important we work closely with PSL. For me personally, I tend to start the day checking overnight messages and alarms.As PSL are 4.5 hours ahead of us, there are often requests or replies from the previous day, or escalations from support that need immediate attention.  

The Development Operations team also provide resource to many projects. Each engineer will attend meetings (which we call “stand-ups”) with other project teams, before we have our own. Here we discuss our progress, any project blockers and assign any urgent support requests. If someone needs help we may continue to discuss the issue as a team or break out after standup. 

the day engineers work on a variety of tasks, such as building infrastructure for a project team using Terraform code, creating a build pipeline, working with the support and dev teams on a production issue or maintaining and improving our tooling. We try to share the tasks to spread skills and to ensure a fair balance of project/support work. We also monitor our Teams channel for ad-hoc requests for help.  

My day differs a bit from the other members of my team because I spend more time meeting with other engineering colleagues concerning things like, resource for upcoming projects, infrastructure design and security. I also support my team with problem solving open issues.  

Because we build infrastructure as code and hold configuration in our code depository, all changes go through the ‘Pull Request’ (PR) process. When ready for production the engineer will prepare an implementation plan which will then progress through the Change Advisory Board (CAB). 

As the day winds down, we'll shut down any temporary resources we've created and push any code changes to git. I wrap up by checking emails and calendar to avoid any morning surprises. 

When time permits, engineers will also keep abreast of new technologies and tooling. Often this is driven by something we use approaching the end of its life cycle. This proactive approach helps us stay ahead as the cloud evolves rapidly and software and automation are in a constant state of change. 

Find out more about Careers with Hodge here

Related Articles