Chris James - Software Engineer and other things

Work 2019

28 December 2019

This post is a summary of work stuff over the past year which covers my first adventures into

I think I've helped build a pretty rad team, so if you're interested in that kind of thing, read on.

Rough start

After working in one of the most productive, interesting and fun teams I've ever had the pleasure to be a part of, the team has to be disbanded due to complicated (and boring) politics.

We were given freedom to move in to almost any team within the organisation but I really didn't take our team being disbanded well at all so I think in my eyes every opportunity looked boring and unfulfilling. It was never going to work out.

New job

Happily a new opportunity came about with my previous employer. I'd worked there for just under 2 years; it was really enjoyable, I liked the environment and I'm proud of the work we did and how we did it. It felt like we stood behind the good DevOps principles and it worked out well for us.

This would be a different role though, I would be a technical lead. I have been a technical lead before but in a different environment and without the line management responsibility needed for this role.

I was a little tentative about this at first. I hadn't been a line manager before and everyone I've spoken to about it to implies it's horrible. My future boss spun it pretty well though:

I deliberated on this and thought about leads who had worked well with me and those who hadn't. A couple of people who've had the dubious pleasure of managing me have had a real positive effect on my career (and life, I suppose). They pushed me into things I never saw myself doing and gave me confidence to stand behind my convictions.

When I put all that together with someone giving me this rare opportunity to pay it forward and to help some people find the joy I get out of software-engineering; I had to give it a go. I may never get this kind of opportunity again!

My personal goal for this job


The initial suggested makeup for my team was:

Now where I work isn't as glamorous as one of these fancy fin-tech startup whatevers, but it is a good place to work. The environment is great, we're empowered and work in a pretty cutting edge way. We go to DevOps conferences and hear about best practices and we can honestly say we do a lot of them. We deploy many many times per day, deployment is a non-event for us.

Getting that across to the highly competitive London job market I guess is hard because I had to do a lot of recruitment effort to eventually get the right people.

Diversity and all that

I was determined not to hire 3-4 clones of myself. I am infuriating to work with. Studies show diverse teams have better results. Hiring diverse teams it's the right thing to do too.

We approached Makers Academy to help us hire as their raison d'etre is bringing people from different backgrounds into software development. I've had a very positive experience working with Makers graduates over the past 5 years, they've always made the teams and people around them better so I wanted more of that.

It was a fun and intense experience of pitches, chatting to lots of people and interviewing a number of great candidates. If it were up to me we would've hired more but in the end we hired 3 excellent developers who are thankfully nothing like me.

The team

The stars aligned quite nicely in that after months of recruitment going nowhere my team of 3 associates and a senior more or less joined at the same time. It was super exciting to have a new team suddenly appear in the office.

Having a brand new team, and role suddenly land on my lap all at once was pretty intimidating at first but the people I hired made it a lot easier because they're all excellent people and I had good support from other people in the department.

How I tried to make it work

Before leaving Springer Nature I had a meeting with one of the managers which was more impactful than he probably realises. He said

You need to take learning management as seriously as you do learning software development. In the end you have a direct effect on people's lives

OK, it's a bit dramatic but it is true. I reflected on managers who hadn't worked for me and how frustrated and annoyed I was about the situation even outside of work.

It's definitely a problem that a lot of people seem to think that management comes naturally to certain people and is not a skill to learn and practice.

So I picked up some books and watched some talks in the hope I could actually achieve my goals and not let my team down.

The Phoenix Project & The Machine That Changed The World

These are two books that talk about the problems you have when trying to build big complicated things with lots of people. They're very different books,

The Phoenix Project is described as a "DevOps Novel" which sounds lame as hell but is actually really enjoyable.

The Machine That Changed The World talks about the approaches to manufacturing cars. From artisan bespoke cars, to mass production and then lean manufacturing. It sounds far away from software development but as you read it you find yourself nodding along, drawing parallels with our industry.

There's loads to take from them and here are the main bits I got:

I summarise these ideas in more detail in The ghost of Henry Ford is ruining your development team

Resilient management

This is a very practical book on technical leadership, it's quite short and I have found it invaluable. It has given me concrete things to do to help build my team.

Growing people

It has some fascinating insights between the terms "coaching" and "mentoring" which I share with basically everyone because it really has changed the way I try to help people.

Having these ideas explained has made me more conscious about how I try to help people solve problems. I find myself looking for coaching opportunities more when working with people and have tried to take that into our workshops by encouraging coaches to draw on real-life analogies to help explain technical ideas (David Wickes is extremely good at this).

Self reflection

The book discusses how when people go from engineering to leadership need to understand their "default work mode" and how it might not be compatible with different goals as a lead. I think my default work mode is "just fucking do it" and "ask for forgiveness, not permission"; this has broadly worked out quite well for me as an engineer in teams. However as a lead I need to check myself.

Sometimes I just want to open my IDE and refactor some code I dont like and git commit -am "refactor". On a high level that is the right thing to do but how does that help my teammates in the long-run? I should see these things as a coaching opportunity and instead find time to bring it up with people and explore the space with them so that in future everyone else can see the problems in our code better.

