5 ms·

I've never understood why for many professions age/experience is coveted but engineers are assumed to have such a short shelf life. Nobody prefers a 30 year old

I've never understood why for many professions age/experience is coveted but engineers are assumed to have such a short shelf life. Nobody prefers a 30 year old lawyer or doctor over a more experienced one but an engineer of the same age needs to start planning a career transition...where is the logic in this?

timr 13y ago
Doctors and lawyers gain skill as they get older because the problems and solutions don't change quickly, and the fields have such depth that expertise takes decades to acquire. We work in an industry where the state-of-the-art is perpetually accessible to 20-somethings who haven't done anything, because the technology gets blown up once a decade (or so). Even if you stay up to date, why would anyone pay you a salary commensurate with your experience, when a total noob can do the same work for half as much? For example, it's pretty embarrassing that we're re-inventing databases because today's generation of "experts" can't be bothered to understand SQL. And don't get me started on how an entire generation of coders will be able to work professionally without knowing how to manage memory. It isn't difficult to find examples of youth and exuberance trumping wisdom in this field -- I've already encountered working developers who are happy to tell me how technologies invented in the early part of this decade are "totally outdated".
- MetaCosm 13y ago
  I think we are reaching the golden age of the older developer. Companies are learning how much more great developers are worth than poor ones. Retention bonuses have gone crazy (getting a 3 year / 250k bonus package isn't even that interesting). The evergreen underpinnings, the basic knowledge of how to build systems floats through languages and technologies.
  - timr 13y ago
    Agree with you about the value of older devs, but I wish I could say I saw "the industry" paying for experience. The examples of ridiculous grants I know about have all gone to people who are in their 20s and early 30s. Granted, there's some selection bias going on: I don't see many 40-something programmers in SOMA. That said: I don't see many 40-something programmers in SOMA.
    - MetaCosm 13y ago
      Rampant speculation, but while drinking me and some developer friends came up with a theory on this. There was a sweet spot, a golden age if you will where a lot of things came together for kids / young adults to drive them to be developers. They are 25 to 40 now. Computers became cheap enough to have at home. BBSs and then the Internet took off. Computers were doing stuff -- but not common place yet. It was an odd window during a technologies birth that I think got people hooked in a way that is hard to emulate. Too early, you are on punch-cards and computers are rare. Too late, and you have app stores and iphones and stuff just generally works so it can be treated as a dumb tool. Sheer luck.
- kenjackson 13y ago
  I've written about this before. You're right, but I think you miss (or simply gloss over) something that is critically different in software -- abstraction and reusability. The nature of SW is to create abstractions that are reusable. So if you've built a good reusable abstraction, no one needs to know what's "under the hood" except in rare circumstances. Ask your frontend web dev to explain some differences between the x86 and ARM ISA. Most won't have clue. Even much higher up the stack, most probably couldn't explain how TCP/IP work. For the most part it's irrelevant. Other fields don't/can't build on lower levels in such a way that practitioners never have to learn the lower levels at all. How many surgeons are there that don't know cell biology? Your best hope is to either continuously churn with the latest trends. Or pick a part in the stack that is likely to not change, and be a niche expert (aka, a networking guru, or x86 god). Your job opportunities will be much smaller, but if you can find your team (e.g., compiler architect or processor performance analyst) you'll likely to have a job for as long as you like.
- ilaksh 13y ago
  I'm 35. I started learning SQL, C, C++, memory management etc. many years ago when I was a teenager. However, and I know that people will take the opportunity to disrespect me for this, but I realized, after playing around with 3d C++ graphics in college, that I wanted to build interactive desktop applications quickly. So I learned to use a very powerful tool called Visual Basic 6. Not because I didn't understand memory management or anything else, but because it was a better software engineering decision for most projects since it allowed me to not repeat solving the same problems that had already been solved. I know people aren't going to be able to understand this because of the reputation that Visual Basic has, and they will lose respect for me, but I am going to go ahead and say it anyway. Visual Basic 6 was and still is a better software engineering tool than C++. Why? One of the core principles of software engineering is DRY. Manual memory management means you are repeating yourself. It also means you are doing the memory management yourself rather than letting the computer do it for you. Another reason why Visual Basic 6 is superior software engineering over C or C++ is the component models. I eventually moved on to .NET and C# because of the stigma of VB and also because the new frameworks provided better tools. Eventually I realized that the closed source world of desktop Microsoft development was outdated since it was tied to one platform and old-fashioned business models. So I moved into web development. The most practical tool for web development was PHP. It was the best software engineering decision to select PHP to build a web application. Because it allowed me to avoid solving the same problems that many other engineers had already been faced with and solved on their own. Something that many software engineers don't understand is that not only is it important not to repeat yourself in your own code, but not to repeat solving the same problems other people have already solved for you. So then I wanted to build a realtime interactive collaborative software application in the web browser. Because that is the most compelling, useful, and challenging type of application. So I tried to do it with PHP. Very awkward. I tried to use another popular server-side tool, Python. Again it turned out to be very awkward to do realtime collaborative software applications with Python (using things like Twisted). So when I heard about this thing called Node.js that was built from the ground up to take full advantage of the single-threaded but asynchronous programming model of JavaScript as well as powerful underlying evented non-blocking I/O C libraries, I had to try it. Guess what? All of that software engineering done by the people who wrote those C libraries and the people who put together JavaScript and Node means that there are a lot of problems that I don't have to solve to write performant IO-intensive code on the back end! Continuation-based programming in JavaScript and Node.js just works better and is more maintainable (less code and less complexity) than the other solutions. So I'm sorry, but if you're not adopting new programming languages, tools and frameworks, then I don't think you are a good software engineer. Because good software engineers only solve the problems that they have to, and don't continue to solve the same problems over and over. Now -- NoSQL. So, it turns out that NONE of the many software applications I built over the years using Oracle, SQL Server or MySQL actually required 'real' db-level transactions or even involved very large datasets. And I believe that is the case for most programmers (not all of course). These days that is still true. Also, these days I only code in JavaScript (mostly CoffeeScript really). So when I heard about things like MongoDB that allowed me to store JSON directly, skip the object relational layer, and not even have to define a schema ahead of time, I had to seriously consider whether I needed a normalized relational database, SQL, to constantly reiterate joins, etc. When you examine it logically, it turns out that we were actually doing all of those things just because THAT WAS HOW YOU DID IT. With the current ecosystem of JavaScript and JSON, it is BAD SOFTWARE ENGINEERING for the MAJORITY of software projects to use a relational database, joins, etc. Why is it bad software engineering? Because you are creating a bunch of problems for yourself that you wouldn't have if you used a different set of tools.
digikata 13y ago
I'll hit 40 this year, and have been in more demand in my last five years than I have earlier in my career. I think there are engineering areas & companies which really don't need anything more than a recent graduate. For those needs, it doesn't make sense to hire someone at higher salary and experience levels. However, there are technical areas that strongly benefit from experience. I can't really advise what those areas are exactly. It depends on your personal history and interests, and there are a lot of short sighted companies that don't value experience enough - to the detriment of their own efficiency.
rayiner 13y ago
I think the differences stem from two factors: 1) Doctors and lawyers are seen as exercising judgment, while engineers are seen as building things. 2) Training opportunities (in the "learn by doing" sense of "training") for doctors and lawyers are much harder to come by than for engineers. If you're looking for a lawyer who has taken half a dozen big commercial litigations through trial, you're probably looking for someone very old because there just aren't very many of those trials that happen. Same thing if you're looking for a doctor with half a dozen experiences treating a patient with aggressive cancer. But how hard is it to find a young software engineer with half a dozen big websites under his belt? Now, I don't think either perception is completely true, in the sense that I think people underestimate how much judgment software engineers exercise and overestimate how quickly they can build up valuable experience.
arn 13y ago
Actually don't know if that's true. As a former physician myself, in many circumstances, I would prefer a younger (to a degree) physician to a much older one. Medical knowledge does change relatively quickly and standards of care change a lot. For the same reason as engineers, it comes down to keeping up with the field. I don't know for a fact that an old physician hasn't kept up with the field, but I do know a younger one can only be so behind.
- timr 13y ago
  "Medical knowledge does change relatively quickly and standards of care change a lot." You have to be clear about the relative rate of change, though: it's nothing like software, where technical knowledge from a decade ago is completely irrelevant today. Medical appointments are pretty much the same as when I was a kid. The more important point, for me, is judgment: older doctors are far less goofy and spastic than younger ones. That means more conservative treatment, discretion, etc.
  - ycombobreaker 13y ago
    > Medical appointments are pretty much the same as when I was a kid. I have a young child, and I have had enough conversations with doctors and nurses to see that standards for medical care _do_ change rapidly enough to matter. Some examples: - At the hospital where my wife gave birth, the SOP is an epidural and continuous fetal monitoring. This means that very little equipment is available which supports mobility. The hospital staff had a hard time wrapping their heads around the idea _lying on your back is painful_ for someone in labor. The human body hasn't changed, but the medical practices are currently optimized around the assumption of an epidural and keeping to a schedule. Doctors who have let this assumption ossify will force the hands of patients who simply don't know otherwise. - My pediatrician's practice currently recommends avoiding peanut butter until age... three? I think. However, there is recent research on some children of Jewish ancestry in the UK vs. Israel, suggesting that their very low rates of peanut butter allergy are probably due to environment rather than a genetic predisposition. If further studies confirm that finding, the AMA will probably revise its suggestions, causing all pediatricians to start offering the _opposite_ advice. - Recent research (sorry, don't have the reference) showed higher rates of food-related allergies when children were exposed to solid foods earlier than 3 months. [edit for list formatting]
