Sponsored by #native_company#
#native_desc# #native_cta#

We're Not Paid To Write Code, We're Paid To Deliver A Product

You're not paid to write code, you're paid to think.

This is one of the first things new hires on my team hear from me. It's a nice concise way of saying I don't care how quickly you finish the task, if its poor code it's as useful as a trap door on a lifeboat. It's become one of my favorite little quotes.

The idea is sound: we get paid to think about problems presented by your customers, and then devise solutions for them. The idea here is that because we should think first and code second, we aren't being paid to write code, we're being paid to think up a solution. This quote is powerful, and that's why I use it so often.

It's simple, effective, and total bullshit.

We aren't paid to think. We aren't paid to write code. We're paid to deliver a product. Our knowledge, skills, attitude, all of the attributes that could make us effective programmers don't mean anything if we can't deliver a working product to our customers.

No customer has ever said, "Well, if only these indents were spaces instead of tabs, this code would be more readable." No customer has ever demanded that we use one-way hashing for storing passwords and actually knew what that meant. No customer has ever forced us to take extra time to think about all the possible architectures and platforms and then use the one that we think best fits the problem. No customer has ever inquired as to what the code standards are on their project.

The customers don't care about the code, don't care about the architecture, don't care if the entire system is powered by an army of hamsters running in their wheels and written by an infinite number of monkeys. They just want their problem solved.

The real danger lies in thinking that either of these two extremes are acceptable: that our job is to write code OR think, and never the twain shall meet.

Let's meet a couple of new programmers, who I will call Sam and Ted. Warning: extreme caricatures follow.

Sam is a new hire from a local college, where she graduated at the top of her graduating class. She passed the interview and the FizzBuzz test with flying colors, and she's now beginning her first day as an employed (for pay!) programmer. You, as the project lead, assign her her first task. It's nothing too difficult since she's just started, something you (as an experienced developer) could do in about an hour, but to be conservative you estimate that it'll take her around a day to complete.

It takes her a week. After the second day, whenever you check on her, she tells you that she's doing fine and the code will be perfect. And when she finally is done, she's correct: the code is utterly perfect, a glorious sight to behold. But it took her a week to complete a task that really shouldn't have taken longer than a day.

Now let's meet Ted.

Ted is starting on the same day as Sam, and he's a recent transfer from another department in your company. His interview went well enough that he was hired, even though he completed the problems really quickly. You also give Ted a relatively simple task, one that should take about a day.

It takes him an hour. In the middle of your lunch Ted comes running down the aisle to your cubicle practically begging for another task, proud of the work he's done like a dog who's killed a rabbit and brought it to his master for inspection. He so damn proud of himself that you can almost see his tail wagging. But his code is nothing to be proud of; it's an unreadable hodgepodge of copy-and-pasted snippets and poorly-named functions, badly organized and terribly explained. You'd need a sword to untangle the mess.

Who would we rather have on our team, Sam or Ted? Neither. Which of these two can actually deliver? They're both just as bad; one thinks too little, the other thinks too much.

That's the problem with mantras; they're never as simple as they proclaim themselves to be.

We're not paid to just code, we're not paid to just think, we're paid to do both in enough measure that we're able to develop a product that solves a problem. Ultimately, we're paid to be pragmatic, we're paid to be smart, and we're paid to deliver. Nothing else matters.

Matthew Jones

Matthew Jones

I'm a parent, a husband, a geek, a web developer, and a speaker, in roughly that order.

Read More
We're Not Paid To Write Code, We're Paid To Deliver A Product
Share this