When I attended WordCamp London 2017, I was struck by a talk by Adrian Roselli, Selfish Accessibility which revolved around a rather simple philosophy: whether due to aging or some mishap, one day you’ll face problems that accessibility solves, and you’ll either regret that your younger self didn’t implement it, or you’ll thank yourself for thinking ahead.

This philosophy resonated with me, and I’ve been reflecting on it ever since, applying it to development and project management: I called it Technical Selfishness, and I always joke that it’s the way to work half as much, get paid twice as much, and produce four times more. Unfortunately, it doesn’t work that way: I don’t know any company that doubles your salary for producing four times as much.

At first, I saw many parallels between what Roselli discussed in his talk and best practices in development, and I thought that Technical Selfishness was about making maintenance and scalability easier through best practices.

As I write this, seven years have passed since then, and I’m now clear that it’s not about that.

If Selfish Accessibility is about making it easier for you to interact with interfaces, and best practices in development are about making it easier to maintain and scale code, then Technical Selfishness is about making the work itself easier for you, and therefore, it’s less about focusing on the immediate benefits of your work and more about the long-term benefits.

Applied to development, it’s less about implementing best practices and simplifying code (for example) and more about simplifying the development process itself: using component libraries (or creating them if necessary) instead of just developing an interface, creating code generators instead of implementing it over and over again.

Oh! I know, I know. Not all code can be generated. Don’t do it. But for the code that can be, don’t implement it yourself… let a machine do it!

Be selfish and understand that your time is valuable, and that value is only perceived to the extent that it is added to the work you produce.

In other words, if you automate processes, decisions, implementations, etc., that can be automated, you free up time to focus on more valuable tasks.

I know you’re thinking this makes sense and is obvious, but… do you do it? Or is it done in your company?

How many excuses come to mind when you read this? Because, don’t kid yourself, that’s what they are.

By the way, making your work easier doesn’t mean you have to do it for your company (or any company).

Be selfish and make your work and processes easier.

Will it benefit your company? Of course.

Will it benefit you? Much more.

Your processes go with you, so the time you spend improving, optimizing, and above all, automating them is yours… forever, at every company you go to.

Technical Selfishness is for you if…

1. Your time is the most important thing

Since we can’t produce it, freeing up time is one of the most important activities we can engage in. Its importance grows as our salary is more closely tied to our results.

But even if our salary is tied to our time (X money for Y hours per week), freeing up time has benefits, as we’ll see in the next point.

2. You’ve had work peaks that either delay deadlines or result in overtime

The more manual development you have to tackle, the more sensitive you are to work peaks, and if you need to deliver by certain deadlines, you start to discard everything that isn’t “essential.”

Obviously, if you can negotiate to extend deadlines as much as necessary, you won’t have this problem. I’ve never experienced deadlines being extended that much (even though my direct superiors have sweated blood to achieve it), but there’s always a first time.

3. You’ve “forgotten” to do things.

In general, when urgency comes through the door, best practices fly out the window. You don’t do as many tests, you don’t document as thoroughly, and you forget some things.

In my environment, even without such urgency, more than one of us (myself included) has forgotten to move a task to a different column in Jira. And while it’s true that “I’m not paid” to move tasks between columns, doing so facilitates the visibility of work from “above,” and it doesn’t look good if you don’t have tasks in progress or if they’ve been there for too long.

Applied Technical Selfishness

In the end, Technical Selfishness is based on:

1. defining all the processes that you repeat more than once

Starting with those you repeat the most, like creating branches in a repository, documenting a feature, or implementing a minimal set of tests…

2. grouping similar tasks,

Grouping similar tasks allows you, among other things, to make use of a mental state and focus. But it also allows you to detect recurring patterns and refine the processes you’re defining.

3. eliminating tasks that are duplicated or redundant,

Often, different processes involve similar steps that, once grouped, you can address in one go.

A very simple example is notifying testers when a new version of an application has been deployed. Generally, the application will have a backend and a frontend, but you’ll only notify once all parts have been deployed, rather than notifying for each part.

4. automating all the tasks in those processes that lend themselves to it,

Automation not only saves time. It also helps enforce standards.

If we take the case of creating a new branch in a repo, it’s as simple as using git checkout -b branch-name. Although branch-name can be anything, and that might not be the best idea. On the other hand, if we automate the creation of a new branch that asks for the necessary data, the name can be generated according to a pre-agreed standard.

Of course, we can also group other related tasks of the same process that require the same data… but that’s for another article.