5 ms·

Well, actually no, the author is right. You are paid to deliver results, be it adding new features, processing data, making widgets or whatever. The business r

by marrs 10y ago

Well, actually no, the author is right. You are paid to deliver results, be it adding new features, processing data, making widgets or whatever. The business really doesn't care how you do that. 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

kordless 10y ago
You are buying into the author's conflicted statements and continuing to spread the dissonance. Dissonance is what got us into this stupid Trump situation. I'm telling you that you can't tell someone who says they are paid to write code they aren't paid to write code and then rationalize some weak argument why you are "right". You aren't right because op is telling you they are paid to write code. All that matters is that "op" is "writing" "code" because they said they were. You don't get to say if they are or not, and the author doesn't get to either! 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.
whoops1122 10y ago
technically speaking, no I m not paid to write code, if ask that question during an interview, company would tell you that they dont pay you to write code as well. 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.
JamesBarney 10y ago
I think a thought experiment illuminates the difference. Two different but identical companies with unlimited vacation gets too people to do the same project. 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.
- user5994461 10y ago
  > In these two situations Steve objectively did far better, but I bet your sweet butt that he gets fired, and Walter gets promoted. 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.
  - TeMPOraL 10y ago
    He delivered shit ton of code; managers have seen the progress pretty much daily, or at least weekly. The failure of the project can be blamed on many things - so ultimately, maybe Walter was just digging the right (albeit crude) ditch but at the wrong place. Someone else's ass may or may not get busted for the project flop (depends on the size of the company, usually). 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).
leepowers 10y ago
> Obviously you do write code in the course of providing those results 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.

by marrs 10y ago

kordless 10y ago

You are buying into the author's conflicted statements and continuing to spread the dissonance. Dissonance is what got us into this stupid Trump situation. I'm telling you that you can't tell someone who says they are paid to write code they aren't paid to write code and then rationalize some weak argument why you are "right". You aren't right because op is telling you they are paid to write code. All that matters is that "op" is "writing" "code" because they said they were. You don't get to say if they are or not, and the author doesn't get to either! 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.

whoops1122 10y ago

technically speaking, no I m not paid to write code, if ask that question during an interview, company would tell you that they dont pay you to write code as well. 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.

JamesBarney 10y ago

I think a thought experiment illuminates the difference. Two different but identical companies with unlimited vacation gets too people to do the same project. 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.

user5994461 10y ago
> In these two situations Steve objectively did far better, but I bet your sweet butt that he gets fired, and Walter gets promoted. 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.
- TeMPOraL 10y ago
  He delivered shit ton of code; managers have seen the progress pretty much daily, or at least weekly. The failure of the project can be blamed on many things - so ultimately, maybe Walter was just digging the right (albeit crude) ditch but at the wrong place. Someone else's ass may or may not get busted for the project flop (depends on the size of the company, usually). 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).

leepowers 10y ago

> Obviously you do write code in the course of providing those results 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.