Nobody wants my Code

Over the past few months I’ve come to a slightly disturbing realisation – that nobody else wants my code.

My Manager doesn’t want my Code

My manager isn’t up to date on the technologies I use every day – and more to the point, it’s not his job to know. His job is to manage the team – coordinating resources, setting priorities, managing budgets and so on, taking care of the minutia so that his team can do their jobs.

My Manager doesn’t want my code.

My manager wants to know that I’m doing my job well, that my customers (clients/users/colleagues) are happy with my work. He wants to know what I’m working on, and needs to know if I’m running behind or becoming overloaded.

My manager doesn’t want my code because it doesn’t tell him anything he needs to know.

My Teammates don’t want my code

By contrast, my teammates are as technically competent as I – they know many of the same technologies just as well, and just as I know some areas better, they know other areas better than I. But, even if we are working on the same project – and even if their code is critically dependent on mine, they don’t want my code.

Instead, my teammates need to know that my code will behave itself – that it will do what it is supposed to do with a minimum of untoward side effects, that it is well written, well tested and well maintained. They need to know that they can rely on my code, so they can get their own work done.

My teammates don’t want my code – they don’t have the time, or the interest, as they have their own tasks to complete.

My Architect doesn’t want my Code

The way that my code integrates into the overall system is defined by the architecture – so the architect has spent a lot of time detailing for me where my code fits. But, he’s not interested in the code itself. Architects are concerned with larger issues, such systems design, how different systems communicate and interact, and where each system fits into business goals.

My Architect doesn’t want my code, he just wants to know that my software will integrate into the grand design properly, that the servers won’t get hammered and that I’ve properly attended to all the necessary little details, like authentication, authorization, auditing, logging, performance, reliability and scalability.

My Testers don’t want my Code

The testers are interested in testing the entire system or large pieces of it, at the very least. They’re interested in the services my code provides, the functionality that is the reason for writing the system. They want to know that my code provides those services correctly, but they don’t care how it’s written – or even in what language - just how it behaves.

My testers don’t want my code because they’re not interested in how it works, but instead in whether it works, and whether the answers it produces are correct.

Other Developers don’t want my Code

After the project is complete and the system has gone live, there will be modifications. Defects will be identified, perhaps changes will be necessary, whatever the reason, there will be modifications.

The developer working on the issue isn’t interested in my code – she wants to find out how to make the necessary change (without breaking anything else) as fast as possible, and then get on with another task. More code is not better code – it’s just more code that needs to be read and understood.

Other developers don’t want my code, they want to complete their assigned change as quickly as possible and get on with other work.

My Users don’t want my Code

The people who use my software every day don’t want my code. If they could find a simpler, faster, way to get their jobs done, a way that didn’t use my software at all, they would quickly switch.

If there was a way for my users to do their entire job by pressing a large green button, once, at the start of each day, they’d hire a monkey to press the button and spend their days elsewhere – perhaps at home in the garden, or maybe overseas in some exotic locale.

Failing the creation of that large green button, the best my code can do is to help them do their job quickly and efficiently.

Users don’t want to use a computer; they want to get their jobs done quickly and effectively.

Senior Management doesn’t want my code

My CIO doesn’t want my code. She’s rightly more interested big picture issues – the details of my day to day coding don’t matter except as they contribute to her long term strategies.

In fact, as long as my Manager is happy, chances are she’ll be happy too.

As for the rest of Senior Management, well, they are even less interested in my code than my CIO.

Nobody wants my Code

All of which brings me back to my original point – that nobody wants my code.

But that doesn’t matter.

My code is important to me – and if I take the time and make the effort to write, test and document my code to a high standard, everyone else will be happy too.

Why?

Because what everybody is interested in is the business value that my code helps to provide.

And that, I guess, is the point.