Should Younger Developers be Paid More?(itmanagement.earthweb.com)
itmanagement.earthweb.com
Should Younger Developers be Paid More?
http://itmanagement.earthweb.com/entdev/article.php/3921006/Should-Younger-Developers-be-Paid-More.htm
45 comments
There was an excellent comment on a previous article that I can't find now, someone said, when you join a company, it's because you meet their minimum requirement. You work hard and in a few years, you're a badass at what you do - but because the change was gradual, no-one really notices it. The only way to monetize your new level of skill is to jump ship and join another company as "the guru".
Was this the comment?
http://news.ycombinator.com/item?id=2095406
http://news.ycombinator.com/item?id=2095406
Yes! Well found :-)
Meh. The whole thing is based on an anecdote which may or may not even be true.
Anybody who pays a premium for new college grads is an idiot. Comp Sci programs don't teach you what you need to know to produce production code. It takes a good three or four years of professional experience for people to pick that up. Some never do.
There's a reason new grads are having a hard time getting hired in this crappy economy. It's not because employers don't know better - it's because employers do know better. Yeah, it sucks to be in that chicken-and-egg position, but everybody was there in the beginning.
Anybody who pays a premium for new college grads is an idiot. Comp Sci programs don't teach you what you need to know to produce production code. It takes a good three or four years of professional experience for people to pick that up. Some never do.
There's a reason new grads are having a hard time getting hired in this crappy economy. It's not because employers don't know better - it's because employers do know better. Yeah, it sucks to be in that chicken-and-egg position, but everybody was there in the beginning.
I guess if the Facebook thing is true, it means that they find the market for really talented engineers very tight right now so instead or making bets on the best comsci talent in the hope that they can quickly get them up to speed on writing good production code.
Right now the market just isn't that tight, so even assuming that would ever be a good strategy it certainly isn't one now.
More likely it's a rumor that grows with the telling.
More likely it's a rumor that grows with the telling.
Comp sci programs indeed don't teach that, that's right. On the other hand, a lot of college grads have taught themselves to code effectively in their own time, either in open source or by selling their own apps. These are generally bright amd well-motivated, and have experience in diverse areas of programming. It's a matter of picking the right people.
While I an appreciate that person's position of getting to market quickly, but I find it hard to believe that you couldn't competently train shart engineers in a week or two on mobile app technology.
I recall at one of my companies we had some incredibly strong devs, but all with Unix backgrounds. We needed them up to speed on Windows and COM. We did two courses for them -- probably WinTellect or something (one Windows, the other COM). In less than a month we had a small team of Windows devs that were as strong as any I'd seen.
We hired for really bright people first. Moving them to the technology was pretty easy. And if one month is the difference between making and breaking a market, you may want to reassess the market.
I recall at one of my companies we had some incredibly strong devs, but all with Unix backgrounds. We needed them up to speed on Windows and COM. We did two courses for them -- probably WinTellect or something (one Windows, the other COM). In less than a month we had a small team of Windows devs that were as strong as any I'd seen.
We hired for really bright people first. Moving them to the technology was pretty easy. And if one month is the difference between making and breaking a market, you may want to reassess the market.
Agreed. Good developers are good developers. The same traits that make someone successful on one platform are identical to what will make them successful on another.
If you pay more for certain training backgrounds, you're paying only for the few weeks/months required for a good dev to come up to speed on the new technology. The company in the article probably spent tens or hundreds of thousands of dollars more than they needed to for virtually no gain, unless those few weeks/months made a critical time-to-market difference.
If you pay more for certain training backgrounds, you're paying only for the few weeks/months required for a good dev to come up to speed on the new technology. The company in the article probably spent tens or hundreds of thousands of dollars more than they needed to for virtually no gain, unless those few weeks/months made a critical time-to-market difference.
Technology is a brutal industry for those that fall off the leading edge. Anyone who's considering going into it should know that.
It's often worth it to have periodic career breaks simply to refresh your skillset. Found a startup in whatever the hottest area is. Take on a side project to teach yourself something knew. Switch to a new job working on hipper technologies.
But if you're expecting to gradually keep your head down and put in your 40 hours a week at the same employer for the next ten years, you're going to be disappointed. Basically everything you started out knowing will be obsolete by then.
It's often worth it to have periodic career breaks simply to refresh your skillset. Found a startup in whatever the hottest area is. Take on a side project to teach yourself something knew. Switch to a new job working on hipper technologies.
But if you're expecting to gradually keep your head down and put in your 40 hours a week at the same employer for the next ten years, you're going to be disappointed. Basically everything you started out knowing will be obsolete by then.
Exactly. Really the article is about paying more for more skilled developers (or at least, ones with skills that you need) rather than just senior vs. junior.
IMO, both the employer and developer are to blame in the scenario given. The developer hasn't kept his skills current, sure, but also the employer/customer requires the new hotness by next week and nobody has thought to train any of their existing developers in it (and end up paying a 130% premium).
IMO, both the employer and developer are to blame in the scenario given. The developer hasn't kept his skills current, sure, but also the employer/customer requires the new hotness by next week and nobody has thought to train any of their existing developers in it (and end up paying a 130% premium).
The developer hasn't kept his skills current
This comment and similar comments I've seen on this post seem to be implying that every developer needs to continuously be learning the latest technology/platform -- in this case mobile.
I really don't think that makes sense. Technology is way too diverse to expect everyone to know everything. Do you think every web developer needs to be able to develop iPhone apps (and vice versa) ?
It seems to me that the post has more to do with the employer discovering an inconsistency in the way they were evaluating the value of their employees. Is the mobile developer really generating more value for the company than the backend/customer logic guy with 10 years experience. I doubt it, and judging by the outcome the manager seems to agree.
This comment and similar comments I've seen on this post seem to be implying that every developer needs to continuously be learning the latest technology/platform -- in this case mobile.
I really don't think that makes sense. Technology is way too diverse to expect everyone to know everything. Do you think every web developer needs to be able to develop iPhone apps (and vice versa) ?
It seems to me that the post has more to do with the employer discovering an inconsistency in the way they were evaluating the value of their employees. Is the mobile developer really generating more value for the company than the backend/customer logic guy with 10 years experience. I doubt it, and judging by the outcome the manager seems to agree.
implying that every developer needs to continuously be learning the latest technology/platform
Generally speaking the idea behind that sentiment is that a ASP.NET MVC dev should keep up with MVC3 and Razor. That Rails devs should keep up with Rails 3. That Javascript devs should keep up with Node.js and the plethora or new libraries/frameworks coming out. Sure you might know a gazillion languages, but the only real requirement is to keep up with the developments of the technologies you need NOW.
I agree that no developer should be expected to know everything, nevertheless he/she should be able to pick up anything fast and easy. It is my firm belief that people should be paid by the value they provide, instead of the technologies they're well versed in.
On another note, I'm by no means a genius rocket scientist turned developer, but in the last 6 years I went from implementing complex E-Commerce Java backends, to front end development and design, to Php app dev, back to Java, to Rails webapps, to system administration and some Python dev, to (right now) Asp MVC and C# dev. I've been using Visual Studio (which I had never used) in a virtual machine running Windows (which I last used when XP came out circa late 2001), and I was productive within the first 2 or 3 days from when I started. Sure I'm a lot better now - 2 weeks into the job, but any developer worth his salt could have tackled the "mobile dev" stuff that the author of the main article was referring to in two or three weeks of training/tinkering. The problem these days are the business types hiring people because they've used some cool new tech, instead of hiring based on trajectory, experience, and perceived value.
Generally speaking the idea behind that sentiment is that a ASP.NET MVC dev should keep up with MVC3 and Razor. That Rails devs should keep up with Rails 3. That Javascript devs should keep up with Node.js and the plethora or new libraries/frameworks coming out. Sure you might know a gazillion languages, but the only real requirement is to keep up with the developments of the technologies you need NOW.
I agree that no developer should be expected to know everything, nevertheless he/she should be able to pick up anything fast and easy. It is my firm belief that people should be paid by the value they provide, instead of the technologies they're well versed in.
On another note, I'm by no means a genius rocket scientist turned developer, but in the last 6 years I went from implementing complex E-Commerce Java backends, to front end development and design, to Php app dev, back to Java, to Rails webapps, to system administration and some Python dev, to (right now) Asp MVC and C# dev. I've been using Visual Studio (which I had never used) in a virtual machine running Windows (which I last used when XP came out circa late 2001), and I was productive within the first 2 or 3 days from when I started. Sure I'm a lot better now - 2 weeks into the job, but any developer worth his salt could have tackled the "mobile dev" stuff that the author of the main article was referring to in two or three weeks of training/tinkering. The problem these days are the business types hiring people because they've used some cool new tech, instead of hiring based on trajectory, experience, and perceived value.
I completely agree with you, I've always been much of a generalist myself and after a while you realize that the fundamental patterns of technology remain fairly constant, only the details change.
It's just that there's a difference between being able to learn new technologies and feeling like you have to. Good developers certainly have high learning capacity but none of us has infinite learning capacity. My concern is that given the pace of technological change we create (or are forced to create) unrealistic expectations of ourselves. If the lead developer on an ongoing successful product is made to feel that he needs to learn mobile development, I think that maybe crossing a line (of course everything depends on the exact circumstances, if the product were stable and the mobile interface was all that remained to be done it might be a different story).
It's just that there's a difference between being able to learn new technologies and feeling like you have to. Good developers certainly have high learning capacity but none of us has infinite learning capacity. My concern is that given the pace of technological change we create (or are forced to create) unrealistic expectations of ourselves. If the lead developer on an ongoing successful product is made to feel that he needs to learn mobile development, I think that maybe crossing a line (of course everything depends on the exact circumstances, if the product were stable and the mobile interface was all that remained to be done it might be a different story).
Well the thing is... a company needs to have employees that create value for itself.
I was once in the position of telling an employer that he was wrong to want to hire an extra Rails dev when we had a front end guy that had little work at the time and had the drive and fast learning capability to learn it in a week or two, at least to decent productive standards. The new hire was a disaster, and three months later was replaced by the guy that I said we could train. For more money than the new hire.
A lead developer should not be expected to know everything, but he needs to know how to solve problems, regardless of the medium, and regardless of the programming language. A lead developer should not only be expected to get into mobile development when required, but he should also be involved in the effort to pursue said mobile solution.
I was once in the position of telling an employer that he was wrong to want to hire an extra Rails dev when we had a front end guy that had little work at the time and had the drive and fast learning capability to learn it in a week or two, at least to decent productive standards. The new hire was a disaster, and three months later was replaced by the guy that I said we could train. For more money than the new hire.
A lead developer should not be expected to know everything, but he needs to know how to solve problems, regardless of the medium, and regardless of the programming language. A lead developer should not only be expected to get into mobile development when required, but he should also be involved in the effort to pursue said mobile solution.
No developer can be across everything, but you do need to be learning a latest technology though, if only so that you can get a decent raise by either inflating your market rate, or by jumping ship when the pay difference gets too great.
The other option is to get a greater depth in one of your current skills so that you can be a 'guru of X', but you'll probably still want to have broad knowledge in related areas (eg. a guru web dev will need HTML, CSS, databases, Analytics, AJAX, etc.)
The other option is to get a greater depth in one of your current skills so that you can be a 'guru of X', but you'll probably still want to have broad knowledge in related areas (eg. a guru web dev will need HTML, CSS, databases, Analytics, AJAX, etc.)
From what I can tell after the little iPhone boomlet subsided there's not a whole lot of money in mobile apps. How many minecrafts are there, really, out there?
There is a market in developing mobile software as part of a general mobile platform. Making the mobile app for salesforce.com and what not. Also a good majority of smartphone users don't really pick up on the apps and are starting to get more into customizing their cellphone and what not, there is a wave on the horizon of smart phone users using their phones more and getting apps and what not.
The money in mobile apps sold through the app store to the general public, might be subsiding. But I believe the money in industry specific, in house apps designed to run on tablet like devices of various sizes is just starting to pick up.
Mobile is no longer a gold rush where you can get money for putting out any random crap, but, there is still plenty of money to be made.
Well actually it was much worse then that, the most jr member of the team was making 30% more then the lead as a FTE. When that comes to light it is a big problem, its the kind of thing that makes the team quit if it goes bad. As was said elsewhere contractor makes sense here, the skill will not be scarce in 6 months so buy it for 6 months at a premium.
True, and technology is far from the worst field in that respect. Professional sports or modeling are two professions in which you will lose your value no matter what you do. You have a limited shelf life and you have to make the best out of the years you have.
As a developer you at least have a choice. It's possible to earn a living as a software developer in your 50s or 60s, I've met a few.
As a developer you at least have a choice. It's possible to earn a living as a software developer in your 50s or 60s, I've met a few.
There is a market inefficiency in that wages are dominated not by one's value to the company today but by one's value to the company the last time one engaged in free negotiations for wages. This inefficiency is persistent and exploitable. If you're being underpaid, changing jobs is the simplest, most reliable way to fix that.
"Ooh but then you're disloyal and a job hopper!" - Calacanis et al.
As I stated last time, only businessmen and finance grads are allowed to exercise self-interest. When labor starts responding to the market they get really mad.
As I stated last time, only businessmen and finance grads are allowed to exercise self-interest. When labor starts responding to the market they get really mad.
I've realized another problem with the situation described in the article. Let's say I work at a company, and I have skills U, V, W, and X, and I know the company's systems in and out. I've been there for 10 years and am an excellent employee.
The company needs someone with skills Y and Z, for some new project. They hire some kid, and pay him 30 or 40% more than they are paying me. They tell me they have to pay that, because there is a lot of competition for people with Y and Z. OK, fine--although if management had done their job and figured out we would need Y and Z ahead of time, I would have been happy to learn Y and Z.
So what happens a year down the road, when that new project is done, and we no longer need Y and Z, and that kid is now doing the same work I do--but with a lot less knowledge of the company systems, a lot less experience in U, V, W, and X, and is still making 30% more than me?
Is the company going to cut his pay to match mine? That won't work--the kid will quit. Are they going to raise my pay (and everyone else in a similar situation) to match the kid's? Probably not financially viable.
They are going to have to find something to do for the prior workers at this point, or moral is going to be low, and they will probably have a lot of people leaving.
Alternatively, if Y and Z turn out to be something the company still needs a year after hiring the kid, then by that time the rest of us will probably have learned them, too, after seeing how lucrative such skills are. Do we all get raises up to the kid's level? If we are actually now doing Y and Z we'd certainly expect at least equal pay. If we aren't doing Y and Z, then we should be going to other companies that need Y and Z, and getting the big bucks.
The company needs someone with skills Y and Z, for some new project. They hire some kid, and pay him 30 or 40% more than they are paying me. They tell me they have to pay that, because there is a lot of competition for people with Y and Z. OK, fine--although if management had done their job and figured out we would need Y and Z ahead of time, I would have been happy to learn Y and Z.
So what happens a year down the road, when that new project is done, and we no longer need Y and Z, and that kid is now doing the same work I do--but with a lot less knowledge of the company systems, a lot less experience in U, V, W, and X, and is still making 30% more than me?
Is the company going to cut his pay to match mine? That won't work--the kid will quit. Are they going to raise my pay (and everyone else in a similar situation) to match the kid's? Probably not financially viable.
They are going to have to find something to do for the prior workers at this point, or moral is going to be low, and they will probably have a lot of people leaving.
Alternatively, if Y and Z turn out to be something the company still needs a year after hiring the kid, then by that time the rest of us will probably have learned them, too, after seeing how lucrative such skills are. Do we all get raises up to the kid's level? If we are actually now doing Y and Z we'd certainly expect at least equal pay. If we aren't doing Y and Z, then we should be going to other companies that need Y and Z, and getting the big bucks.
It's a bit unpleasant if you're on the wrong side of the equation but it's just market forces. Mobile application developers were scarce while normal developers were plentiful.
The big lesson is that you should continually refresh your skills and develop new things on your own time.
The big lesson is that you should continually refresh your skills and develop new things on your own time.
I feel hourly rates for consulting could be driven by "hot" skills, but not employee rates. Any manager who pays new employees less than old ones is asking for trouble like this. HR departments should also prevent this, if they have their act together.
That being said, nobody should get too bent out of shape if someone else makes more than them. If you agree to work for a salary, then live with that decision... don't come crying to management because someone else bargained better.
That being said, nobody should get too bent out of shape if someone else makes more than them. If you agree to work for a salary, then live with that decision... don't come crying to management because someone else bargained better.
That being said, nobody should get too bent out of shape if someone else makes more than them. If you agree to work for a salary, then live with that decision... don't come crying to management because someone else bargained better.
Bullshit. If someone with practically the exact same skillset as you is being paid significantly more than you're being underpaid for the company's own evaluation of your skillset. What you should do is say: my skills are worth x and y is getting paid that; if you don't increase my salary proportionately that I will go work for someone else at market rates.
Of course, if the issue is just that your coworker is for some reason getting paid far over his skill set or market rates then they just got lucky.
Bullshit. If someone with practically the exact same skillset as you is being paid significantly more than you're being underpaid for the company's own evaluation of your skillset. What you should do is say: my skills are worth x and y is getting paid that; if you don't increase my salary proportionately that I will go work for someone else at market rates.
Of course, if the issue is just that your coworker is for some reason getting paid far over his skill set or market rates then they just got lucky.
Lost in all of this are the dedicated engineers who have put blood, sweat and tears into an organization, only to be left behind when technology changes. But is it their own fault? The company’s fault? Or just a natural cycle?
Let's say you join a company as, I dunno, a Unix sysadmin. When you go in, it's because they hired you for your Unix skills. But after 5 years, your value to the company isn't just those skills anymore, it's that you know the company's systems, its business, the particular way "we do things here", you have a network of people within the organization and can "get stuff done" and so on. And probably, by now, your Unix skills are falling a bit behind, because the company is not about the bleeding edge, they say if it ain't broke don't fix it (many large organizations only upgrade when the vendor desupports something) and besides, your time is spent in meetings now.
So people can fall into a trap - they're doing very well in the company - and don't even notice they're falling behind until it's too late...
Let's say you join a company as, I dunno, a Unix sysadmin. When you go in, it's because they hired you for your Unix skills. But after 5 years, your value to the company isn't just those skills anymore, it's that you know the company's systems, its business, the particular way "we do things here", you have a network of people within the organization and can "get stuff done" and so on. And probably, by now, your Unix skills are falling a bit behind, because the company is not about the bleeding edge, they say if it ain't broke don't fix it (many large organizations only upgrade when the vendor desupports something) and besides, your time is spent in meetings now.
So people can fall into a trap - they're doing very well in the company - and don't even notice they're falling behind until it's too late...
I've noticed (in several years as an intern software engineer) that it's responsibility and foresight that separate junior and senior level developers, technical skill less so.
Having in depth skill with a new technology is certainly a desirable attribute but I'd rather have the reliability of a n experienced developer (especially since they should be able to pick up something new).
Having in depth skill with a new technology is certainly a desirable attribute but I'd rather have the reliability of a n experienced developer (especially since they should be able to pick up something new).
I don't want to rag on this article but heck if I can figure out what the point is.
This is very easy. If you know stuff that few other people know, you can make more money. Once everybody figures out that's where the money is, the money isn't there any more.
Companies will only pay to train you after they have figured out they need something -- and with most companies this is about six months or more after they actually needed it. So they are in a bind and have to hire talent immediately. Folks who come in knowing what the company wants pick up the extra bucks.
The trick here is that you cannot rely on your company to train you. You have to figure out where the market is going, all on your little lonesome, and then do whatever you can to master the tech -- including writing programs for local charities if that's what it takes to get real-world experience -- before the market gets there. This is called investing in your future. It's the tech equivalent of going to night school.
I've been playing this game for a long time, and I've been the young buck making the big bucks (although I've never been the older complainer guy). After I worked my way through code monkey, architect, lead, and pm roles, I ended up training and watching software teams. So I've literally either participated in or worked with folks helping and evaluating hundreds of teams.
Best teams? If I had to generalize, I'd pick the old guys who keep picking up new tech. They know the business, they've been around long enough to play nice with others, and -- if they've stayed current this long -- genuinely are having a fun time with what they do. Plus they tend not to get stressed out by too much. Second best? A mixed team with mostly young guys with lots of current tech and a couple older guys to provide that gray-beard kind of balance.
But that's just a generalization, and like all generalizations it's very limited in its application. Each team is completely different. That's what makes this biz so much fun. Just like my generalizing, I think companies get too caught up in buzzwords. Smart guys with good attitudes can do a lot. I wouldn't go ape-shit with concern simply because buzz word X wasn't in somebody's job experience (or vice-versa) If you know you have to learn X for this next project and you're sitting around waiting on somebody else to come and teach it to you? That's just a little bit too passive for my tastes.
I hate to sound like such a hard-ass (well maybe not really) but this is a very simple business that hasn't changed much in several decades. The pace might have changed, sure, and the tech is all new, but the mechanics of being a good project member, what makes a good project, and how people get paid and such are all the same as they were in 1980 or something. Not much mystery to kick around here in this narrow area of "why Joe makes 30% more than Fred"
This is very easy. If you know stuff that few other people know, you can make more money. Once everybody figures out that's where the money is, the money isn't there any more.
Companies will only pay to train you after they have figured out they need something -- and with most companies this is about six months or more after they actually needed it. So they are in a bind and have to hire talent immediately. Folks who come in knowing what the company wants pick up the extra bucks.
The trick here is that you cannot rely on your company to train you. You have to figure out where the market is going, all on your little lonesome, and then do whatever you can to master the tech -- including writing programs for local charities if that's what it takes to get real-world experience -- before the market gets there. This is called investing in your future. It's the tech equivalent of going to night school.
I've been playing this game for a long time, and I've been the young buck making the big bucks (although I've never been the older complainer guy). After I worked my way through code monkey, architect, lead, and pm roles, I ended up training and watching software teams. So I've literally either participated in or worked with folks helping and evaluating hundreds of teams.
Best teams? If I had to generalize, I'd pick the old guys who keep picking up new tech. They know the business, they've been around long enough to play nice with others, and -- if they've stayed current this long -- genuinely are having a fun time with what they do. Plus they tend not to get stressed out by too much. Second best? A mixed team with mostly young guys with lots of current tech and a couple older guys to provide that gray-beard kind of balance.
But that's just a generalization, and like all generalizations it's very limited in its application. Each team is completely different. That's what makes this biz so much fun. Just like my generalizing, I think companies get too caught up in buzzwords. Smart guys with good attitudes can do a lot. I wouldn't go ape-shit with concern simply because buzz word X wasn't in somebody's job experience (or vice-versa) If you know you have to learn X for this next project and you're sitting around waiting on somebody else to come and teach it to you? That's just a little bit too passive for my tastes.
I hate to sound like such a hard-ass (well maybe not really) but this is a very simple business that hasn't changed much in several decades. The pace might have changed, sure, and the tech is all new, but the mechanics of being a good project member, what makes a good project, and how people get paid and such are all the same as they were in 1980 or something. Not much mystery to kick around here in this narrow area of "why Joe makes 30% more than Fred"
The biggest thing that jumped out at me was his response, when confronted by his team lead. This manager totally waffled on the issue, than continued to waffle, using language that just screams (to me) "you're getting screwed and I don't have the balls to be honest with you about what's going on." Managers like that, I have a really hard time trusting.
I think the title is a little misleading ... but I understand that "Should Younger Developers with a hot and in demand skillset be paid more" is too long and not as interesting.
That being said, I don't really understand what the dev was upset about ... Its just good ol' supply and demand.
Being skilled at new hot technology is always a good thing. In my short time as a dev, I've seen the crazy salaries for WPF (.NET), Rails, facebook (if that counts) and now iphone/android developers and I'm sure this won't be the last time either.
Want to make $200k+? Pick up the skills that are attracting that kind of coin. Simple.
That being said, I don't really understand what the dev was upset about ... Its just good ol' supply and demand.
Being skilled at new hot technology is always a good thing. In my short time as a dev, I've seen the crazy salaries for WPF (.NET), Rails, facebook (if that counts) and now iphone/android developers and I'm sure this won't be the last time either.
Want to make $200k+? Pick up the skills that are attracting that kind of coin. Simple.
Possible solution: hire them as contractors. People expect contractors to get paid more, so your current employees will stay reasonabye gruntled.
You also aren't stuck with overpaid employees once everyone lese is up to speed.
That actually might be a downside for the highly paid youngsters. Once everyone else has caught up with them, why keep them for such a high price?
Should managers think they are going to sneakily hire new, inexperienced people for high salaries and not catch flak from long time employees?
More appropriate questions include: Should I pay more for ability to learn? Should I pay more for already knowing how to do what I need done?
Some people start out eager to learn, but lose it. And others become learning machines. Pay more for the latter, regardless of their age.
Some people start out eager to learn, but lose it. And others become learning machines. Pay more for the latter, regardless of their age.
I'm curious, what is the career path and salary looking like for people in these situations as time progresses? For example, someone at Facebook who might be paid $120k, how much higher is their salary going to get as they get older and more experienced?
Typically bonuses and stock grants will become the major part of ones total compensation. Base salary will grow but probably not by that much.
So today I learned two things from the front page on Hacker News:
1) College students aren't really learning anything in college.
2) Fresh, young college grads should be paid more.
Makes sense.
Makes sense.
George looked down and sighed. “So you are telling me
there are no guarantees, and oh by the way, you want me
to mentor these new guys on the business requirements?”
“Yep, that sums it up,” I responded, not half as
convinced as I sounded.
“Well, that sucks.”
Senior engineers usually have a mortgage and kids.
Two of the most productive, and accurate, and quick -- while accurate -- fellows I worked with were getting into their 40's. Our boss was a bit younger, but stood well apart from his peers in capability (and pleasantness).
My impression from this: It's the person, not the age.
EDIT: I've had the opportunity to work with some plenty smart women, too. (I realized the prevalence of the masculine in the above.) Again, several were "older". Same conclusion.
My impression from this: It's the person, not the age.
EDIT: I've had the opportunity to work with some plenty smart women, too. (I realized the prevalence of the masculine in the above.) Again, several were "older". Same conclusion.
Experienced engineers who were more than capable of learning something soon realized that their growth at company was limited b/c boss didn't see them as being different than their current state. So, if you are code Java now, boss thinks you are a "java engineer". People started to leave quickly.
Experience shows what not to do more than it shows what to do. Imagine someone who "knows python" trying to build django, twisted or tornado w/out having general real world experience, domain experience or really understanding why those need to be built. That is a recipe for disaster.
Smart, capable engineers are constantly reinventing themselves. If they feel they are not going to be given a chance to work on something interesting b/c they don't have X on their resume they will move on. The business will suffer as they take domain knowledge and experience with them.
That boss is still at that company. Engineering staff has over 150% turnover in past 18 months (when above boss started). Most engineers have moved onto things that are much more glamorous and interesting but still say they would have preferred to stay there and work on that system. The company itself has slowly started to lose market share and customers are not renewing their contracts. A former clear #1 in the space has become a #3 or #4 at best. Those months watching this boss destroy this company are some of the best lessons I could ever learn...on what not to do and how not to do it.