3 ms·

This is an especially important point for coders. In my 23 year professional life I've had 4 very different careers, involving 7 major platform changes, at leas

This is an especially important point for coders. In my 23 year professional life I've had 4 very different careers, involving 7 major platform changes, at least a dozen different languages and more SDK documentation that I can remember. It's not like technology or the rate of change will be slowing down in the future either. So, learning how to learn efficiently is an important tech skill.

vonmoltke 14y ago
I do this constantly, even if my explorations never get beyond surface exploration of new things. My career has moved from electrical engineer->(non-IT) systems engineer->real-time algorithms software engineer (C)->non-real-time algorithms software engineer (Java). Over this course (so far) I have worked in a dozen languages, and may have a dozen more in the next decade. I also try to keep myself astride the hardware-software boundary as best I can. My most frustrating professional experience so far was working in a sequestered program in my prior company where almost everyone in engineering leadership positions had been doing the same damn thing for 20+ years and could not understand why anyone would want to keep learning and trying out new technologies. In fact, showing too much interest in technologies unrelated to the program could be interpreted negatively.[1] I'm both amazed and horrified that such an attitude could persist in this day and age in such a company, but I guess that comes from the program's somewhat unique situation. [1] The old guard on this program had the attitude that you could spend your entire career on it and its derivatives, so there was no reason to want to leave unless you were unhappy, in which case there must be something wrong with you.
- coopdog 14y ago
  Just out of interest, were the old guard who refused to learn the (non-IT) systems engineers? I've had similar experiences with senior engineers and am trying to work out how (or whether) the field should be saved
  - vonmoltke 14y ago
    They were by-and-large the systems engineers. Most had math or physics degrees (BS->PhD), and the rest had various engineering degrees. The bigger problem in this case, though, is the isolation of this project from everything else. Its hard for me to explain properly without the details I can't provide, but in short this group had a really hard problem to solve, and did so. Some people built their entire careers on this, and they developed this destructive attitude that is part Not Invented Here and part superiority complex. The result was that whatever a handful of the senior engineers though was the best approach was the direction "development"[1] went, no matter the evidence to the contrary. I don't think this is indicative of the discipline as a whole. The discipline is necessary in many market segments. Even software companies have systems engineers; they just call them software architects. I'm not sure what could be done about a situation like I described above, though. If you want to discuss this more offline, you can get my contact info from my profile. [1] "Development" in this case was taking obsolete algorithm code, hacking in new functionality as quickly as possible, and forcing it to work with minimal perceived effort in the top-level system where all the software was being written from scratch.

vonmoltke 14y ago

I do this constantly, even if my explorations never get beyond surface exploration of new things. My career has moved from electrical engineer->(non-IT) systems engineer->real-time algorithms software engineer (C)->non-real-time algorithms software engineer (Java). Over this course (so far) I have worked in a dozen languages, and may have a dozen more in the next decade. I also try to keep myself astride the hardware-software boundary as best I can. My most frustrating professional experience so far was working in a sequestered program in my prior company where almost everyone in engineering leadership positions had been doing the same damn thing for 20+ years and could not understand why anyone would want to keep learning and trying out new technologies. In fact, showing too much interest in technologies unrelated to the program could be interpreted negatively.[1] I'm both amazed and horrified that such an attitude could persist in this day and age in such a company, but I guess that comes from the program's somewhat unique situation. [1] The old guard on this program had the attitude that you could spend your entire career on it and its derivatives, so there was no reason to want to leave unless you were unhappy, in which case there must be something wrong with you.

coopdog 14y ago
Just out of interest, were the old guard who refused to learn the (non-IT) systems engineers? I've had similar experiences with senior engineers and am trying to work out how (or whether) the field should be saved
- vonmoltke 14y ago
  They were by-and-large the systems engineers. Most had math or physics degrees (BS->PhD), and the rest had various engineering degrees. The bigger problem in this case, though, is the isolation of this project from everything else. Its hard for me to explain properly without the details I can't provide, but in short this group had a really hard problem to solve, and did so. Some people built their entire careers on this, and they developed this destructive attitude that is part Not Invented Here and part superiority complex. The result was that whatever a handful of the senior engineers though was the best approach was the direction "development"[1] went, no matter the evidence to the contrary. I don't think this is indicative of the discipline as a whole. The discipline is necessary in many market segments. Even software companies have systems engineers; they just call them software architects. I'm not sure what could be done about a situation like I described above, though. If you want to discuss this more offline, you can get my contact info from my profile. [1] "Development" in this case was taking obsolete algorithm code, hacking in new functionality as quickly as possible, and forcing it to work with minimal perceived effort in the top-level system where all the software was being written from scratch.