Nobody ever paid me for code

Overall I like posts like these, as they are a reminder that you're not really paid for agonizing over eloquent or great code, but just code that "gets the job done". But then if you over-index on this viewpoint, you'll end up needing posts which remind you that this is a craft and that code needs some agonizing over.

What I've been pondering lately is another way to sum this up that is more future focused: Let's say a genie walks into your project and says that you can have 1.5 times the features you have right now, for 3x the code. The genie promises that the code will be "alright, maybe just kind of a bit bad". I think around 2/3 of developers would say no, but I suspect 2/3 of people in product management, sales, marketing, etc would say yes. Everyone would be sympathetic to the problems this would create, but the allure of getting 1.5X ahead on your roadmap is probably too hard to ignore for those other disciplines. It's basically accelerating all your other work streams by 1.5, at the expense of potentially bogging down dev. Obviously, countless caveats exist, but it does in general feel right, and feels like it hints at the fundamental causes of tension between business and development.

The more important and general wisdom: know your audience. You will sometimes have clients with deep technical backgrounds that expect a sufficient level of detail to have any faith or trust in your solutions. You need to be able to tailor your communication based on the situation and the expectations of the audience in question. This is never binary and can be especially challenging when you need to communicate to multiple people at the same time that each require different levels of detail.

I disagree with some of the things the article describes. Not that they aren't real or that the world works differently, but with those things themselves. For example:

(1) It should always be ones goal to improve ones technical skills, not only in the beginning of ones career. Too often have I seen bad code or lack of knowledge about computer programming concepts, that people ought to know, considering the time they spent in their career. Those things will result in "solutions" but those solutions might not be the most maintainable and understandable. Fine if you switch jobs every 2 years and never have to deal with the aftermath, but not fine for people, who value quality. All your communication skills won't make up for a brittle base due to insufficient technical skills.

(2) To let others dictate, how you develop professionally, being the ultimate yes-sayer. Improve the way you yourself value and see as important and stick to your guns. Not everyone needs to go along career paths that some company with mediocre management has laid out for them. Not everyone needs to become a talker.

(3) Perhaps the title is a bit too extreme. Code can be the solution. Good code even more so. Personally that's what I want to do. Write code to solve problems. Of course, only write it, when it is necessary. Who wants to write code only to have it be discarded, because it was not needed in the first place. (OK maybe sometimes one does, for the learning experience.)

> They told their customers: "1000 Songs in Your Pocket".

That is talking about specs, and it is exactly what the competition did too. Here in the unit "number of songs". Maybe most people at the time couldn't translate GBs into number of songs, but nowadays bandwidth or "surf" is talked about in terms of GBs because it has become familiar through experience.

The iPod had better specs and better design. The original Jobs presentation even puts up a table or 2x2 illustrating how the iPod specs would be superior.

Obviously, one adapts language to audience, but I've never seen a case where this is the real reason for success or failure.

I was around for the mp3 "revolution", so I'll add to the author's discussion point about the ipod.

The thousand-songs-in-your-pocket sales pitch was more than lifestyle/concept -- it was an actual feature. All of the other players at the time were big & bulky because the components they used for storage & battery required the corresponding form factor. The "pocket" part of the sales pitch was exactly that: the ipod physically fit in your pocket because the components were smaller and more integrated. In the stage demoes by Jobs, he shoves the ipod into his jeans.

To the author's point about "you pay for the problem it solves, or the needs/wants it fulfills", the implied need here was that you need this to be small and out-of-the-way -- not a miniature home-stereo attached to your belt.

And not to pick on the author, but I don't find the ipod reference very applicable to the case of communicating with your consulting clients. Sure, you have to speak to your audience -- but direct 1:1 contact with a handful of stakeholders is hella different from millions of consumers who never asked you for a specific set of features and a timeline.

This works the other way around.

You'll get a technical project manager, and they'll bring in a consultant to do some programming.

"All you guys need to do is write a little code to interface X with Y, it should only take you a couple days"

They don't think, "you'll need to get with this vendor, use this outdated software, follow these restrictions, make sure the UI matches up with the other program, interface with this authentication library..."

That's all part of "Add UPS shipping support to our CRM software"

Sometimes I know what I want, and if a salesman starts trying to sell me a 'concept' or a 'lifestyle' instead of a car, I'm walking away.

Using the analogy of a car, I’m not buying ANY car but a SPECIFIC car with features and quality that meet my requirements. My client is not getting ANY code, but featured and performant code. My client is fed up with basic code, they want “quality” and are paying appropriately for it. So yes, there are clients that pay for “quality” code because they do want more than just a solution.

I think this is wrong:

You are getting paid to code.

The person's problem is not code, but if code is the solution, that is what you are getting paid for.