huherto 13y ago
Another practice is that in most professions, leaders are also very capable in their own areas. Think about a law firm, a hospital, an accounting firm, a construction company. But often in programming you have managers that are ignorant, outdated and sometimes even complete idiots. Why do we put up with that? Why do accept that our managers are not more capable than we are?
- kenjackson 13y ago
  IC's in all professions think their managers are idiots. I've heard it from lawyers, police officers, teachers, and sales people. I think its just human nature that your boss (or management in general) is out of touch and an idiot. It's why politicians are clueless -- until you get elected and then you suddenly are viewed as clueless too.
geebee 13y ago
On thing to consider is that doctors and lawyers are members of professional associations that resemble cartels in many ways. It could be that the powerful elder members of these groups ensure that their professions don't evolve in a way that would overly favor young people. For instance, suppose that software engineers were required to hold S.D's (software doctorates, a three year professional doctoral degree that limits enrollment overall to ensure scarcity and severely limit the enrollment of international students). To get this this SJ, you are required to implement things in enterprise java, with massive amounts of complexity, in a way that is difficult to change. Also, scope is broad - making very minor changes to html code is ok for a para-software, but only under the supervision of a licensed member of the Software Bar. Anything involving "programming logic" counts as practicing software, and if you are not a member of the ASA and you do this, you can be imprisoned. In addition, suppose this group used influence over congress to place heavy and database requirements on the business world - in short, forcing them to spend a great deal of money on licensed members of the "American Software Association". I suspect that under these circumstances, software wouldn't evolve quickly at all.
mc-lovin 13y ago
Now that the issue of "discrimination" has reared its ugly head, no one can give a straight answer to your question. By that I mean that any explanation of why people over 30 really are worse programmers, will be interpreted as "discrimination" and therefore wrong. Any explanation of why people over 30 are better programmers, will be taken as evidence that there must be a lot of discrimination since the older programmers are not only not worse, but better.

