Nobody ever paid me for code

Because mauve databases have the most RAM

Summary

At the beginning of a dev career, you focus on improving your technical skills, which is perfectly natural. But people don't pay for code, they pay for solutions to problems.

Once you understand this, you will adapt the way you communicate with your clients or bosses, because they don't care about the implementation, and you can focus on what matters to them.

This will, eventually, shape your professional identity in the eyes for those who pay you.

You don't pay for a car

There is something good advertisers have understood for a long time: they should not promote the object they want to sell you.

Instead, they will sell you a solution, a concept, a lifestyle...

In 2001, when Apple released the iPod, it was seldom the only mp3 player on the market. Yet, it didn't hilight the specs like the competition did. Only a niche cared about the Giga Bytes and the Mega Hertz. They told their customers: "1000 Songs in Your Pocket".

There are several reasons for this, but one of them is that you don't really pay for the product you buy, you pay for the problem it solves, or the needs/wants it fulfills. Sometimes it’s an indirect need or want, like improving your self-image or your social status, which has nothing to do with the original object function.

For example, people don't pay for a car. They actually pay for things like:

• Being able to go to holidays with the whole family.

• Shorten their commute time.

• Enjoying the pleasure to go fast on the road.

• Showing off.

• Etc.

But the car is just mean for that. If there are other ways to satisfy the same conditions more efficiently, they may choose that instead.

E.G.: Instead of paying for a car, you may take a pay cut in exchange for a fully remote position that completely remove the commute time. Instead of the pleasure of driving a car, you may choose a bike. To show off, you may get a boat and keep your old car instead.

You don't pay a plumber to change a gasket

This is true for services as well.

If your sink is leaking, you might call a plumber to fix it.

But you don't really pay the plumber for putting a new gasket in.

In fact, you don't care about the gasket, you care about not having your sink leaking.

If there were no leak, you wouldn't pay anybody for the pleasure of seeing this person changing the gasket. It is done with a purpose: solving your problem of a leaking sink.

And in the same way, if there is another manner to solve the leak, you may choose to do so. You may tighten the faucet screw very strongly with adjustable pliers and delay the inevitable a little more. Or put a bucket under the leak and decide it's enough and you don't have time for this crap.

Well, believe it or not, this whole analogy is exactly how companies behave with problems. They may call somebody to solve it. Do it themselves. Or put a bucket under the leak forever.

But the point is: they don't pay you for changing the gasket, they pay you to fix the problem.

And by gasket, I mean producing code, in case I wasn't being obvious enough.

If the clients (or the bosses, but I'll user "clients" as a generic catch-all for anybody that brings money your way) want you to build a new feature, they don't care about the code. They care about the new feature.

If they want you to fix a bug, they really don't care how you do it, they want the issue to disappear.

They pay you for the results and their context. They pay you for relieving their pain, and solving their problem.

Now, of course, this is a tad more subtle.

Different types of problems have different types of costs, consequences, and constraints. And solutions to those problems as well also have them.

When code is the solution, it has a cost, at the very minimum in time and man-hours. And constraints, such as licenses, NDA, platforms, versions, formats, resource limits... And of course, consequences, such as technical debt, electricity consumption, user experience and hiring difficulties.

While the clients don't care about the code, they care very much about those.

And so, as IT professionals, we must communicate talking about that. Not about the code.

Communicating with the clients

Too many times, I see my colleagues focused on the technical. This is completely backward. We exist to isolate the other teams from the technicalities.

We need to talk to the other side using their language, and about things that matter to them.

Why should they not adapt to you?

Well, if they are worth their salt, they already do it, in fact.

You usually don't hear the clients talking about how they negotiated their budget to get you paid. They get you paid.

They may talk about constraints, like payment delays or amount limits. Because you care very much about that.

But you don't care about the fact they spent 3 hours in a meeting with accounting and HR to categorize each cash flow so that's they get an allocated margin taking in consideration the average stats on pregnancy, sick leaves and training.

You just want to know when, and how much.

They are the same.

Plus, it has many advantages for you to do so:

• Your communication will improve tremendously, and you will get much more qualitative information about your tasks, your objectives and what you can do, or not.

• Productivity and trust will increase tenfold.

• When something will go wrong, and it will, as it always does, you will less likely be blamed. Focusing on problems has the magic property of getting people involved on problem solving. Seems obvious, in retrospect.

• Your perceived value will rise, and so the number of opportunities and money you can expect in the future.

So keep the technical talk to your peers, unless the client explicitly asks for it. And even then, increase slowly the geekiness to see where you can get to. Some clients are very technical, but it's rare, the majority are not, some think they are, but they really are not.

Examples of what not so say and what to say instead.

Don't:

We should migrate from SQLite to Postgress. We are getting concurrency errors because too many processes are trying to write orders at the same time and it's not something we can queue because it needs real-time feedback.

Do:

Some users are getting errors when too many of them order at the same time. We tried workarounds but they make for a bad shopping experience. This is not a trivial change to do. We are currently working on X, but I think this is more urgent. I advise we suspend work on X so that I can evaluate how much we need to do, and then plan for this change.

Don't:

We have an XSS vulnerability and someone could inject JS code into our product page comments. We need to fix this ASAP.

Do:

We noticed a bad actor could use product page comments to pirate our users because they are not protected well enough. This could affect our customers’ safety and our reputation. To our knowledge, this has not happened yet, but fixing it should be added to our lists of things to do. We have already tools to do this, so we could do a first try in half a day and see if that works.

Who are you, really?

At the beginning of a career, you focus on improving your technical skills, which is perfectly natural. This means it can require a conscious effort on your part to start seeing the other side of the coin.

Because this whole thing is really about your identity to your clients.

How they see you is how much they value you, and how much, ultimately, they pay you.

When I was younger, the problems I was solving were mostly seen as technical problems. My identity was "the guy I pay to build a new feature or fix a bug"

But the more I got experience and reputation, the more it shifted higher into whatever the professional equivalent of the Maslow pyramid is.

When I demonstrated I could deal with complex assignments from A to Z, my identity became "the guy I pay when I want to get things done". One client once said to his colleague "just send him, he is a black box, he'll deal with it."

After years of working with clients on complicated problems, dealing with crisis, leading teams through fire, and communicating transparently every step of the way, my new identity became: "the guy I pay to lower my stress."

This is my current status, the big bosses of my client don't pay me to code, build features, manage projects. Others do that as well. They pay me, quite a lot, because they know for this price they will sleep well. Life will bring storms, but they don't have to worry about it, because they trust I will make good default choices, and if, and only if, ther input is needed, I will come back to them.

At this stage, it's not a matter if I'm going to code the feature or fix the bug. This is a given. It's obvious. It's not worth mentioning. It's like saying bakers will provide cake. Of course they will will.

It's not even about good work. This is also a given. That's the default expectation, it's part of the package. The cake will be good.

No.

At this stage, they pay me because they have thousands of stuff to do, hard stuff. It's exhausting, it's stressful. And it's important. One of this stuff, they know they can just leave it to me and I will ask the right questions, but not more, fight the right battles, but not more, push back the wrong decisions, but not more, and deal with the humans so the problem is solved, if solveable. Then make sure they know what they need to know, but not more.

If you provide a service, ultimately, you want people to pay you so they can stop worrying.

Because that's worth a lot.