My job advert for 2023

I'm looking for a new software developer/engineering manager role, and this post will summarise me for potential employees.

This blog is a fair reflection on my general attitudes towards software development, what's important to me, what I feel works, and what doesn't!

My hope is someone will read this and think.

Chris's experience, values, and work methods align with what we need, and we should chat with him.

If I look like a good fit, contact me and dig into other posts here to see more of what makes me tick. If you wish to prepare for our interview, I already have my questions written down for you.

The headlines

  • Happy to be either an engineering manager or a developer within a team.
  • I'm happiest and probably most effective when I am coaching and pairing with engineers & teams.
  • Around 17 years of professional software-engineering experience
  • My most recent experience is with Go, but I have shipped numerous production systems in Type/JavaScript, Kotlin, and Scala.
  • I've worked on various systems during my career, from client-side heavy, niche data exploration tools and backend APIs to websites serving hundreds of requests per second across the globe.
  • I am the author of the popular resource Learn Go with Tests.

Stuff I like

  • Trunk-based development
  • TDD
  • Continuous delivery (10 deploys per day, DORA metrics, that kind of vibe)
  • Autonomy with responsibility. You build it; you run it.
  • Kanban (not scrum)
  • Iterative, lean development practices
  • XP
  • Stream-aligned teams (think Conway's Law and topics discussed in Team Topologies)
  • Learning, coaching and mentoring. A curious and learning-focused engineering culture is very important to me. Every place I work I try to encourage and facilitate book clubs, katas, lightning talks, etc.

My answers to the usual questions

What are you most proud of professionally?

  • Writing Learn Go with Tests and seeing what a positive impact it's had on many engineers.
  • My conference and meetup talks (Gophercon UK, London Gophers) and being invited to Go Time a few times
  • Participating in several junior engineers' journeys, helping and guiding them to well-deserved promotions and pay raises. The thing I am probably most proud of is hiring a group from Makers Academy, a coding boot-camp, and fostering a fun, curious and effective engineering team.
  • Helping teams become more effective in their development and release practices, making work more straightforward, less stressful and more effective. We're a good fit if you have heard of DORA metrics.

What are you looking for?

  • I am happiest when I am in a team that is constantly growing. I love coaching, guiding, and learning from people smarter than me. I want an environment where engineers are humble and curious about software engineering. My dream role is to be a coach.
  • Go, ideally, but I also like Kotlin and JavaScript (mostly). I enjoy programming, and if you're happy to accept additional ramp-up time for me to learn something new, I'm more than excited to do that. Any Rust roles?
  • A team of diverse backgrounds. I've been lucky to work in teams over the past five years with people from various backgrounds, making me a better engineer and person.
  • I love seeing metrics fly up that represent actual people using the software. Feeling a connection between the work to tangible outcomes is fantastic.

Can you complete these data structures and algorithms / cracking the coding interview / leetcode exercises?

I'd rather not. I last thought about bubble sort et al. around 2002.

I've designed a number of interview processes, securing some excellent colleagues. They've always involved a small but practical homework that has helped us understand the quality of the code they write in a team setting (think testing, coupling/cohesion, separation of concerns, etc.), rather than whether they can invert a binary tree or not.

Look at my GitHub if you need clarification on whether I can write code, or look at Learn Go with Tests as I clearly explain my thought process.

Values and principles

Quality and delivery speed are correlated, not traded-off

Dave Farley's book Modern Software Engineering encompasses my views of what practical engineering looks like. If you've read that book and it resonates, I'd love to work with you. One topic he covers is that teams often take shortcuts and technical debt to go faster, but when we bring evidence to the picture, we find it's a false economy.

The State of DevOps reports debunk the idea we trade speed and quality off; they are correlated.

If we're honest, we all know this to be true. How many times have you opened a garbage codebase and wasted days or weeks trying to make a minor change?

The way to go fast is to write high-quality, small increments, get feedback, change direction, and repeat. See also: How to go fast.

Empowered teams

I'm not too fond of the idea of story robots. Programmers on an assembly line picking up tickets from JIRA, mindlessly doing them and throwing them into "done". Never questioning the work and never working with real users.

I have no interest in leads, seniors or BAs sitting in ivory towers writing tickets and throwing them over the wall to some poor, demotivated programmers who are judged by how many tickets they complete or how many PRs they approve per week.

I want my teams to be given a real user problem and for them to work together to figure out how to solve it. They should focus on actual business outcomes, not "velocity".

Velocity is an abstract concept; if a team has a "good" velocity, it doesn't mean they're solving real problems. High velocity is only useful if you're going in the right direction.

Work-life balance

I feel very blessed to have a profession that I enjoy, but that doesn't mean I will sacrifice my personal life for it.

The need for long hours and heroism often ruin work-life balance. Heroism is a symptom and a bandaid for organisations that fail to manage work correctly, execute poorly on a technical level and not having the courage to say "no".

(Another good sign of compatibility is if you know what I mean by "That looks like a Brent", referencing The Phoenix Project)

Occasional acts of heroism are sometimes necessary, I'm never jobsworth about my role and only work strict hours, and it can feel good to save the day; but it should be the exception, not the norm.

When I run teams, I optimise the way we work so that we try and do things properly and not be woken up at 3 am, and if work is taking longer than people hoped, we deal with it, find ways to improve, cut scope, etc., but not demand engineers work late nights which for the most part, tends to make things worse.

If your job description includes phrases like a fast-paced environment or working well under pressure, that gives me some red flags.

Honesty, with respect and empathy

Honesty is extremely important, and when I build teams, I do my best to try and build a safe environment for people to express their views so we can grow.

"Constructive" feedback is an act of kindness if it is done kindly. Honesty does not have to come at the expense of respect and empathy.

Learning culture

I love learning and improving my craft. By our industry's standards, I am very experienced, but I am still excited to challenge myself to improve and learn new things.

So many organisations bemoan the output of their engineering teams but are unwilling to do anything concrete to increase capacity beyond cracking whips. I want to work in organisations that invest in their teams to help them improve; things like 10% time are good examples of this.

It also should be happening on a day-to-day basis. Pair programming, mobbing, retrospectives, etc., are all important tools to help teams and people improve. A safe environment where people can be fearless to try things without fear of reprisal if something goes wrong is key to growth and innovation.

This also relates to my first point: quality and speed are correlated, not traded off. The better we get at writing software, the more we understand the domain, the higher the quality of the systems we build and, therefore, the more value we can deliver. If this doesn't align with you, it will be difficult.

Other practicalities

Remote?

Even though I am an introvert pretending to be an extrovert, I like going to the office and seeing people face to face. That said, depending on where in London your office is, it might take a long time. Either way, it is very expensive (I live just outside London), so I prefer to go 1-2 times per week maximum. I can make occasional exceptions; for instance, if you're doing a week-long project inception, that's fine.

I am open to being 100% remote, but so far, my one experience (during Covid) could have been more enjoyable. I feel I suffered from "Zoom fatigue". Maybe our environment did remote work wrong, though, and I appreciate lots of people swear by it.

I also am okay with travelling abroad from time to time.

When?

I prefer to start around March, but have some flexibility.

Salary?

Nice try. You tell me.

PS, everyone has a "competitive salary".