timr 13y ago

Doctors and lawyers gain skill as they get older because the problems and solutions don't change quickly, and the fields have such depth that expertise takes decades to acquire. We work in an industry where the state-of-the-art is perpetually accessible to 20-somethings who haven't done anything, because the technology gets blown up once a decade (or so). Even if you stay up to date, why would anyone pay you a salary commensurate with your experience, when a total noob can do the same work for half as much? For example, it's pretty embarrassing that we're re-inventing databases because today's generation of "experts" can't be bothered to understand SQL. And don't get me started on how an entire generation of coders will be able to work professionally without knowing how to manage memory. It isn't difficult to find examples of youth and exuberance trumping wisdom in this field -- I've already encountered working developers who are happy to tell me how technologies invented in the early part of this decade are "totally outdated".

MetaCosm 13y ago
I think we are reaching the golden age of the older developer. Companies are learning how much more great developers are worth than poor ones. Retention bonuses have gone crazy (getting a 3 year / 250k bonus package isn't even that interesting). The evergreen underpinnings, the basic knowledge of how to build systems floats through languages and technologies.
- timr 13y ago
  Agree with you about the value of older devs, but I wish I could say I saw "the industry" paying for experience. The examples of ridiculous grants I know about have all gone to people who are in their 20s and early 30s. Granted, there's some selection bias going on: I don't see many 40-something programmers in SOMA. That said: I don't see many 40-something programmers in SOMA.
  - MetaCosm 13y ago
    Rampant speculation, but while drinking me and some developer friends came up with a theory on this. There was a sweet spot, a golden age if you will where a lot of things came together for kids / young adults to drive them to be developers. They are 25 to 40 now. Computers became cheap enough to have at home. BBSs and then the Internet took off. Computers were doing stuff -- but not common place yet. It was an odd window during a technologies birth that I think got people hooked in a way that is hard to emulate. Too early, you are on punch-cards and computers are rare. Too late, and you have app stores and iphones and stuff just generally works so it can be treated as a dumb tool. Sheer luck.
kenjackson 13y ago
I've written about this before. You're right, but I think you miss (or simply gloss over) something that is critically different in software -- abstraction and reusability. The nature of SW is to create abstractions that are reusable. So if you've built a good reusable abstraction, no one needs to know what's "under the hood" except in rare circumstances. Ask your frontend web dev to explain some differences between the x86 and ARM ISA. Most won't have clue. Even much higher up the stack, most probably couldn't explain how TCP/IP work. For the most part it's irrelevant. Other fields don't/can't build on lower levels in such a way that practitioners never have to learn the lower levels at all. How many surgeons are there that don't know cell biology? Your best hope is to either continuously churn with the latest trends. Or pick a part in the stack that is likely to not change, and be a niche expert (aka, a networking guru, or x86 god). Your job opportunities will be much smaller, but if you can find your team (e.g., compiler architect or processor performance analyst) you'll likely to have a job for as long as you like.
ilaksh 13y ago
I'm 35. I started learning SQL, C, C++, memory management etc. many years ago when I was a teenager. However, and I know that people will take the opportunity to disrespect me for this, but I realized, after playing around with 3d C++ graphics in college, that I wanted to build interactive desktop applications quickly. So I learned to use a very powerful tool called Visual Basic 6. Not because I didn't understand memory management or anything else, but because it was a better software engineering decision for most projects since it allowed me to not repeat solving the same problems that had already been solved. I know people aren't going to be able to understand this because of the reputation that Visual Basic has, and they will lose respect for me, but I am going to go ahead and say it anyway. Visual Basic 6 was and still is a better software engineering tool than C++. Why? One of the core principles of software engineering is DRY. Manual memory management means you are repeating yourself. It also means you are doing the memory management yourself rather than letting the computer do it for you. Another reason why Visual Basic 6 is superior software engineering over C or C++ is the component models. I eventually moved on to .NET and C# because of the stigma of VB and also because the new frameworks provided better tools. Eventually I realized that the closed source world of desktop Microsoft development was outdated since it was tied to one platform and old-fashioned business models. So I moved into web development. The most practical tool for web development was PHP. It was the best software engineering decision to select PHP to build a web application. Because it allowed me to avoid solving the same problems that many other engineers had already been faced with and solved on their own. Something that many software engineers don't understand is that not only is it important not to repeat yourself in your own code, but not to repeat solving the same problems other people have already solved for you. So then I wanted to build a realtime interactive collaborative software application in the web browser. Because that is the most compelling, useful, and challenging type of application. So I tried to do it with PHP. Very awkward. I tried to use another popular server-side tool, Python. Again it turned out to be very awkward to do realtime collaborative software applications with Python (using things like Twisted). So when I heard about this thing called Node.js that was built from the ground up to take full advantage of the single-threaded but asynchronous programming model of JavaScript as well as powerful underlying evented non-blocking I/O C libraries, I had to try it. Guess what? All of that software engineering done by the people who wrote those C libraries and the people who put together JavaScript and Node means that there are a lot of problems that I don't have to solve to write performant IO-intensive code on the back end! Continuation-based programming in JavaScript and Node.js just works better and is more maintainable (less code and less complexity) than the other solutions. So I'm sorry, but if you're not adopting new programming languages, tools and frameworks, then I don't think you are a good software engineer. Because good software engineers only solve the problems that they have to, and don't continue to solve the same problems over and over. Now -- NoSQL. So, it turns out that NONE of the many software applications I built over the years using Oracle, SQL Server or MySQL actually required 'real' db-level transactions or even involved very large datasets. And I believe that is the case for most programmers (not all of course). These days that is still true. Also, these days I only code in JavaScript (mostly CoffeeScript really). So when I heard about things like MongoDB that allowed me to store JSON directly, skip the object relational layer, and not even have to define a schema ahead of time, I had to seriously consider whether I needed a normalized relational database, SQL, to constantly reiterate joins, etc. When you examine it logically, it turns out that we were actually doing all of those things just because THAT WAS HOW YOU DID IT. With the current ecosystem of JavaScript and JSON, it is BAD SOFTWARE ENGINEERING for the MAJORITY of software projects to use a relational database, joins, etc. Why is it bad software engineering? Because you are creating a bunch of problems for yourself that you wouldn't have if you used a different set of tools.

digikata 13y ago

I'll hit 40 this year, and have been in more demand in my last five years than I have earlier in my career. I think there are engineering areas & companies which really don't need anything more than a recent graduate. For those needs, it doesn't make sense to hire someone at higher salary and experience levels. However, there are technical areas that strongly benefit from experience. I can't really advise what those areas are exactly. It depends on your personal history and interests, and there are a lot of short sighted companies that don't value experience enough - to the detriment of their own efficiency.

rayiner 13y ago

I think the differences stem from two factors: 1) Doctors and lawyers are seen as exercising judgment, while engineers are seen as building things. 2) Training opportunities (in the "learn by doing" sense of "training") for doctors and lawyers are much harder to come by than for engineers. If you're looking for a lawyer who has taken half a dozen big commercial litigations through trial, you're probably looking for someone very old because there just aren't very many of those trials that happen. Same thing if you're looking for a doctor with half a dozen experiences treating a patient with aggressive cancer. But how hard is it to find a young software engineer with half a dozen big websites under his belt? Now, I don't think either perception is completely true, in the sense that I think people underestimate how much judgment software engineers exercise and overestimate how quickly they can build up valuable experience.

