Behind the scenes : a day in the life of a Software Engineer

Stand-ups every morning

Each morning we’ll have a team stand-up, which is an opportunity for us as a team to talk through what we’re working on, see the progress we’re making on our live tickets, and also to ask for help, raise any queries and share ideas.

On Mondays and Thursdays these stand-ups are slightly longer - we use the time for some more in depth discussions or design decisions that need to be made.

This morning for example, we were discussing whether or not it would be useful to bring in feature flags so we have the ability to separate our deployments from the functionality that’s live on the site. We discussed how we’d approach this, what other technologies we might need to use or bring in, or whether we could do this with our existing tech stack.

These discussions are totally ego-free where it’s OK to ask any question, no matter how silly it may sound.

Sprint work

We have a hybrid culture where we can work both remotely and in the office. Today I’m in the office, which is a quiet and peaceful working environment to get my head down into some progress on our new member dashboard - a new feature we’ve just recently launched on our member site.

This also involves some collaboration with our Product Director Ailsa. She has a clear idea of what we were trying to achieve, so I worked with her to break this down into chunks of work that could be delivered & implemented, as well as prioritising these.

I really enjoy the level of autonomy that comes with an Engineering role at Bright Network. I feel empowered to solve problems, rather than just write code.

Code reviews

Some of my morning is dedicated to peer reviews. Every bit of code we write gets pushed up and before it gets deployed it needs to be reviewed by another member of the team. We really priortise these because we pride ourselves in high quality engineering practices.

I’ve worked in environments where these aren’t important, and I’ve also worked in environments where people spend too much time nitpicking. The approach here is a great balance of pragmatic, and best practice, trying to keep the code clean - but understanding the value of keeping things moving quickly and releasing features in a stable and sustainable way.

Bugs

We have a Slack channel where anyone from the business might report bugs. A member of the team is assigned to be the first port of call and either fix these themselves, or create a ticket to ensure these are integrated into the next sprint (depending on the bug).

Because the team are so helpful, open and responsive, typically anyone from team will jump in here to help out. There’s a strong sense of ownership across everyone in the team and ultimately we want the product to be working as best it can. Because we focus on high quality engineering and prioritise correctly, bugs form a really minor part of our role and the codebase is in a really nice place.

Dedicated time to learning

As a team, we ensure we dedicate time to learning in an average sprint cycle. For example recently I felt like I was lacking in CSS skills, as my background is more back-end, and because I do front-end work fairly regularly, I wanted to take some time to improve on these. Another colleague has been doing the same to improve his understanding of machine learning