Well, actually yes, yes I am. You can make a compelling case that this shouldn't be the case, or that they people paying me are shooting themselves in the foot running things the way they're running things, but the fact remains that in today's daily standup/weekly status report/what have you done for me lately "agile" corporate environment, I am absolutely paid to write code and if I don't write code, they'll stop paying me.
Obviously you do write code in the course of providing those results, and all of the author's examples of what you should be doing are still examples of writing code, but they are the minimum code required to deliver results.
Another example of how you're not paid to write code is the frown you receive from stakeholders every time you say you are going to refactor something, or that you are going to rewrite the API to be RESTful.
They don't care, and they shouldn't
It's completely asinine and blaming to speak for others actions. Stop doing it. It's ruining this place. <-- This last part is a blanket blaming statement speaking for all others and I really shouldn't say it.
P.S. I've flagged the article given it's making "you" statements.
However, when most of the companies's idea of "agile" development cycle is to have smaller goals and very short deadlines, you end up being a code monkey. A project may run better if you have time to design a better object structure, instead because of a tight deadline, we have to slap on 10 if and else if statements then call it a day.
when making an enhancement? add 2 more if statements, fix a bug? put some if statements under the previous if statements.
bottom line, because of the tight deadline, better code and better design means nothing. we become if statements code writing monkeys.
Workaholic Walter shows up to work 7 days a week, works 10 hours days for 3 months busting his butt to write a piece of software that ultimately fails because he spends so much time working he misses the big picture.
Smart Steve does some research decides the project already exists in open source downloads it, sets it up in a week. Then decides to take a 10 weeks vacation because he just saved the company so much money.
In these two situations Steve objectively did far better, but I bet your sweet butt that he gets fired, and Walter gets promoted. The problem is no one ever really knows how much value you added, or how much work you did.
I've been on projects that were incredibly successful from a technical perspective. Objectively the product performed exactly like the stake holders wanted, the performance was great, it could run for months at the time, even while actively being configured by people completely unfamiliar with the software and not crash. It was still a failure because no one wanted to buy it. We spent a year kicking butt and still added 0 value to the business. But I will still paid. And I wouldn't have been paid any more if the project had instead resulted in an extra $12 million in revenue.
You pay a hair stylist to cut your hair, not for the business deal you may or may not get because of it. Why someone pays you is different from what you are paid to do.
I wouldn't bet on that.
Noone is aware that Walter overworked because noone saw him. Plus, he didn't delivered anything in the end.
In the meantime, Steve gets sacked because he's obviously not working - so why he should get paid?
The point is, companies would want you to focus on business goals, but in fact they pay you for the amount of code produced (and punish you if it's low).
I know Walter. He made a big point of sending e-mails at 2 AM, CC-ing the recipient's boss, and then following up at 8:00 the next morning asking why you hadn't responded yet.
The question is whether it comes from Walter or from the company. Either let him go or move to a better environment.
Well, then you _are_ being paid to write code. We can yammer on all day about how we're adding value, but the programming skill and talent has to be there first. So you're both being paid for the value of your skills (being able to code proficiently and efficiently) _and_ for increasing the equity or profit of the business.
An analogy might help. When I pay a contractor to add improvements to my house my goals is to increase my home equity. So I am paying for value. But I'm also paying for his skill. Because if I get an unskilled contractor I might end up underwater. An unskilled contractor can cause me to go backwards, where the cost of fixing his bad work costs more than the equity boost. The same dynamic applies for bad programmers. Skill is the primary driver that causes any increase in value.
> but they are the minimum code required to deliver results.
We're not looking for the minimum amount code, but the best solution. Writing tests will add overhead to your code. At a minimum you could leave them out. But the benefits of rigorous testing can justify the investment of time.
Dijkstra: 'My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.'
'Measuring programming progress by lines of code is like measuring aircraft building progress by weight.'
You are the steering wheel that alligns the overall thing's behavior with the interests of the organization that owns the thing. That's what author calls "adding value".