arn 13y ago

Actually don't know if that's true. As a former physician myself, in many circumstances, I would prefer a younger (to a degree) physician to a much older one. Medical knowledge does change relatively quickly and standards of care change a lot. For the same reason as engineers, it comes down to keeping up with the field. I don't know for a fact that an old physician hasn't kept up with the field, but I do know a younger one can only be so behind.

timr 13y ago
"Medical knowledge does change relatively quickly and standards of care change a lot." You have to be clear about the relative rate of change, though: it's nothing like software, where technical knowledge from a decade ago is completely irrelevant today. Medical appointments are pretty much the same as when I was a kid. The more important point, for me, is judgment: older doctors are far less goofy and spastic than younger ones. That means more conservative treatment, discretion, etc.
- ycombobreaker 13y ago
  > Medical appointments are pretty much the same as when I was a kid. I have a young child, and I have had enough conversations with doctors and nurses to see that standards for medical care _do_ change rapidly enough to matter. Some examples: - At the hospital where my wife gave birth, the SOP is an epidural and continuous fetal monitoring. This means that very little equipment is available which supports mobility. The hospital staff had a hard time wrapping their heads around the idea _lying on your back is painful_ for someone in labor. The human body hasn't changed, but the medical practices are currently optimized around the assumption of an epidural and keeping to a schedule. Doctors who have let this assumption ossify will force the hands of patients who simply don't know otherwise. - My pediatrician's practice currently recommends avoiding peanut butter until age... three? I think. However, there is recent research on some children of Jewish ancestry in the UK vs. Israel, suggesting that their very low rates of peanut butter allergy are probably due to environment rather than a genetic predisposition. If further studies confirm that finding, the AMA will probably revise its suggestions, causing all pediatricians to start offering the _opposite_ advice. - Recent research (sorry, don't have the reference) showed higher rates of food-related allergies when children were exposed to solid foods earlier than 3 months. [edit for list formatting]

