Ask HN: Asking About Career Path
3 comments
If you want more money, get closer to the money.
In most financial firms, software development staff is a cost center, even if the projects themselves are viewed as investments. So make sure you're not simply someone who does a very good job at executing project plans from other people.
Positions that are closer to the money in enterprise firms than "very good Java software developer" include:
* Architects who decide how very good developers should be writing code
* Product leads/managers who decide what very good developers should be writing in the first place
* Anybody involved in the software development process that has mastered the problem domain itself; so, for instance, if you're working on clearing software, you should be a world expert in clearing.
* People who come up with very good ideas for software projects that save or make money for the firm.
Things you can do to execute this:
* Try to move into an architecture role (be warned: this is what most devs try to do, so the law of supply and demand limits the upside here)
* Talk to your manager about what the next 3 steps are on the career path that ends with you managing a team, and then spend another 10 minutes talking about how to execute step 1 and have it recognized.
* Change groups you work on (say, from clearing to order management) and coincident to that move invest a month of diligent nighttime reading to become an expert in the problem domain of the new group, which gives you business value.
* Survey every project you've worked on so far for the company, make a list of 5 problems those projects had that cost the company money, come up with a solution to one of those problems that you can implement on your own (for instance, refactoring classes, or factoring out thorny configuration logic into Scala, or &c &c &c), and then talk to your manager about how you can demo that idea to the group.
The goal at the end of the day is to be in a position where, when you have the performance review, you can confidently put on the table a bunch of things you've done for the business. You'll know it when you've got the upper hand in negotiation; the company won't be able to afford losing you.
As much as "become an architect!" is a trap for enterprise devs, be aware that if money is your objective, "go move to a software company!" is an even bigger trap. You will make more money over your career by carefully planning and executing a strategy to increase your value to an enterprise than you will at startups.
(NB: I'm not an enterprise dev, but I work closely with a lot of enterprise devs, have successful enterprise dev friends, and have started companies with people that have later gone on to de-pants my projected lifetime earnings at enterprises).
In most financial firms, software development staff is a cost center, even if the projects themselves are viewed as investments. So make sure you're not simply someone who does a very good job at executing project plans from other people.
Positions that are closer to the money in enterprise firms than "very good Java software developer" include:
* Architects who decide how very good developers should be writing code
* Product leads/managers who decide what very good developers should be writing in the first place
* Anybody involved in the software development process that has mastered the problem domain itself; so, for instance, if you're working on clearing software, you should be a world expert in clearing.
* People who come up with very good ideas for software projects that save or make money for the firm.
Things you can do to execute this:
* Try to move into an architecture role (be warned: this is what most devs try to do, so the law of supply and demand limits the upside here)
* Talk to your manager about what the next 3 steps are on the career path that ends with you managing a team, and then spend another 10 minutes talking about how to execute step 1 and have it recognized.
* Change groups you work on (say, from clearing to order management) and coincident to that move invest a month of diligent nighttime reading to become an expert in the problem domain of the new group, which gives you business value.
* Survey every project you've worked on so far for the company, make a list of 5 problems those projects had that cost the company money, come up with a solution to one of those problems that you can implement on your own (for instance, refactoring classes, or factoring out thorny configuration logic into Scala, or &c &c &c), and then talk to your manager about how you can demo that idea to the group.
The goal at the end of the day is to be in a position where, when you have the performance review, you can confidently put on the table a bunch of things you've done for the business. You'll know it when you've got the upper hand in negotiation; the company won't be able to afford losing you.
As much as "become an architect!" is a trap for enterprise devs, be aware that if money is your objective, "go move to a software company!" is an even bigger trap. You will make more money over your career by carefully planning and executing a strategy to increase your value to an enterprise than you will at startups.
(NB: I'm not an enterprise dev, but I work closely with a lot of enterprise devs, have successful enterprise dev friends, and have started companies with people that have later gone on to de-pants my projected lifetime earnings at enterprises).
I really question what you think "senior" means. A career for most people can be 40 years, and you're calling yourself "senior" after 5? What do you think guys with 20 years experience - who've led teams, managed budgets, seen the full SDLC, seen the same fads cycle every decade with different buzzwords, worked in multiple industries, multiple languages, multiple countries, been QA, developers, architects, project managers, business analysts at different points in their careers - see and hear when some kid (no offense) calls himself "senior"?
A revenue generating programmer in an investment bank is called a "quant". Maybe you could give that a whirl.
A revenue generating programmer in an investment bank is called a "quant". Maybe you could give that a whirl.
The last time I checked 5 years of experience is enough to label someone as "senior" in software development.
I'm not saying that's not crazy, or disagreeing with your general point, but as the term is used in the field he's not out of line.
I'm not saying that's not crazy, or disagreeing with your general point, but as the term is used in the field he's not out of line.
I think I'm getting to be a cranky old developer like you (I'm just shy of 20 years of professional programming). I thought the same when I saw five years = senior.
On the other hand, 6 years into my career I was promoted to Principal Engineer, over guys with 3 times my experience. Go figure.
On the other hand, 6 years into my career I was promoted to Principal Engineer, over guys with 3 times my experience. Go figure.
Yeah, it's like kids who show up to their first interview and say "I have 15 years experience", meaning they have been playing with computers since they were little. Ermm, no, work you didn't get paid for doesn't count. You aren't being paid to program. You're being paid to solve business problems with code. Even for hardcore geeks this is true, the problem a compiler writer is working on is actually the problem of the CFD guys who want to optimize their simulations, and their problem is actually the problem of the auto guys who want to build better cars. Or if you're working on a filesystem your problem is actually the problem of the database guys who want to process transactions faster, and their problem is really the problem of traders. Experience of that is what matters.
What do you think guys with 20 years experience blah blah blah blah blah...
That would be the "staff" engineers. I myself is a "senior" design engineer with 4 years of experience. You seem unfamiliar with the industry lingo.
That would be the "staff" engineers. I myself is a "senior" design engineer with 4 years of experience. You seem unfamiliar with the industry lingo.
I would say you should look for companies where the software is the product and start applying there. When you are a support role in a company in which the product is something else you will always be an expense by definition. You can either jump ship or document precisely how you are making the company money. When it comes time for review give the reasons that you are worth $x more a year and back it up with actual numbers. For example, I had x idea that I implemented and by the metrics I put into the software I was able to measure a y decrease in time spent accomplishing task w. This led to a increase of profitability of $z and n hours saved overall.
I would say that jumping ship to a company whose focus is software would be more fun and bring a larger monetary increase. The economics of today is that you really can negotiate a larger salary by moving to another company than just getting marginal cost of living increase raises.
I would say that jumping ship to a company whose focus is software would be more fun and bring a larger monetary increase. The economics of today is that you really can negotiate a larger salary by moving to another company than just getting marginal cost of living increase raises.
So I am thinking about what to do if I want to get a big salary jump. I can ask for a big raise (been here 5 years but the annual raise not that big) but I doubt it could help. Or I can just start over again in a new firm. I just need to make sure whatever firm I chose to work for, I want to be a source of revenue generating, not just an IT "expense". In my opinion, software companies like MS, google , Oracle always treasures their engineering staff better than the business staff. Or I can consider working for a consultant firm since I bring home the money for them as well.
I'd like to hear your opinions. Thank you