Short version: program things which make your employers lots of money, and get in the habit of mentioning that repeatedly when you negotiate aggressively for more compensation. Long version: http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...

A personal anecdote: In 2006 I wrote CRUD apps, talked to people, and read a lot of documents. In 2013 I will write CRUD apps, talk to people, and read a lot of documents. I'll also get paid probably in excess of 10X what I made in 2006. To the extent that the difference involves programming, it's largely not because I've suddenly graduated to Guru Rockstar Ninja and more because I figured out how to apply programming to a few of capitalism's pressure points. (Mostly involving selling more software.) This turns out to be fantastically more valuable than writing CRUD apps to e.g. manage student lists for university back offices. This difference is a lot more important than other competing explanations like where I live, what industry I work in, or the fact that I changed from J2EE to (mostly) Ruby on Rails in the interim.

There are many HNers whose programming skill is a key asset to their line of work and yet would not be classified as programmers, by the way. I encourage you to not see their jobs as out-of-scope if your goals are making a lot of money while continuing to program. That's quite a bit of the solution set. (Then again, AmaGooBookSoft have many, many uncomplicated "We give you instructions, you producing working code implementing them" jobs which would meet your requirements.)

Consider a real estate agent. Real estate agents spend most of their time prospecting for leads. Leads convert at X% into sales, where the agent earns 6% of the transaction price. Any system you can deliver for a real estate agent which increases the number of leads they have or the percent which eventually turn into sales solves a problem for them.

Consider an insurance company. Insurance companies have prospects and successfully sell some percentage of them policies, which transfer risks from the insured to them. The insured occasionally suffer losses, which results in them filing a claim against the insurance company, which the company will investigate and probably pay. Between the time an insurance company collects payments and pays claims, it has use of the "float" created by money which is probabalistically owed to someone but not paid yet on its books, and it can invest this float profitably. Software can increase the number of prospects they have and/or the percentage of prospects who are successfully convinced to buy policies. Software can assist (or replace) very expensive human underwriters, who judge whether a particular client is worth taking on and, if so, at what price. Software can greatly improve underwriting profits. Software can streamline the costs involved in processing claims. Software can be used to assist companies in paying out less claims that are actually outside of their policy requirements but which had previously been paid due to error or the infeasibility of adjusting them profitably. Software can increase the profits of management of float.

Consider a SaaS company. Ignore the product. There's four numbers of interest in that company: visitors per month, new trials per month, average plan price, and churn rate. Software can move those numbers up, up, up, and down, respectively.

Working in any industry will tend to expose you to a lot of these opportunities. After you have the mindset, the question is more-or-less as simple as asking an accountant "How would you look at a company and find where money is being spent?" I mean, if he were pressed for time, he might say "By looking", though there's a longer way to phrase that.

What is your opinion on the effectiveness of speaking to people and asking them directly about their problems? Or am I better off reading industry magazines/blogs/forums and kind of examining them in their natural habitat?

I don't think that was the takeaway I was going for. An accountant, told "Tell me where the money goes in a taco truck", would be able to do do a napkin sketch of that in under a minute. "Describe at least one business problem amenable to a software solution that a taco truck has" does not strike me as being terribly difficult. (Actually selling it to them in a scalable fashion? Much more difficult, but that's largely because they're a taco truck.)

What is your opinion on the effectiveness of speaking to people and asking them directly about their problems?

I find that listen to people is often an effective strategy for learning from them. I feel I have to add the disclaimer "That is my sincere attempt to answer that question" to that sentence. Often, not-software-people do not have a great handle on what software could actually do for them, so asking them "What software do you wish existed?" doesn't work all that well, but asking them for top-of-mind business problems is not that difficult.

Or am I better off reading industry magazines/blogs/forums and kind of examining them in their natural habitat?

These two activities don't compete with each other. Either or both are more effective than neither. Don't do neither. If you're currently doing neither, start doing either or both.

In my case, I was working on the help desk, and was sort of a hobbyist programmer. Answering help desk calls on the night shift was boring work, and because I was the only one working at night, I didn't have the luxury of getting to ask others what the answer was. I either knew the answer, or knew how to find it.

Knowing how to find it was tricky. The Windows group (that supported Windows servers) kept all their information in Sharepoint. The Lotus Notes group kept all their data in Lotus Notes databases. Unix group kept all their documents on NFS shares. Each group knew how to find their data, so it was great for them. But the problem is that if the Tier 1 support can't find it, they have to escalate to Tier 2. This costs more in terms of hourly wages, delays customer satisfaction, and takes longer to solve problems.

My solution was to write a central, web-based knowledge base, and I wrote convertors to go to each of the knowledge stores and import it into the knowledge base. Now, as a Tier 1 help desk, I only had one spot to go to for finding knowledge. Customers got support faster, less calls had to be escalated to Tier 2, and all was right in the world.

Later I refined the crap out of it and made it really pretty good, but that initial implementation saved the company a lot of money. By not having to engage Tier 2 support as much, that meant they could be working on their regular jobs, like managing servers of streamlining application processes or whatever it was they were meant to do. By offloading the work to the cheaper Tier 1 help desk, that was cost effective. By reducing the time it took to satisfy a given customer request, that meant less workers could handle more calls. That's cost effective. That was a problem that they would have been willing to pay $xxx,000 to solve, because it saved them well more than that, but I just wrote it for them and let them know how much it was saving them.