huherto 13y ago

Another practice is that in most professions, leaders are also very capable in their own areas. Think about a law firm, a hospital, an accounting firm, a construction company. But often in programming you have managers that are ignorant, outdated and sometimes even complete idiots. Why do we put up with that? Why do accept that our managers are not more capable than we are?

kenjackson 13y ago
IC's in all professions think their managers are idiots. I've heard it from lawyers, police officers, teachers, and sales people. I think its just human nature that your boss (or management in general) is out of touch and an idiot. It's why politicians are clueless -- until you get elected and then you suddenly are viewed as clueless too.

geebee 13y ago

On thing to consider is that doctors and lawyers are members of professional associations that resemble cartels in many ways. It could be that the powerful elder members of these groups ensure that their professions don't evolve in a way that would overly favor young people. For instance, suppose that software engineers were required to hold S.D's (software doctorates, a three year professional doctoral degree that limits enrollment overall to ensure scarcity and severely limit the enrollment of international students). To get this this SJ, you are required to implement things in enterprise java, with massive amounts of complexity, in a way that is difficult to change. Also, scope is broad - making very minor changes to html code is ok for a para-software, but only under the supervision of a licensed member of the Software Bar. Anything involving "programming logic" counts as practicing software, and if you are not a member of the ASA and you do this, you can be imprisoned. In addition, suppose this group used influence over congress to place heavy and database requirements on the business world - in short, forcing them to spend a great deal of money on licensed members of the "American Software Association". I suspect that under these circumstances, software wouldn't evolve quickly at all.

mc-lovin 13y ago

Now that the issue of "discrimination" has reared its ugly head, no one can give a straight answer to your question. By that I mean that any explanation of why people over 30 really are worse programmers, will be interpreted as "discrimination" and therefore wrong. Any explanation of why people over 30 are better programmers, will be taken as evidence that there must be a lot of discrimination since the older programmers are not only not worse, but better.