Comment by spolsky | Hacker News Reader

Comment by spolsky | Hacker News Reader

The fact that Google's employees are young does not say anything or imply anything about the half life of a computer programmer. It's just one data point. Here are reasons why it is skewed:

* Fast-growing companies at large scale do enormous amounts of college recruiting. That's because the quality of the pool is much higher than the pool of out-of-work programmers... not because young people are smarter or better programmers but simply because the candidate pool includes a cross-section of skills, whereas the candidate pool of out-of-work programmers is biased to programmers who can't find work.

See also: http://www.joelonsoftware.com/articles/FindingGreatDeveloper...

Thus, the average age at Facebook is younger than Google, at Google it's younger than Microsoft, and Microsoft is younger than IBM. It's just a question of when the biggest growth spurt occurred in hiring.

* Nobody was working as a software developer 30 years ago. Well, of course, not nobody, but this field has grown like CRAZY. Everybody knows that, but they don't think of the implications. Even if every software developer who started work in 1980 was still working today as a software developer, they would only constitute a small fraction of the current workforce because the number of software developers in 1980 was miniscule. And you would expect them to be working in relatively mature companies simply because those were the companies that were around when they got their jobs.

Bottom line--this "mystery of the disappearing tech worker" is a good bit more imaginary than real and is probably mostly explained by the kinds of people you're hanging around with, not a real social phenomena.

See also: http://www.wolframalpha.com/input/?i=computer+software+appli... (If anyone can figure out how to get older data than Wolfram Alpha displays, I'd appreciate it)

I wish I knew how the Googles and Facebooks hire a crowd of junior programmers and have them do these amazing things.

I am in the 5th year of leading development teams and have more than 5 years to go until my half-life is over. Yet, I have not figured out how to run a team entirely of junior programmers. Yes, they come with a lot of energy and current knowledge but there is also so much missing that people gain from, well, experience. In the field of software but also in all the adjacent domains that are so crucial for being successful as a team. I cannot image how I would do without having a few senior people around who can give things a little structure and a little broader understanding of things.

Also, most experienced folks, even if not super up-to-date with fancy technology, are a hell of a lot more productive than the shooting-from-the-hip youngster. They don't need to put in 12 hour days.

My other problem is that it's so hard to actually find good senior programmers. There are also a lot of people who got stuck more than ten years ago ...

  >> it's so hard to actually find good senior programmers

Most of them either find jobs through referrals, or have become consultants in order to avoid the unwritten rule in many companies that you can't make a higher salary than your manager (yes I know there are exceptions).

I don't know about Facebook, but Google doesn't seem to be hiring many college kids these days. It's hard to find a 22-year-old with both the skill and desire to work in Google's main languages (Java and C++). Also, what you said is quite true: a team consisting entirely of junior programmers is difficult to manage.

I found the hardest part to be the impatience :) But then one has to be fair and look at one self at that age and acknowledge that one was just as much a pain in the ass at that age. Karma pays forward.

iPhone programmers that interface with C/C++ code do, and they're young.

My experienced as an unofficial team lead of a few programmers with various experience (which I conclude that they were Jr. Programmers with a few years of lack of mentorship) was to do the following:

1) Define structure

Set some rules. Coding styles, check-in etiquette

2) Find tools to limit mistakes

Static code analysis, automate build that breaks when #1 fails.

3) Always on alert

Do a lot of code reviews. A lot. Argue and fight over little things (variable naming convention, missing documentations, unclear code).

Now this might not sit well with others so get ready:

4) Become a "drill" sergeant

I find that becoming the "bulldog" sometime works. You've got to become some sort of "drill" sergeant. People may dislike you at first but if the project is successful, they can hate you all the way to the exit door all they like.

That was my experience. I made a concious decision to put the success of the project as the top priority. Even if it means breaking some bridges with other programmers. I hope they learn why I did those things in the future. If they don't, I won't quarrel or regret my action.

5) Be nice on other occasions

I may be the biggest jerk during code-review and check-in commits but when my co-workers stuck, I'll be gladly help them even if it means I have to sit with them and do my overtime. This can gain you some respect after confrontation/intense debate/being a jerk.

I always try to be friendly during office/release party. Give credit to the team, etc.

Just an alternative to #4 (which I have been on times with various degrees of success).

What's the #1 thing people are afraid of? Public shame. I have a theory that Scrum primarily works because of this. Just have daily Scrum-light meetings with your group. If you have 15 minutes with a group of 5-6 people and everyone has to say either "done" or "not done"... the not dones will of course have some silly excuse, but because of the time constraint you must cut them off, be curt, and say to the effect "so John can you help Dan with that right after we break?". And then everyone would make commitments on to what they would do that day. I guess in a way you can say this was being a drill sergeant, but the thing was I wasn't an a-hole, that 15 minute meeting every morning was just part of the process, it was expected.

After a few weeks of this everything moves at twice the speed. I had a team of 6 devs (including myself) burn through nearly 200 bugs in 2 months. That's every engineer fixing about 4 bugs a day. There was a hug chasm of talents on that team... we had the top guy in my dept as well as one of the weakest engineers on the same team. Everyone performed.

Perhaps there is a more euphemistic term than "shame", but I agree that Scrum and code reviews harness this shame in a positive way.