The plumber is getting paid to change a gasket. If you look at the invoice, it won't say "water management" but it will include the gasket and labor.

Same for the car. If you look at the invoice, if won't say "personal transportation, instead you will see the car and the options that you paid for.

Same if you go to the doctor. It will list the various procedures and diagnosis and bill for those.

This conflates two issues: deciding the solution to your problem, and paying for the solution.

Marketing and sales is about convincing people that what you are selling is the solution to their problem. For example, car ads try to convince you that the specific car is the solution to going places in comfort with status. A beer ad tries to convince you that this particular beer is the solution for you having a great time with friends.

You actually then pay for the concrete car or beer, etc.

Yet every interview I have been to has had several coding tests, take homes and technical interviews. Your code is reviewed, and someone decides after 6 months if you are up to task. As an employee you can’t find an external solution and resell it with some smooth talking for double the price and go play golf. Rather you will be subjected to agile practices and if unlucky logging your hours against tickets. Most coders are actually paid to code. (trying to do non coding work beneficial to the business is actually a struggle unless it is in your assigned role!)

Lot of comments here are replying the nature of the solution matters.

E.G:

"Sure you are being paid for a solution. But you are also probably being paid for a quality solution"

or

"Code can be the solution. Good code even more so"

or

"when you pay to get your car fixed, there's an implicit expectation that it will be fixed well enough that it doesnt break the same way again"

But the article does address this:

> 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.

Of course the quality of the solution matters, but it any good thing has a price. Therefore you have to present it with the price, and then your opinion on the whether it's worth it.

Sure you are being paid for a solution. But you are also probably being paid for a quality solution.

I'm not sure you would want your house built by the contractor that took short cuts and did shoddy work. You might have roof over your head, but there will be more expensive problems later.

Good read, a lot that resonated with me. My comms (written and verbal) to stakeholders are something I'd rate as "OK". But, on occasion I still do catch myself out diving into tech talk at the wrong times.

I'd add that with a certain level of seniority, for those developers that enjoy working directly with clients and stakeholders, it's expected that you can translate in both directions.

That is: not just going from "tech to non-tech", but also shaping a "non-tech" requirement into an actual solution.

Clients will rarely ask for redundancy, persistence or ACID compliance. But they will say things like "I want some sort of completeness check, and I can't have the system drop any messages from the exchange."

I also became a guy who "solve problems" at a church that I volunteer as the media/AV/computer/tech guy. If the audio sounds weird in our live production or if the wedge speaker sounds too quiet or if the youtube stream looked too dark, I'm not going to say that we need to increase gain level on mic, change EQ to prevent feedback, change ISO setting on camera, etc. Instead, I'd tell them that I'd make some changes in the sound mixer and also adjust some settings in camera to fix those issues. I just tell them just enough for the audience/client/people to understand, without having to burden them with unnecessary detail.

In general I agree. But if this approach is applied for the same system many times in a row, it can cause technical debt.

> 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 you sink leaking.

I care about the gasket. If I want the sink to not leak then one way is to not use the tap/faucet. There are countless ways to fix the problem of your sink leaking, but only very few that you really want. Knowing your problem is important so that you don't waste time and money on charlatans. I care about the damned gasket.

I think the problem is developers might think on multiple levels of abstraction at once all the time. When they see something, do their thoughts about it's inner working automatically come to mind?

Code conissours don't quite get how nobody else cares, or even notices the code.

Look at Etcher. it's 80MB to do what DD does. I used to use it until the Pi imaging utility came along. And for non pi stuff I still use it. It loads almost instantly on a modern machine, and it's safer that DD where you might accidentally hit the wrong key and have nothing stopping you.

But a lot of developers would be bothered every time they use it by the fact it bundles electron. They have a sense of quality that goes beyond functionality, they want deep craftsmanship even if means more manual work, and the fact that complexity is not their problem doesn't matter, they don't like anything unnecessary anywhere.

So when they talk to others, they're talking about their interest, which is trying to get to the core essence of what defines a problem in an elegant way, while the user just wants it solved in a way that means they don't have to think about it anymore. For the coder, the thinking is the whole point!

Or at least for the typical fairly intelligent intellectual, idea driven personalities in the code world.

The clients pay me to create quality products or services.

The "quality" is key. I can stop the leak, but if I did it badly, the sink will start leaking again. And it will leak worse.

My (somewhat outdated) experience with consultancies was that they depended a lot on the customer believing they had some wizardry, and that involved selling a lot of industrial jargon that the manager had a passing familiarity with. Whether the consultancy could produce a working product was secondary to the proprietary and arcane technology (300 combined years of experience or whatever) that they could bring to the sales meeting. The manager could rest well knowing that they had bought an intricate Patek Philippe of code, that might be as fit for purpose as a Citizen, if it works at all.

