4 ms·

> solve their business problems Your job is to solve business problems. You happen to use code as the tool to do so because it lends itself to building better,

by Swizec 10y ago

> solve their business problems Your job is to solve business problems. You happen to use code as the tool to do so because it lends itself to building better, more reliable, more scalable solutions. Nobody pays for a lump of code, they pay for a tool that solves a problem they have.

Beltiras 10y ago
Incidentally this very often comes about by writing code. Or installing new systems. There's a strange broken circularity to that blogpost.
blub 10y ago
Depends really. A surprisingly large number of organisations don't seem to be equipped to handle business input from the development staff or any kind of "productivity multiplier" contributions. E.g: making the team more efficient, reducing signup friction, fixing UX annoyances, inventing a new feature or product, improving security practices, reducing defect rates by introducing CI/static analysis/whatever. In this case the job of the developer will be to write code and it doesn't make sense to pay high salaries because the ROI is not there. This leads to the situation where very good developers aren't paid good salaries because in such a company they are literally not worth the money.
alkonaut 10y ago
The customer pays my employer for a solution and my employer pays me to create it but I get your point. I just didn't agree with the argument of the article in general - most of devs can't use a piece of shell script to solve a problem they would otherwise code. Simply because we work within the boundaries of a single product such as a large desktop application. I don't solve my employers business problems, I solve the customers business problems an the only way to do it is to code it in the application.
douche 10y ago
> Nobody pays for a lump of code, they pay for a tool that solves a problem they have. A more cynical situation, which I have seen all too often, is that they pay for the line items on the RFP. Whether or not those features will ever be used or are in any way beneficial.
TeMPOraL 10y ago
Except there are two common problems here: - NIH. If you think it's programmers who primarily suffer from NIH syndrome, check again. Just how many times you end up writing something that's already done because your bosses insist they must have an in-house solution? - Nonsolving a nonproblem. A lot of code we write is meant to solve a problem that doesn't really exist, is created by stupid decisions higher up the chain, or sometimes just shouldn't be solved in the first place (e.g. tools facilitating an unethical business model). So yeah, I'm often paid to write code - because the decision that code must be written is made by people above me.
OpenDrapery 10y ago
Sometimes, as a developer, I ask higher level questions about the business. Who is the customer? What problems do they have that we are trying to solve? How does this business make money? How are the executives measured? These are questions that are relevant if you want me to add value in a non code monkey way. But, sometimes, when I ask these questions, I get looks that say "You're paid to write code, so stop asking non code questions." Or maybe I'm just projecting.
leepowers 10y ago
> Nobody pays for a lump of code, they pay for a tool that solves a problem they have. Of course they're paying for code. They're paying for code that does something useful, and which may or may not produce value for their business. You can't separate the two.

by Swizec 10y ago

Beltiras 10y ago

Incidentally this very often comes about by writing code. Or installing new systems. There's a strange broken circularity to that blogpost.

blub 10y ago

Depends really. A surprisingly large number of organisations don't seem to be equipped to handle business input from the development staff or any kind of "productivity multiplier" contributions. E.g: making the team more efficient, reducing signup friction, fixing UX annoyances, inventing a new feature or product, improving security practices, reducing defect rates by introducing CI/static analysis/whatever. In this case the job of the developer will be to write code and it doesn't make sense to pay high salaries because the ROI is not there. This leads to the situation where very good developers aren't paid good salaries because in such a company they are literally not worth the money.

alkonaut 10y ago

The customer pays my employer for a solution and my employer pays me to create it but I get your point. I just didn't agree with the argument of the article in general - most of devs can't use a piece of shell script to solve a problem they would otherwise code. Simply because we work within the boundaries of a single product such as a large desktop application. I don't solve my employers business problems, I solve the customers business problems an the only way to do it is to code it in the application.

douche 10y ago

> Nobody pays for a lump of code, they pay for a tool that solves a problem they have. A more cynical situation, which I have seen all too often, is that they pay for the line items on the RFP. Whether or not those features will ever be used or are in any way beneficial.

TeMPOraL 10y ago

Except there are two common problems here: - NIH. If you think it's programmers who primarily suffer from NIH syndrome, check again. Just how many times you end up writing something that's already done because your bosses insist they must have an in-house solution? - Nonsolving a nonproblem. A lot of code we write is meant to solve a problem that doesn't really exist, is created by stupid decisions higher up the chain, or sometimes just shouldn't be solved in the first place (e.g. tools facilitating an unethical business model). So yeah, I'm often paid to write code - because the decision that code must be written is made by people above me.

OpenDrapery 10y ago

Sometimes, as a developer, I ask higher level questions about the business. Who is the customer? What problems do they have that we are trying to solve? How does this business make money? How are the executives measured? These are questions that are relevant if you want me to add value in a non code monkey way. But, sometimes, when I ask these questions, I get looks that say "You're paid to write code, so stop asking non code questions." Or maybe I'm just projecting.

leepowers 10y ago

> Nobody pays for a lump of code, they pay for a tool that solves a problem they have. Of course they're paying for code. They're paying for code that does something useful, and which may or may not produce value for their business. You can't separate the two.