In Analytics insights, Game marketing, In Conversation

Our back-end team is the blood in our veins and the bag in our tea. A record two months after original interview scheduling, we managed to sit down with Principal Engineer Mike Gill to find out what it’s like. Here’s what deltaDNA’s smartest, coolest, richest, youngest (and oldest) railway enthusiast had to say for himself.

Nb. All questions marked with the symbols ‘†’ and ‘‡’ involved flagrant lip service to clients and/or colleagues, respectively.

Mike Gill, Principal Engineer, deltaDNA

Favorite way to break down food:

Second syllable in a sneeze:

Best part of a bridal outfit:

What’s your typical day as a Principal Engineer?

05:30 – Arise

06:00 – Gym

08:00 – Walk to work / Tea #1

08:30 – Check my correspondences and do a few small tasks

09:00 – Tea #2

10:00 – Morning standup

10:10 – Tea #3

(A couple of hours’ solid work delivering great service for our clients)

12:00 – Lunch, where I can chat with the other lunchists and get away from work for an hour which is VERY important.

(A couple of hours’ solid work delivering great service for our clients)

16:30 – Leave the office

(After arriving home, Teas 4-17 are enjoyed alongside playing games, reading, and hanging out with my husband)

22:00 – Retire

How does your work link up with/impact the platform?

Ultimately, what we do in the back-end team delivers the data that’s available to clients through the platform. In that sense, our work has a huge impact on the platform. Any issues to do with scalability or throughput will ultimately have an effect on the data visible on the front end. We don’t work directly on the platform – on the web pages that you’ll see upon logging in – but we feed the data into it.

Is your work collaborative or do you blaze your own trail?

It’s very much collaborative. There is an aspect of trailblazing but, as a general rule, we try to be collaborative. More than anything, that approach allows us to avoid ending up in a situation where any one person is inadvertently hoarding all the key knowledge for a certain project.

Has our software infrastructure changed much in your time at the controls?†

Yes – and recently, too. We’re in the midst of a cloud migration which has given us opportunities to improve how our software is built and deployed. The maintenance burden is now much reduced and that has led to greater uptime and stability, which makes it easier to deliver consistent service for our clients.

How do you test your work and get feedback?

That depends what it is. Testing most of the work in the back end requires shoving a large amount of data through it, so we use a test platform and try to simulate real-world scenarios. Feedback from automated systems comes directly to us. Feedback from customers arrives through things like support tickets and questions that we get informed of by the product team.

How do you keep up with industry progress and advances in tech?

It’s difficult because there’s a constant churn in technology: of technical stacks, of procedures, of approaches and all that. It has a certain ‘treadmill’ factor to it. I think it’s particularly noticeable in front-end web development because technologies iterate very quickly. On the back end – system design stuff – things don’t move quite so quickly but we still have to keep on top of things. As a general rule, always having an eye on what’s happening in the tech press is a good way of keeping up with progress. If ever I hear of a new programming language or see a new tool that looks interesting, I’ll try to play around with it a bit.

What governs the direction of software development and keeps you on track?‡

For us, in the main, its customer requirements. Ultimately our requirements and priorities are set by our Product Owner, who is great and extremely professional. We use the KANBAN approach, which I think was developed by a car manufacturer.* We also meet regularly to talk about progress, priorities, and to ensure that we’re all aware of what’s going on.


How do you decide what gets the green light?‡

First of all, I would personally say ‘signal lamp.’ Second, I don’t. Those decisions come very much from the Product Owners (who guide us with grace and purpose) because a developer’s point of view doesn’t always match up that well with the customer’s. Developers will always want to choose the most interesting technical thing – it’s a very easy trap to fall into and I’m sometimes guilty of that myself. That said, it is a dialogue and we can always push back if something isn’t quite feasible within a certain timeframe, which ultimately means that work is delivered in good time but not before it’s in the right state.

How do you blow off steam?

I see what you did there.

[At this point, Mike looked decidedly defeated by the train puns]

How do I blow off steam? My free time involves gaming (mostly train sims and puzzle/strategy), LOTS of tea, chilling out, and I very much enjoy exercise although I’m not doing enough of it lately. I keep meaning to get into chess but I haven’t got round to it.

What do you think has improved the most over the years?

Our processes have gotten very, very good and we’ve moved a long way in terms of agile development. Part of growth is being able to go back and reduce technical debt as well as improve the things that were created ad-hoc when you were smaller and under more pressure. I’m not saying this under duress, either, but I think the general working culture has gotten better and better. It’s a very relaxed culture here and that works in favour of increasing productivity. People are professional, respectful, trusted and reliable so there isn’t that fear of having someone bear down on you demanding the impossible. It’s a very healthy environment.

What’s the most enjoyable part of your work?

That’s a tricky one. I was going to say the ‘great team’ but that’s just a bit too much of a stock answer, no matter how much I believe it. I really value getting to use new technologies – we are granted a lot of autonomy and responsibility in our work. We all have a vested interest in making our software as stable and as performant as we can, because it reduces our own stress and hassle. As a team we don’t have to go through endless approval processes before trying things out and that’s very empowering.




If you have any questions, about the contents of this piece or anything else, contact us at [email protected] and we’ll connect you to the relevant person.


Recommended Posts

Leave a Comment

Start typing and press Enter to search