"...but i want more pay - how about CEO level pay?"
Even as a mid-level developer, my salary matched that of experienced project managers in my wife's previous line of work (large insurance company).
And CEOs generally lead a very different lifestyle than a good developer. On call 24/7, lots of travel, etc. And it's a different set of skills that many developers lack (schmoozing, sales, dealing with other giant egos). Compare that to my 40-45/hour work week, true vacation (with no work interruptions), and limited exposure to clients/sales/etc (which I find the most stressful part of my job - minimizing that is a good thing for me).
Junior developers: $75k-100k + $2-3k equity/bonus
Senior developers: $90k-140k + $4-8k equity/bonus
Engineering manager: $120-160k + $10-15k equity/bonus
Director or Super-smart architect: $140k-$180k + $15k-20k equity/bonus
VP (senior manager): $250k-350k + $200k-1MM equity/bonus
CxO: $300k-$1MM + $5MM-50MM equity/bonus
So when you say "Mary in the cubicle next to me makes more than me," you're probably talking about at most a $50k difference, which is a rounding error for the senior execs. You'll be hard pressed to find a non-senior exec in any line of work (engineering, QA, project management, mid-level management) whose compensation even comes close to what the big shots are making.
Is there where we get to discuss the gross over-compensation granted to CEOs in the US?
[I'm joking, I don't want to discuss that here]
- I was formally educated in FORTRAN up 'til the 95 spec. Many engineering codes still exist in it, so I've since rounded out OO Fortran. It helps me read legacy code, talk to the older engineers, and maintain it if need be.
- I built a computer with a nVidia GPU chip: It helped me appreciate the hardware side of things and enabled me to write and run CUDA (CPU/GPU) programs, which offers a window into high performance computing (HPC).
- I learned as much about the OSI stack as possible (I had the fortunate opportunity to take a week-long CCNA bootcamp training class) so I could have a rough mental model how networking works, which helps in distributed computing or HPC scenarios.
- I already knew C, so I spent time spinning up on C++ and its ecosystem, as it can be popular in engineering contexts.
If you are wanting to go the pure developer route then there are plenty of others who can provide better advice. I have come to enjoy the inter-discipline of CS and engineering.
I took some of my class notes on equations and implemented them in a variety of ways as an exercise to get used to the language while keeping the engineering knowledge relevant. For instance, when I was blazing past a variance calculation, I was surprised to learn that catastrophic cancellation could occur in a naive implementation. Not because I "got the answer wrong" per se, but because a computer has limits (in this case: precision), and there's no way (in my mode of learning) for that kind of information to stick unless I have my hands dirty in the code.
To go back to the languages though, I stuck to major ones and played with Python, C/C++, and Fortran. Python and Fortran I used online references to play with and learn, while with C++ I bit the bullet and read C++ Primer which is really hefty but I found to be very thorough (and a great reference).
There's lots you can learn on your own. Just do some web searches. Pick a language, and start learning. Python is great for a beginners. (I like Haskell, but I'm weird.)
There are a bunch of auxiliary skills that help. Learn how to use irc (freenode is great), get familiar with github.
Drop me a line, if you need more help. My email address is in my profile.
At most companies the coding required is easy and doesn't require much thought, low-skill = low-pay. The job of allocating capital and people to the highest ROI areas is much more significant to most companies' success than having the best programmers.
Personally I would have said a big part of it is that they control payroll.
Think steven jobs - he is credited with apple's success. May be that's true - he could have ruthless quality requirements. But it couldn't have happened without the engineers that _actually_ created the product. Why is it that the CEO gets exponentially more returns than the soldiers that fight in the trenches, doing the _actual_ work?
I look at it this way. I've been programming for 10 years and, in a typical "do what I'm told" job, I'm not going to learn anything new. Sure, managers only get 10-15 hours of coding time, but that's more than you'll get in useful coding time as a managed employee anyway.
As a manager, you can have your underlings explore new technologies and report back, keeping you current on the field, and while you'll only get 10-15 hours of coding time (unless you work 40+) you have a lot more freedom in deciding what you code, and power to get your work noticed. I'd rather have 10 hours per week of quality coding experience than 40 hours in the Java mines maintaining someone's VibratorFactoryVisitorSingleton.
Managers are good at complain-bragging and making their track sound more painful than it actually is. The fact is that a manager who keeps his coding skill current is highly valued. Being a manager means you have organizational credibility, and if you want to use that credibility to code because you think it's the right thing for you, then you can.
If I were to take a cynical view of dual-track organizations, I'd say that the real purpose is to convince the programmers that the management-ladder people are better than they actually are. A Director-equivalent programmer at Google (Principal Engineer) is an objectively strong engineer, and it's competitive as hell to get to that rank. The Director-level managers at Google aren't any better than middle-management at other companies.
I would be quite surprised if the real product direction power wasn't held by the principal engineers at Google. I mean, ya, the managers get to manage, and they provide some leadership, but they have those pesky management tasks and politics (all necessary) getting in the way of that. In that situation, there are also probably plenty of managers who have to manage peers (i.e. people who have equal or even more influence in the company), and the concept of "underling who reports back" is a bit of a stretch!
The individual contributor path is exponentially more difficult to climb. I argue that you both have to win the lottery with the right projects and get in early at a company, and have all of the necessary skills.
I believe it is a story that is told to individual contributors by people with real power to keep them motivated.
The only theory that I've heard of where a flat org could be actually beneficial to individual contributors is the parents theory on open allocation. Otherwise it's just management kicking out the ladder once they've climbed it.