Abstractions are scaffolding

All software is an abstraction. It’s human-like language with a logical structure to abstract over ill defined business processes, and gates and transistors, and assembly language, and often 7 network layers, and memory management and databases and a myriad of other things that abstractions paper over to help you deliver business value.

Abstractions are the scaffolding you need to get your project running, but they’re another dependency you need to own. You need to understanding what’s under the abstraction. Or you start thinking network traffic is free. The network is not your friend, it’s slow and unreliable.

Abstractions provide some structure to make what they support easier, but they in turn rely on structures underneath. If you’re going to own an abstraction like any other dependency, you need to understand the structure it’s built on and what it’s designed to support. I understand what ORMs do because I’ve written some of that code in a less performant, less reliable way, before I realised someone had done it a lot better. Indeed, that was the realisation that drove me to alt.Net and NHibernate, but it meant that I understood there was SQL underneath, and the SELECT N+1 problem was a mismatch in the queries that could be resolved, and not just an unexplainable performance hit caused by a network spike.

Abstractions make more sense if you understand what they’re abstracting over. They’re not there for you to forget about what’s underneath, just to save you having to write that code for every class in every project you work on, and to benefit from a wider pool of developers working on battle-tested code. If you don’t know TCP from HTTP, don’t write web applications. If you don’t understand databases or SQL, don’t use an ORM.

This is from the person that *invented* Hibernate#LearnSQL pic.twitter.com/GRlDgBPotw

— Connor McDonald 🍸☕️ (@connor_mc_d) October 1, 2016

All abstractions are imperfect. Learn what’s under the cracks.

The manager and maker schedule

All technical leads should write code. If you’re not writing code, you’re a manager. And that’s fine. But stop pretending you’re technical. Many Technical Leads or other senior technical staff have a preferred time split between the admin and technical parts of their job, but I don’t always see that in practice.

Some technical leads double down on the technical part and ignore the leadership part. Those are the people who need mentored. It’s the hardest shift when becoming the leader, to accept that your most valuable time is no longer the conversation you have with the compiler, it’s the conversations you have with and on behalf of your team.

You need the time to have those conversations, to keep the team delivering, and delivering the right thing. But you also need up to date technical knowledge to give you the right context for those conversations.

Managing time can be one of the trickiest skills for a new technical lead to learn. The process I use is simple, but it requires discipline.

If you want a split of 60% coding to 40% admin, then schedule it in advance. Pick 2 admin days and 3 development days. Or if you’re most creative in the mornings, schedule 3 hours at the end of each day. Into the admin days put your 1-2-1 meetings and other line management, and your cross-functional meetings, and the team planning and retrospective meetings. Lay out time for emails and backlog pruning and catching up on your reading list. And then block the remainder off for development, deferring to your task board for detail. And make those events as public as you can so your team and others know when they can schedule your time.

Maybe those times are dictated by others and you end up with regular meetings scheduled in your Zone time.If you can’t move it, work the schedule around it. Turn those into your admin days. The most important thing is to define a split, and stick to it.

Sense and Respond by Jeff Gothelf and Josh Seiden

Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously by Jeff Gothelf

My rating: 5 of 5 stars

Having read Lean UX, I was expecting a good book on how organisations could deliver projects. This book is about much more than that. The authors are coming from a point of frustration where agile delivery and Lean UX projects have failed to reach their potential because the organisations surrounding them were not supportive, so this book is about how to reshape an entire organisation to meet the challenged of the modern world, with lots of positive and negative examples, which is refreshing to see in this type of book. If you’ve ever had a strategy meeting, or ever found your project success limited by your organisation, go read this book.

Easily the best book about dysfunctional organisations and organisational change I’ve read since Peopleware.

View all my reviews

Buy on Amazon UK :

Demotivated by refactoring

Technical debt causes drag. It slows down new features and lengthens the half life of a project (Erik Bernhardsson talks about projects with a code half-life measured in years, but Sandi Metz talks about projects with a half life of 6 weeks on her Chainline mailing list – go sign up now). We all know the benefit of doing it and development teams fight to get time to do it.

But it’s not the most exciting work. Dealing with debt can easily demotivate a team fired up by new challenges and new features, even when they see the benefit. Yak shaving doesn’t get innovators out of bed.

Sometimes the motivation comes from seeing the next step, 2 days refactoring so that this new feature can be delivered faster. Sometimes it’s a negative motivation, fix this and you’ll never have to worry about it again.

But for teams driven by delivering business value, taking time away from that to naval gaze at the code stacks up the guilt, and can tire the team out faster than a crunch, because there’s no adrenaline to go around. That’s because often the goal of refactoring isn’t enabling functionality, it’s unlocking efficiency, and that’s a less tangible goal. Why go through the pain when other tasks show more short term benefit for less work?

For one, the team has to be motivated by medium and long term goals rather than just short term. Not just what can be done this sprint, but what code do we want to work with next year? For another, refactoring in general should be small enough that the next business value task is on the horizon, and directly linked to the success of the current task. Or maybe there’s a personal reward. The team appreciates the work and so is happy to cover your support shift. They all agree that you get off pager duty for the length of the task plus a week.

When yak shaving is a drag, how do you keep motivated?