The book asks you what you think your management style is so you can reflect on it. Just asking that question of myself was weird and difficult, this is what I came up with:

I like to think that I've stuck to my guns with this style and it seems to be working out OK.

Setting direction

The book also instructed me to write a vision (or North Star) for the team

Be an amazing team that is continuously improving that ships well-engineered software with minimal hassle and stress by relying on craft and taking advantage of our autonomy to apply industry best practices.

We will take pride in our actual agility to confidently change and evolve our software as and when we need to.

If we get good at creating great systems, our stakeholders will always be happy with us and will continue to give us autonomy.

And a mission, which is a more grounded version of it

And a strategy to get there

If nothing else it felt cathartic to write this down and I've encouraged the team to contribute to the document.

I sometimes feel my role, if anything is to keep pushing the team in the direction this describes so that we do become that team that I hope we will be.

A talk from Makers

A few of us went to a Leading a Diverse Team workshop at Makers. It was interesting and one talk resonated with me a lot. It discussed how often as a leader we project our own ideas as to how to accomplish a goal based on our own experiences. This is fine and well intentioned but it's from a position of bias and you may be unintentionally shutting out different ideas.

A better, more empowering way of trying to achieve what I'm trying to achieve is setting a vision but then encouraging the individuals in my team to think about the unique ways they can contribute toward that vision that I may not be thinking of.

My way of achieving goals is one means to that end but it doesn't have to be the only one; and there's probably better ones that my team can think of based on their own background, skills and experience. It's my job to encourage people and build a great environment so they can explore their own ideas.

Lessons learned, things to improve

Introvert Chris

I am one of those introvert-ish people who can seem relatively outgoing most of the time but I definitely suffer from running out of social energy quite quickly and just wanting to get a break from people (no offence, team).

This role definitely has taken its toll on introvert Chris at times and I need to find ways of managing that better but I dont have many good ideas yet. I think perhaps now my team is settled more I shall try and delegate a few more meetings to people as it will save me some social energy and is an opportunity for others to contribute in those areas.

You cant just mob

I hear a lot of great things about mobbing and I am totally on-board but for whatever reason when we tried it did not go well. I suspect it was a function of the team being very unfamiliar with each other and the nature of the work (it was very new-project, infrastructure work).

Still, like leadership it's probably something you have to study and not just an innate skill. I hope to read more about this and try it again next year.

General time management

I'm not happy with the amount of time I've got to pair with everyone. I'd say I do it quite often but not enough. The times where I paired I've been able to give much more useful feedback in our one-to-ones.

When the role was first offered to me it was proposed I would manage 3 people. That quickly turned to 5 and at the start of 2020 7. To serve all these people well I am definitely going to have to think carefully about what I am doing every day and try to find opportunities to delegate useful tasks that will help people grow and free my time up at the same time.

Study more

The few books I got through gave me some excellent ideas and set me up well. I want to continue reading this subject to get better. I'm currently reading An Elegant Puzzle which is very interesting but seems maybe better suited to a head of engineering role rather than the one I'm in right now.

The next books will be:

Final reflections

I'm glad I didn't try and "wing-it" with management. I'm still learning though and there's lots of room for improvement but I think the upfront study I did helped grease the wheels for my team and get it off to a good start.

During hiring I was very upfront about what my expectations and aspirations for the team were which resulted in a group of people joining who seem to be bought into the idea and are contributing toward it.

I'm really pleased and proud of how things are going. I shouldn't take for granted that we managed to turn a group of strangers with various backgrounds and experiences into a great team. The culture is fun, open, curious and we take pride in our work; which is honestly exactly what I wanted.

I feel everyone has become better engineers since joining and I am confident we'll do great next year so long as we keep pushing ourselves to get better and better. (that felt like a bit of a lame manager-esque rallying call, sorry)

I think the most gratifying moment for me was a small one. A few weeks after the team formed I went on holiday. When I came back one of my team mates told me they had changed the process. I replied:


It's the team's process, not mine. I want them to be comfortable making decisions about how we work and voicing strong opinions about the way we do things, and this demonstrated we are heading in the right direction.

Gamifying Continuous Integration

28 November 2019

If you read the internet, you'll soon realise that a large number of software developers don't understand what CI is and why it's important.

It's important to state that continuous integration is not a server.

Like the word DevOps, people seem to think these important principals of software engineering are about tools and products. Perhaps misinformed managers think if they buy the right magic box they can finally deliver their projects on time.

Continuous integration is continuous integration

Read the words.

It's about making sure that when you are working on code is the most up to date version of the code as a team.

In an ideal world if you could somehow all work on same computer at the same time comfortably, that would be pure CI.

If you've ever used VS-code's Live Share plugin, that's as pure a CI experience you can get in a remote environment. If you've not used it, it allows you to connect to a colleague's VS code and edit the code together as if you're working on the same computer. The changes you make are reflected (or integrated) to everyone else in the session - the feedback is immediate.

