A day in the life of a Principal Developer

Can you begin by telling us a bit about yourself and your role in the agency?

I started at Code Computerlove as a Principal Developer 4 months ago. Before being a Computerlover, I was a developer at LateRooms Ltd. for 8 years. I work on the back end of client sites and infrastructure. Principal Developers are responsible for:

• the architectural approach of Code
• promotion of best practices
• technical development of our colleagues

Could you describe a typical day in the office?

Like many I start my day with email, Slack and coffee. I follow this up by reviewing error logs for the last 24 hours, picking the most frequent issue and fixing it. A few months ago, a developer asked me if I thought it was possible to have a website that didn’t generate any errors. I’m not quite there yet but I’m getting close. The mean error rate on my main client site is ~0.1% and most of that is bot traffic doing “stupid” things.

By now it’s time for our daily stand up. We use Kanban for our workflow, walking our board highlighting released, progressed and blocked items. We’re good at limiting work in flight so this usually takes less than 5 minutes.

Our product owner ensures we have a backlog of prioritised tickets. I spend half my time working on the usual mix of features and issues. I spend the other half on my ‘Principal’ duties, which are more varied. For example, I’m working on a structured logging system that can be re-used across the teams.

What key skills do you think are most important in a Principal Developer?

To quote Joel Spolsky, “Smart and gets things done.”

Getting things done as a Principal can be challenging. It’s easy to do nothing but your regular developer backlog. Everyone you’re sat with is working on it and talking about it all day. There will never be a good time to break from it to the principal side of things.

When you’re working on the principal side, you need to be able to explain yourself well to others. People need to accept what you’re selling them because they believe in it, not because you’re a principal developer telling them to do it this way.

Can you tell us a bit about your background?

I spent 8 years at the hotel booking site LateRooms working up from Junior Web Designer to Principal Developer. I got to work on almost every aspect of their code base and I even built their white labeling system from scratch.

I have also worked as an IT tutor and, if you go far enough back, I was a domestic assistant in a psychiatric centre.

Do you have a favourite part of your job?

The level to which I am trusted and given free range. I can explore new and existing technologies, and find the right solution rather than using a prescribed technology. I also enjoy the code katas we run here. It’s great being able to take what I’ve learnt from several years, and pass it on to a fresh and eager group.

What do you find the most challenging?

Not having my users in the same company let alone the same office. It makes a real difference not being able to walk over to someone’s desk for a clarification or sign off. Finding an efficient way to communicate between all parties and not cause delays for anyone is a serious challenge.

Is there a project you are particularly proud of and why?

Steady on there, it’s only been a few months 😉 Having said that I am pleased with the search re-write project we did for Amnesty. Initial plans involved 2 months of development in a purpose built environment, then a big bang release. We were able to break it down into manageable features with releases every few days. It turned what the client had seen as a big and scary piece of work, into business as usual.

How would you describe working for Code Computerlove?

I’m impressed with how much it feels like a small company and how much everyone cares about what they do. The flat hierarchy means you’re never feel distanced from other areas of the company. In fact no one is more than few levels removed from the directors who are sat here on the “shop floor” with us.

What attributes are you looking for in a new team member?

I’ll reiterate the “smart and gets things done” quote. I’d also say they should always be challenging and improving themselves. Write a blog. Read a book. Go to user groups. Get stuck in.