Comment by viandante | Hacker News Reader

Comment by viandante | Hacker News Reader

Business analyst/finance here. I believe you are generalizing quite a bit. Some types of programming skills are a commodity. Such as some types of 'analytical' skills: all that is done on a spreadsheet on a regular basis is a commodity, that is why there are so many 'analysts' in the emerging countries.

Regarding programming, making 'apps' in .NET for a big corp is considered (and maybe it is) a commodity by the management. So, if you want higher salaries, you may want to move away from that.

What also doesn't help the programmers (generalizing again, but let's do it for the sake of discussion) is this complete misunderstanding they have regarding the 'suits'. It is absolutely true that a lot of 'suits' talk BS, but they do have a feeling of the business that programmers seem not to have, otherwise there wouldn't be so many todo and project management apps out there.

My strong advise would be to actually move away from the technical side for a moment and talk with the 'suits', ask them what problems they have, ask them about the business, etc. Companies have so many problems, but they are totally disregarded and this kind of discussions don't help.

Now, a programmer that cares about the business: that is a skill that is not a commodity...

Last few bigger companies I was in, as a developer, I was involved in multiple meetings, often with different project managers for different projects. The one constant was me (and a couple other devs), being involved in meetings with marketing projects, financial reporting projects, upcoming IT purchasing decisions, operational IT issues, and more. Guess what? The developers involved in these meetings had a pretty solid view of the entire business. Yet almost any time a suggestion was made by a developer based on info from other project meetings, it was shot down or dismissed. (not 100% of the time, but close). I saw this behaviour at 3 companies of varying sizes (between 150 and 2000 employees).

Developer suggestions were generally based on a broader view of the business' overall needs (because of the breadth of discussions we were involved in) than other people at table had, which apparently can be threatening, regardless of how you present things politically.

I realize not everyone as a developer gets in those situations. Sometimes you're chained to one project and set of people for months on end. If you're not, you can have a much better view of the business needs, but that doesn't mean anyone will listen to you as a developer. You need to move out from being perceived as such - either by changing jobs to another company, or occasionally within a company. I've never had the latter option work out for me, but have seen a couple people do that successfully.

I usually assume that the suits are usually normal people and good programmers are usually smart people. That doesn't mean that what a smart person says will be listened.

You have to see the world like them, think like them and, especially, talk like them. You have to understand their incentives in the company. Etc. If you don't make clear for them why your proposal is beneficial (to them, not to the company), then you lose.

"If you don't make clear for them why your proposal is beneficial (to them, not to the company), then you lose."

Fair point - basic human nature - but then people need to stop saying "you (developer) don't understand the business needs or the company's needs". I understand them quite well. If "the company" continues to employ people who need constant ego stroking every 5 minutes, then they'll continue to bounce along, and I'll go sell my skills to one of their competitors who is more open to input from all levels (to the extent any of those exist in that industry!) :)

Well, companies' needs and suits' needs intersect at some point. You have to be smart enough to see that intersection and to propose things that look good on both sides.

Even though you felt you went to more meetings and therefore had a "broader view of the business", perhaps the project managers also attended meetings that you were not involved in, which gave them insights you could not have possibly known? For example, maybe during weekly PM meetings where all PMs gave an update of the projects they were managing, your PM also developed a strong sense of what was going on in the business? Maybe the PMs attended meetings where the corporate strategy was discussed, which you did not attend?

Not recognizing that others may have vantage points that were unknown to me was a tough lesson to learn, but an important one. It's difficult to speculate on what someone else may know or not know.

In some cases that may have been true, but in most cases it was not. This spoke to poor company communication more than any awesomeness people think that I think I possess.

The suits have 'a feeling of the business'? If its as accurate as their views about 'commodity programmers', that explains a lot.

Management's output has no unit tests, no spec, few stats to hold accountable short of annual revenue. In my experience (30 years) they function through a combination of personal feelings and witchcraft. Those that luck out are considered special for no good reason - statistics shows there are usually outliers, so a dart-throwing monkey may do as well.

Ask the suits what problems they have? Its their job to drive the program. As 'commodities' why on earth should we have to pry vital information out of some overpaid manager? I don't mean to be spiteful here, but managers that don't know intimately the details of their program, tasks, direction and resources are useless drones.

You are wrong. Management does have output test: financials. Every executive is measured on the impact he has on the P&L and KPIs. You can say those metrics are flawed, and they can be, but the same most of the IT stuff I saw in my company is flawed (because it comes from commodity programmers).

Of course, the suits are mostly unpleasant people that do not respect your work. However, being the programmer generally a smarter guy, he could try to understand what the world vision of the suits really is (mostly: more profits, less cost) and work around that. Have you ever asked yourself why such horrible pieces of software like sharepoint are so common in companies? Because who sells them understands the world vision of the business people and he can put that into a crappy product and make god damn money...

Hit it on the head. more profits, less cost. And the quality spiral that ends in "those stupid commodity programmers, why do they turn out this crap and take so long?"

And the stupid commodity programmers shake their heads and turn their backs, because explaining "I said it took longer to do it right, and you chose fast and cheap every time, and now we are where I said we were going, but you made it my fault somehow" makes them sound petulant.

Yes, believe it or not we ARE trying to work around cost and earnings, but you shoot us in the foot every time. Why? Because you are rewarded using financials. And they are recomputed on too short a cycle to reflect quality.

Bottom-line is remote from most folks in a company. Executives may be accountable for P&L but not anybody below that. What does a middle manager do? They optimize for their cost and milestones-complete. Which drives them to maximize their budget and minimize their deliverables. Which, if you think at all about it, are exactly opposite to the company goals.

Down below that, you have programmers. Who mostly care about the quality of what they do. But find their manager cares less than crap about that.

So here we are. Right where your short-sighted financial goal-seeking puts us.

From the original question: Given that programming is generally more difficult […]

IMHO, one can stop reading at this point because an argument based on a flawed assumption is, well, flawed.

Well, the question is flawed as well. In many places, developers are paid as much or more than project managers.

I've found that sometimes, like you in this case, I think some stated premise is just plain wrong, but when I read on, I find that I agree with the subsequent argument. In some of those cases, that is possible because the argument doesn't actually require the premise (other possibilities are that I'm being inconsistent, that on second inspection the argument is wrong, etc.). So you don't necessarily need to stop reading :).

Regarding your last line: it heavily depends where you live. In some places, it won't get you anywhere...

That means you either move in the suits department, or you leave the company as programmer skills are not core for the business or the support of the business.

There is a continuing misunderstanding between "suits" and dev's, where most dev's _do_ learn the business through experience, but the suits continually choose not to, and instead of working as the "teacher" and filter between both areas, just push the demands down to the dev. And "yes": teacher is always part of the job.

> That means you either move in the suits department

There's also the option of avoiding working all-together for companies that employ said "suits". Which, and I thank the Creator of the Universe for that, I managed to do for the last 10 years of my employee history.

Reply on news.ycombinator.com