I just turned 36, and I am in a contemplative self battle with this very question for my own career. As far as internal career development goes for my current employment, I have "succeeded". I have had a slew of successful projects and have been slowly but surely moving up the chain. It's difficult because in a large firm (20k global employees), moving up means coding less and attending more meetings. This is starting to drive me mad. I know that I can only go so far as an engineer in a large firm, but I don't want to just coalesce into the larger bloat that churns out hours and hours of meetings and powerpoint. On this path, in 5 years, I will be a director of some department and my distance from the code will be far. One way I am coping is by continuing this management ascension and writing code on the side - but when I have kids in the next couple years I probably wont have much time for that. It is a difficult decision to be sure.
I'm not sure that's a totally valid sentiment. For starters, top-notch developers in the US earn salaries that approach CEO-level pay (ok, maybe not quite, but certainly top-5% salaries nationally).
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).
Come on.. Maybe you've seen developers at Google or somewhere like that make LameFailingCompanyCEO-level pay, but I highly doubt that "top-notch" developers anywhere earn salaries that approach CEO-level pay IN THE SAME COMPANY. Everywhere I've worked there has been a huge compensation cliff between the senior managers (anyone with the C?O title or their direct reports) and the rest of the peasants. I'm talking orders of magnitude difference. Sure, there are outliers, but I'd guess the typical tech workplace (lets say Bay Area cost of living) is structured, on average:
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.
Salary seems on the money, but equity is not - at least for a senior engineer, I have been offered around $60k * 4 (standard 4 year vesting - value at offer) typically in my short time around.
You're being a little vague. 5% is which markets? A programmer in SF might earn as much as a CXX from North Dakota but the CXX in his market is making a lot more than him. Still, I think at the CXX level the total compensation is a lot more. >$300k? $500k?
I did my mechanical engineering and having a pain in finding a job. I'm planning to get into programming. What do I need to do to become a decent developer who is in demand and can earn decent money?
I graduated with a BS in nuclear engineering (which at NCSU is very close to a mechanical engineering degree). I now work the computational engineering angle, working both the CS and engineering model side of things. I can show what I did, but I don't have a singular piece of advice that can act as a silver bullet.
- 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.
They definitely required programming, but were understanding of any spin-up time it took to get on board. I did wind up spending large amounts of time outside reading and tinkering along with blog posts, wikipedia, and even good old-fashioned books.
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).
It's easiest if you start hanging out with people who can program (and best of all, earn good money programming).
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.
CEO's and managers get a lot of shit on HN, but there is a reason they make more money (in general, obviously there are exceptions, especially at tech companies). The main reason is that what they do is more valuable.
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.
Yeah, I probably should't have said more valuable. It's more accurate to say that there a lots of people who can program poorly and for most jobs that's all that's needed. Far fewer people can manage others well or effectively allocate resources.
but that's not the whole story - a CEO is highly paid, but that's more likely that they've "proven" track-record of doing well in another company, and in order to poach them, a high salary is needed. But, _is_ the CEO responsible for their so-called record? or do they just have really talented employees and the credit for doing well is being rubbed off into the CEO?
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?
You should work for a tech company (i.e. those companies that solely focus on tech). Most usually have clear career paths for those who want to become senior individual contributors vs. managers, because that is actually very useful.
I'm skeptical about dual-track organizations (read my other post in this thread, here: https://news.ycombinator.com/item?id=8481680 ). I agree that it's a good idea, but they tend to make it astronomically harder to be a Director-equivalent engineer than a Director. Ultimately, the management ladder is easier to scale and therefore "better", insofar as you can be a Director and still code (if you want).
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.
The tech world is going flat, which has a lot to do with the experiences of your former employer. In this new (but not really that new) model, the hierarchy is flatter, people managers are fewer and have lots of reports, while experienced/skilled individual contributors (ICs) are expected to provide more of the leadership missing from the fewer managers (who are better at providing that anyways). When each manager has 20 reports, you don't need many of them. Even Microsoft is moving this way, and has always focused on a lot of strong ICs; distinguished engineer is a partner level position (I think).
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!
Look at how many distinguished engineers, or other very high level individual contributors who have actual real power there are compared to Directors and VP's who manage large groups of people.
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.