Nice list! That is pretty much what I am expecting of myself and other more senior developers.

I guess, I am not a super good "drill" sergeant, though. All I can do is leading by example, mainly doing a lot of pairing. But that is time consuming, so I might try to develop more of a sergeant attitude.

> I wish I knew how the Googles and Facebooks hire a crowd of junior programmers and have them do these amazing things

Volume. You are forgetting (and/or haven't been privy to) all their failures. Statistically if you do 100 things 1 or 2 of them will be amazing, the rest are crap. We've seen publicly a few of those companies' failures. I'm sure there are many more we haven't.

They haven't managed jr devs any better than the rest of us. They just brute forced it with shed loads of money and people.

Why do you have teams "entirely of junior programmers"? Maybe that's the problem to be addressed, not running them.

The junior programmers I worked with at Google were far better than the senior programmers I worked with at other jobs. Experience has value, but it's not the only attribute that matters when it comes to skill and ability. Taking the best kids out of MIT, CMU, and Stanford is a lot different than the junior programmers you'd encounter at most places.

We don't.

The most effective teams I have worked on at Google have a healthy balance of experienced and inexperienced engineers.

Senior engineers are in extremely high demand at places like Google and Facebook precisely because of the points you bring up.

In the late 70s I worked as a compiler development lead at Control Data. I've kept in contact with many of them because one of the developers has held a New Years reunion party every year for the last couple of decades. Most stayed as developers through the years. It was and is a very talented group of people who ended up at companies like Google and Yahoo. You wont find an ex-CDC clump anywhere, because the ended up as singletons at later generation companies. It's not that they moved out of development; they are dispersed in a much larger pool of developers.

The phenomenon used to exist 30 years ago and may still exist at companies behind the leading edge. The highest engineering salary was near the lowest managerial salary, so if an engineer wanted to get a salary increase, s/he had to become a manager. But even in 70s CDC had established a separate technical salary track so good engineers didnt have to become bad managers.

What you say makes sense, but I wonder: do the big, high profile companies intentionally have a high churn rate on employees, especially young hires?

I heard someone talking about how IBM/Intell/etc... hire PhD's right out of grad school, train them for 6 months, squeeze all the creative energy and effort out of the employee they can for 2-4 years, and then expect the employee to want to go work elsewhere b/c they're burned-out. The productivity they get in those 2-4 years is worth burning out employees.

This also happens in finance, where jobs right out of school are 60-80+ hour weeks for a few years. Then you land a nicer position (likely in management) once you've cut your teeth.

Is there evidence that a similar thing is happening at the Google/Facebooks too?

I don't know that the vampirism is intentional. Even in investment banking, the most evil non-war/oil industry on earth, the bad hours have more to do with a dysfunctional workflow (the real work begins at 4:00 pm and has a next-day deadline, but it's only an 8- to 10-hour day of real work) and secrecy (i.e. hire fewer people and have them doing less interesting work => reduce leak risk) than intentional malice.

I don't think that's happening at companies like Google and Facebook. Companies like that bend over backward to prevent their workers from burning out (massages, healthy cafeteria meals). When people burn out after 2-4 years, they leave behind legacy horrors (speaking of vampires) and that can easily cancel out any benefits you get by working people 60+ hours per week.

My experience in finance IT business is different (but it depends on finance business itself - the difference between writing systems for mortgage industry is different than what quants write and that's different from guys writing integration/real time market data/trading systems).

But what's the most important thing in finance IT business is to keep with business knowledge. Having only pure IT skills will get you nowhere. You need to understand a business side of your finance domain which means being able to easily communicate with your clients/customers in their language. It's pretty common to see IT guys in finance having Series 7/24/63 or CFA certificates on their resume (I'm one of them). Again if you want to be in finance IT business for a long haul, focusing on general IT knowledge only is not enough.

Now we just need to figure out why so many tech workers _believe_ that older tech workers are disappearing. Part of it is, as you say, a demographic shift. I wonder if a big part of it is also due to the employee structure of large, non-software companies.

Non-software companies do hire programmers, but have difficulty recognizing the talented ones, and don't really have structures in place for rewarding that talent. So, the "successful" programmers in those companies quickly figure out that they need to switch over to management. These workers with only a few years of actual software development experience move up into management roles, and take charge of software development groups. What's interesting is that they have so little actual software development experience that they might be perceived as non-technical to their employees, hence the tech worker has effectively "disappeared".

IT industry is very young but in next 20 years it will be pretty common to see a lot of 40+ folks in this business. It's obvious that we don't see many 50+ folks in IT today since when they started 30 years ago IT business was more or less a niche. Plus majority of them were unable to keep with dramatic changes and knowledge absorption thorough the years.

Totally off topic, but I was really surprised that the intern salaries at Fog Creek in 2006 were $750/week, whereas today good interns get about $1500/week + housing in the Bay Area. Have salaries actually doubled in five years?

That looks like it would be at the top end of intern salaries but the figure as far as I understand (just did an internship a few months back) is roughly correct.

Another detail from about the 70s, would be that some of the people doing the programming may have been (extremely good) EEs: Intel switched from making memories to making processors, PARC was being ridiculously productive, and so on.

Reply on news.ycombinator.com