I didn't initially make more money, but I did get moved into a position where I could do more of that, which I did. At some point, I was awarded for having saved the company an average of 3 million per year. At the time, my salary was something like $50k a year. I never struck gold working at that company, but "developed applications to reduce company costs by $3 million per year" looks pretty good on a resume. It sets you apart from the vast majority of developers who are just going to build what they're told to build. It shows that you take initiative, and that you care about more than just what's in the scope of your job -- you care about the company, and the company's bottom line, and can actively impact that bottom line.

Well, if it had to be spoon fed it would have no value, because everybody and his cat would be doing it.

That's why you'd make the big bucks. Someone just telling you what to build makes you contractor bucks. Looking at a business problem, and identifying how you can apply your programming skills to save or make your company money makes you rock star bucks

- started in a particular industry

- Kept working in same industry and built "domain expertise". Need min 5+, ideally 8+ years of "actual" experience.

- Changed jobs 3-4 times within the first 5 years. But remained in the same industry. Built a lot of networks/contacts on the way. (Job hopping is not necessarily a bad thing in today's world if you know how to do it properly). Every hop, negotiated a good raise (15-20% in US is good raise). I always sold myself using the "value" that I was already bringing to the table because I was in the same domain doing specific thing that the next employer really needed.

- Finally after 5 years of solid experience, decided it was time to go consulting on my own. Started talking to all my contacts in the industry where I was already known/valuable and started somewhere. Charge flat Daily rate and take care of your own expenses.

- Raise your rates at the end of every engagement. But try and get long term engagements as well. Personally, i work on 18+ months contracts (the nature of my industry and projects). So by the time you are done 1st time, client usually wants you bad enough to give you a decent raise. Won't always work however.

- Never settle for less if you know your worth. So first figure out what you are worth to a prospective employer whom you are interested in or who is interested in you. Always fight for the extra few grand. Why ? Because the next time you are negotiating with the next guy, those few grands will make a difference on what number you are asking for next. People always look at what you are making currently unless you are an expert in your field or were currently underpaid for whatever reason etc.

If you want to make money you have to be a businessman in addition to being a good programmer/engineer or else other businessmen will take the money on the table.

Specifically, I built mobile components and server systems for mobilizing data (spreadsheet-to-app conversions, etc). I then used these components and services to help speed up their mobile strategies, provided high quality training materials, and positioned my company for long-term revenue from licensed IP.

I'm currently at the stage where I have a strong client list and a marketable product, which is attracting investors, more clients, etc.

It's just myself and one engineer at the moment. I do both design and development for mobile and back-end systems.

Btw, you don't need to move to the Valley or NYC. I traveled the majority of 2011. All client work started as onsite engagements, then moved to remote.

Hopefully sharing this will help you in some way.

EDIT: I meant "seconded" in that you'll obtain your $120k salary in high COL areas, but it's not necessarily the best choice. I wasn't advocating actually moving there (I'm in Austin)

I don't really get this part, though it's a common sentiment. Here in Copenhagen, most apartments don't have elevators. Many people are busy, but I have never heard someone complain that an elevator is the bottleneck that would let them relax more. What proportion of your day could possibly be spent on the stairs? It takes me maybe one minute to walk up the 5 flights of stairs to my apartment. It's good exercise, too.

It's an issue for people who have mobility problems, but it's not a time problem.

Granted, you're not in SoMa or Manhattan, but in those cases you're $120k = ~$45k... so why not make well over $45k, say in the $60-$100k range based on skill/ experience/ demands, and actually "feel" like you're making every cent of it.

New grad rates tend to be $50 - 70k, while some bigger companies offer ~$90k.

$90k in Austin is a much better standard of living than $120k in Bay Area though...

Granted, if you've only been programming for five years you're probably going to only be looking at 80K if you're good (50-60 if you're merely okay). But 100-120 with ten years experience is in the range of what I've seen locally.

Also, you'll need to know .Net or Java.

Edit: Also, TN has no state income tax.

Second, you have to be more than a programmer, you need to be someone who can blend roles into project management, business analysis, strategy etc as well as make the people around you better.

Third, you need to in demand skills but maintain versatility. This is hard work. I work a 40 but I practice another 10-20 every week.

Enterprise is never going to be as sexy as working for a startup. But they do have project budgets that exceed most company A rounds. The work is not very exciting and things often have to be done in ways that you wound never even fathom on a personal project but they make up for it by paying above market rates.

Please also clarify whether you're a single or have a family.

I've been working for 25 years and haven't crested the $100K mark (upstate NY & midwest) in gross salary. But that goes a long way here.

However I get several weeks of paid vacation, health insurance, 401K match, profit sharing. Any other position I have looked at lately is a step backwards from that.

In a year or two, I'll be moving my family to the Nashville area, while retaining my Bay Area job, and it's pay scale.

One day I'll sleep again.