A much simpler experience of CI is mobbing. Everyone is working from the same version of the code together.

How do you know if you're not practicing CI well?

One obvious sign is developers wasting lots of time resolving large merge conflicts. Merge conflicts are a direct result of you working on a version of the code that isn't up to date. Your team are not integrating their changes continuously and therefore as they make changes the risk of making invalid changes increases.

The time wasted on merge conflicts has compounding effects as it increases the delays of integrating your own changes to the system.

One might argue you can resolve this by structuring work differently to avoid conflicts, even going as far as to re-architect your system to avoid merge conflicts. An often touted reason to go for microservices is it allows teams to work independently.

Reader, I have worked on a team with 20 odd developers, shipping frequently on a monolith and very rarely did we have merge conflicts. We also didn't do pull requests, we committed to master.

If you don't practice CI you are not working with your team as well as you could

Changes to the system are invisibly stored on your colleague's computers where they are of no use to you.

You could be imagining some great abstraction given the code in front of you but unfortunately the code in front of you is not the source of truth because unknown to you another developer merges a gigantic change after spending a week on a feature.

People become reluctant to refactor parts of the code because someone is working on a branch that is vaguely near the code you want to change so you wait a few days and then forget about it.

How do you CI well?

The simplest way is for everyone to commit to master, frequently. It really is that obvious!

To be good at continuous integration, you should continuously integrate your changes to master. That way everyone will be working with the same version of code for the most part.

It's important that you respect your colleagues and run your tests before pushing. If the build is broken the team should stop committing unless it's to directly fix the problem. If people keep committing whilst the build is broken it will become very difficult to diagnose what the problem is and the new commits may compound the issue.

The process, in full

This practice is simple to follow, doesn't require elaborate review systems, branch strategies etc, and forces good habits.

It wont entirely stop merge conflicts occurring, but they should be very infrequent and because you're doing small changes they're typically trivial to resolve.

But what about code review?

The industry seems to have conflated reviewing code with a very specific, relatively new process of looking at code when a pull request is submitted; usually too late once all the code is written.

Did you know that you can talk about code, at any time during the day?

Did you also know that the correct abstractions and patterns may not be apparent when the code is "done" and you'd be better off encouraging an environment where people are free to refactor code when they want to, rather than having to go through a laborious process every time they want to change the code. I've worked on and observed projects that practice code review very strictly and yet the code is still not great.

Relying on a process of checking code before it is merged is not going to result in a healthy codebase alone.

With this way of working I strongly encourage pair programming because people rightly assert that as a lone developer it is very easy to do something wrong if you don't gather feedback. Pair programming facilitates a constant feedback loop on what you are writing.

What if someone commits something wrong/broken?

First of all, no process in the world can prevent this. Stuff does go wrong, and you would be better asking yourself:

How can we detect and recover from problems easier?

Secondly, this approach does require a healthy and collaborative team that talk to each other regularly about what they are working on. They should be talking to each other when they start a bit of work about what they are going to do, how they will release it safely, what kind of tests, etc. Couple that with working on small things iteratively the risk of pushing something catastrophic are very low.

If someone does push some code that maybe works (so the tests pass, monitoring is all good, etc) but is actually "bad". Well so what? We can refactor it if we don't like it.

What if I, a tech lead want to check every change before merging

I don't want to work with gatekeepers.

I want to work on a team that trusts one-another.

Perfect is the enemy of good.

So is a system of pull requests bad?

Not at all, they're perfect for open source projects where you want to welcome contributions from other people but dont have implicit trust. In that case you will want to review changes that go into your precious project.

For a team where you trust the developers all it adds is overhead.


We should be removing the barriers to changing software, not adding walls and walls of bureaucracy.

In this kind of environment people fix code when they see it needs fixing.

This way of working tightens feedback loops and increases actual meaningful agility.

CI is not just about the code

Gaming it

I feel very strongly about working this way over a pull request approach when you are working on a team you trust.

Most of my team until recently were very unfamiliar with this way of working so I made a silly dashboard on one of the TVs which showed who committed to master most over a given week. It penalises you points if you push a change which breaks the build.

ci-league dashboard

After just a few weeks this slight nudging has improved the team's approach to CI, we've had significantly less merge conflicts, people are refactoring more often and the number of failed builds has also dropped.

The code for it is on github

And if you have docker, you can run it with

$ docker run -p 8000:8000 quii/ci-league

If you want it to look at a private repo you'll need to supply a github personal access token as an environment variable

$ docker run -p 8000:8000 -e GITHUB_TOKEN=supersecret quii/ci-league

It doesn't do any fancy auto-refreshing but most browsers have extensions to auto refresh a tab, we set it to update every 10 minutes here.

Wrapping up

As usual in software, we seem to suffer as an industry of remembering the why of all of these fancy terms.

If you appreciate the why of CI you may not fall in to the trap of blinding applying best practices that work in a different context to the one you are working in. As I said pull-requests in an open source project make total sense and work great. In a different context it adds overhead.

You should instead focus on what your environment your team is working in, the constraints you have and use principles like CI to guide what process best fits.