Now, you can't sell a Patek Philippe by saying it's the most expensive out there. It has to be "the best" which is reflected in price. And you don't really ever make the comparison because it wouldn't reflect favorably. The aesthetics are, of course, top notch, but the sales copy is full of specs and descriptions of the arcane, lots of words to say it's the watch that goes ding.

Marketing an upstart consultancy, you reach past the manager who makes these safe, expensive decisions, and you try to do the Apple thing mentioned in the article. You'll be laser-focused on providing value, lots of easy wins that the manager can show off at every opportunity. They will wonder who their wizard is that is doing all this with only 4 team members while the other project is using 30 and has nothing to show for it yet.

Familiarity eventually causes the manager to short-circuit the upstart's sales pitch. They get 10 minutes into it and the manager says, "You mean you're just Agile? We already use Scrum. Boring." So the upstart will have to come up with new things to stay ahead of the established player.

I remember there was heartbreaking posts years ago by an Australian author of a popular Delphi library. He basically said people loves his libraries but few would pay for them, so he gave up developing Delphi libraries all together.

Over the years, what I learned is that individuals or companies do not like paying for technologies. They pay for products. In the case of technologies, companies rather pay for "boring" workflows. For instance, companies pay for control planes, so much so that Amazon's Open Search can be a billion-dollar business. On the other hand, few companies would pay for AWS AI's Key Phrase Extraction or Amazon Forecast, unless data processing is part of the service and is a huge pain for the companies.

The vast majority of coding jobs do not fall into the category of "company wants you to solve their problems". The vast majority is literally just paying people to code whatever it says in the Jira ticket, no matter how stupid or unclear that ticket is.

A power plant stopped working. None of the engineers could fix it. They called the retired engineer who designed the power plant years ago for help. He arrives, looks at the control room panels, walks through the plant, pulls out a screw driver, and turns a screw. The power plant starts working again. He quickly writes an invoice for $100,010. The manager complains asking why he is charging so much when he only turned one screw. The engineer replies, "I'm charging $10 for turning the screw and $100,000 for knowing which screw to turn."

Hot-ish take incoming:

It's even less complicated than all this. You spend X on a feature to increase revenue by Y. You pay a plumber N so you don't have to pay a flooring guy 10N. In some orgs, if they're large, you could replace $ with $KPI, but $KPI should still be obviously quantifiable. If you're an engineer without obviously quantifiable KPIs (especially if you're a young-ish engineer with ambitions of becoming really excellent one day), you might consider selling your skills to a more serious employer.

See a related concept in product development, ‘jobs to be done’. In a sentence: people don’t pay for products, they pay for jobs to be done. There’s a famous example about milkshakes (YouTube).

Using Apple as an example seems silly because from what I see they agonize over the tiniest quality details in their products (and still often get it wrong). They spent almost 5 years and billions building an AR headset that possibly doesn't even have a market. This is the biggest and most successful business ever, how does that factor into the "generate business value" rhetoric.

I think there are job where you very much need this mentality and then there are jobs where you don't have to bother much with the non-technical.

Maybe the later are harder to find on demand, but there are plenty there.

There are benefits and tradeoffs each way. I think the most important thing is to know what kind of person you are and what you want, and move towards finding work where you can be mostly actualized in that.

> So keep the technical talk to your peers, unless the client explicitly asks for it.

This! Adapt the message to the target audience. The code we write is an abstraction, it takes some input and produces an output. For many it's a black box or can be thought of as a black box. Start high and go lower and lower until you reach the right level of detail for the person you're communicating with.

This is indeed a good point to keep in mind. I do tend to forget sometimes. As a perfectionist I'm always planning code refactors in my mind, but rarely do they see the light of day; they're often minimal and don't add anything to the solution. There's very little added value.

Know your audience – know what they need, and you can develop accordingly.

Always the same story. Nobody "cares" about how it's done, until they do. If the plumber throws crazy glue and scotch tape enough so it stops leaking for a day, is the job done ?

There are principles to master in how to make a job good enough considering the time / budget constraints.

Also known as the “jobs to be done” pattern.

This is why I don't ask permission before eliminating technical debt: eliminating relevant technical data is part of solving the problem I'm currently addressing, and it's an implementation detail.

Another flavor of the original "Why would you hire a milkshake?" story [1].

[1]: https://www.youtube.com/watch?v=sfGtw2C95Ms

Excellent Article!

I think many ppl here should not just read it once but several times and try to learn.

Next step after that: — how will team work and nice&pleasant interaction with colleagues help me achieve things.

A typo: "well enought" -> "well enough"

unless you buy an off-the-shelf product/solution, you're in effect buying a service of some sort and the low-level/technical implementation is just detail (coding, plumbing, rebuilding car engine etc).

p.s. to me the OP read like a Cover Letter for a job application :)