Hacker News Reader

Well... no, it doesn't make you money. It means you pay out less in taxes. There's no more income, just less outgo.

I've boiled down my programming-skills to people sometimes by saying "I can use computers/web/IT to do one of two things: bring in more revenue, or reduce your operating expenses". That's pretty much what everything boils down to.

Accountants, almost by their definition, aren't going to be able to increase revenues. They might increase profit by reducing outlays, or shifting money around to different tax years and such, but fundamentally accountancy activities aren't going to increase revenue.

Most IT projects don't increase revenues on their own either - it's generally in conjunction with initiatives from some other department. But sometimes the increase in revenues that can be generated with strong IT/web initiatives is enormous.

However... most of us are focused on the 'saving money' aspect, similar to accountants. We can optimize processes in an organization, increase auditability, generate more reports faster, etc.

EDIT: "The same direct profitability cannot be said about programmers. At best it is indirect" Ummm... just to be clear, yes it can. If I do a project for someone that costs, say, $100k, but allows them to bring in, say, $3 million in extra revenue, it's a no-brainer. The project increased revenue (and, well, it's a no-brainer to do if it increases profits). But I may do the same project for $100k which allows a company to reduce its internal helpdesk needs from, say, 25 people down to 5 people, saving $400k per year. That should generally be a no-brainer too.

It's pretty easy - I'd say often easier, to justify developer or software project cost/benefits/ROI vs an accountant's abilities, simply because the laws surrounding taxes are impossible for anyone to fully understand. That huge tax deduction you got might come at the expense of an audit 3 years from now. Even if you 'win', the cost of the audit needs to be factored in later.

"But I may do the same project for $100k which allows a company to reduce its internal helpdesk needs from, say, 25 people down to 5 people, saving $400k per year. That should generally be a no-brainer too."

Here's the problem I have as a manger. Answer me these questions:

1. How do I know your software will actually allow me to replace 20 people?

2. How do I know the project will succeed, i.e. actually finish in a usable state?

3. How do I know the project will be on-time or on-budget?

Historically, software projects fail all three of these questions rather regularly. And most people who have any kind of dealing with software know this, so they know that it may end up costing them $200,000 to replace old software with buggy new software which doesn't do everything the old software did, requires training new people, and maybe doesn't even reduce costs.

That's what the parent meant - software projects are not as predictable as accounting. They also tend to take much, much longer and cost much more before you see whether they worked or not.

To be fair, part of this is because companies consistently cheap out on programmers in a way they don't with accountants. I've worked with some tremendously good software consultancies that can really turn out product, but they charge exorbitent rates, just like PWC, etc.

Which I think is the point we're making here. Programmer should be paid more, and one of the ways to be paid more is to be more consistent in quality and price.

But it's very hard for a potential client to gauge how good someone is. As opposed to accountants, who you can tell are good by school, company they work/worked for, etc. With programmers, at least today, you really don't have anything near that level of credibility - at most, you can work with firms that have a proven track record, but like you said, they cost a lot more in the long run.

How do you know accountant X won't fiddle the books and land you in hot water? How do you know all the deductions are kosher. Even well-meaning financial people have conflicting views on what's allowed and not allowed.

When talking about hiring an accountant or firm, it's still a crap shoot until you have a relationship and track record with them.

Less so. With accountants/lawyers, you can usually tell someone is at least decent by school/company they work for/companies they worked for.

There's also a lot of government intervention to make sure they act legally - I'm pretty sure that most countries force CPAs and lawyers to have a minimum level of credibility (studying, passing tests, etc.) This makes it easier to make sure the majority of the population makes at least decent decisions.

Separate reply.

"Additionally, programmers would do well for to adopt an accountants mindset toward explaining and justifying the reasoning for everything."

It'd be great to be able to do that all the time. OFTEN, however, the 'programmers' aren't treated with the same deference accounting is given, and aren't told about strategic plans and directions. They're effectively kept in the dark and treated as assembly-line workers. Any justification that a developer might give for implementing a change can be dismissed because "you don't have the full picture", followed by "and we're not giving you the full picture".

What was odd about that situation (one in particular, been in 2 I can recall) is that the development/IT people are often positioned in such a way as to have to be aware of everything, and sometimes know more about what various departments are doing, where efficiencies can be implemented, and possibly what changes could benefit the org as a whole, and yet still get treated as line workers.

I realize not every developer has to go through this, but if you recognize yourself in that situation, realize it gets better, and you can do more with your talents/skills if you want to.

That's why you have regular HNers like patio11 arguing that the way to make it as a consultant is to own your business outcomes. If you frame a project to a client as "you have X problem. I solved a similar problem X' for another company using solution Y, and it led directly to a $Z increase in revenue", then as long as $Z > your rate they can appreciate what a no-brainer it is to hire you.

Of course, it's much easier to navigate yourself into that sort of position if you're an external consultant than if you're a salaried engineer whose manager hands you specs. Figuring out how to make that shift within the confines of a larger company's bureaucracy is phenomenally difficult.

At the margin, every employee makes the company money or saves the company money. You do a marginal analysis: if you get rid of the employee, does the net income go up or down?

Whether the contribution to net income is direct or indirect is irrelevant in determining that person's contributon to the bottom line. 1 accountant who bills $500,000 isn't really different than 10 engineers who build a product that brings in $5m of revenue, in terms of the bottom line.

Direct versus indirect is, however, relevant to compensation. It's much easier to negotiate a higher salary when your contribution to the bottom line is direct and easily measurable. But that goes to my point of there being more things that go into salaries than supply/demand. Whether your contribution to the bottom line is direct or indirect shouldn't affect salaries, theoretically. In theory, people don't get paid what they're worth, their salary is set by market forces and supply/demand. But in practice that's not the case.

> at best it's indirect.

Sometimes everything you sell is made of software or information services. The value of programmers is not indirect in those cases.