3 ms·

Fuck this. I think the real danger is being the 12-year master of TPF reports at BigCorp, Inc. How do you spin 20 years at BigCorp in an increasingly non-tech

by tom_b 15y ago

Fuck this. I think the real danger is being the 12-year master of TPF reports at BigCorp, Inc. How do you spin 20 years at BigCorp in an increasingly non-technical role over that time window in a way that would actually excite Google or Facebook? I think the norm for those of us who want to stay technically relevant is to be open to re-inventing our hacker skills, master the linking of our efforts to bottom-line results, and the wisdom to know when the time has come to tackle new tech stacks and projects.

deleted 15y ago
[deleted]
spitfire 15y ago
Simple: Experience. With a little grey hair comes the wisdom of what paths NOT to go down, no matter how attractive they are initially. Also, math and analysis skills never go out of style. The fact is, the technology industry does not value experience it values novelty. Try asking a rails dev what a taylor series is sometime. I'll take the guy with deep experience and analytical skills and self awareness but just a little $cooltech exposure any day.
- ahoyhere 15y ago
  Grey hairs don't correlate with wisdom. Most people don't actually grow and change all that much, they just get older.
- steve-howard 15y ago
  How much programming requires you to know about Taylor series? I think they're nifty, but not very relevant to most work. I sort of agree with you that experience matters, but I'm not so sure math is useful unless you're writing programs for scientific computing or you want to be a professor.
  - moultano 15y ago
    That's self-fulfilling. Math lets you solve problems that you wouldn't even have though of as problems before. If you don't know the math, your brain skips over them as a fact of life rather than as something with a solution. Programming doesn't require math because programmers don't necessarily know math, not because the opportunity isn't there.
  - amcintyre 15y ago
    It's not so much knowing a long list of mathematical facts, as acquiring the mindset that lets you take those facts and apply them to new situations. Sure, you can choose a programming career where you don't need to know what a Taylor series is, how large linear systems are solved, or even what sine and cosine are. Maybe that will be a safe choice for the forseeable future, but more and more apps involve 3D, machine learning, computer vision, data analysis, etc. I personally view it as increased job security to learn as much as I can about the basic tools that let me understand how those things work. To not do so is (in my mind, anyway) very much the same as saying that caching, or complexity theory, or how to build a linked list is "not very relevant to most work": it may seriously limit the jobs you're eligible for in the future, because you'll lack the foundation to understand the work at hand at even the most basic level. That said, I've always been interested in math, and probably obsess too much over knowing how things work. I can appreciate that it's just not interesting enough for most people to pursue.
  - cageface 15y ago
    Taylor series are very handy in DSP for finding good approximations to computationally expensive functions.
- tsotha 15y ago
  >With a little grey hair comes the wisdom of what paths NOT to go down, no matter how attractive they are initially. That's certainly true. After awhile you've been involved in enough projects you can pick out the ones that are in trouble long before the younger guys. The problem is this kind of experience/wisdom is hard to get across in an interview.
ShabbyDoo 15y ago
Yes. How many people have you observed in BigCo's whose value lies mostly in knowing some internal, proprietary process/technology/etc.? They might make $100K and be worth that amount for awhile to the BigCo compared to someone from off the street who doesn't know how to help out CustomerX who has been stuck on a customized version of the company's flagship product from 12 years ago. Maybe this person is compliant, polite, and completes near-menial work as asked. So, whenever a round of layoffs happens, he or she never gets cut.There are a bunch of reasons why those with scant technical skills end-up sticking around. However, the divide between this person's salary and that which he could get at another company grows ever wider. Whenever I read stories about out-of-work "older" engineers, I presume them members of the categories I described above. What never seems to be said is that their plights usually are the results of decisions they made over a decade before. Stick with the current company doing crappy technology X? Yeah, it's boring, but the benefits are good and the work is low-stress. Go out on job interviews? I know deep down inside that I'm a mediocre developer, but my current company seems to put up with my crappy code and low productivity. SO, I 'd better stay right where I am. In this latter case, it could be argued that the "older" person's previous employ-ability was an accident or aberration. There probably are few on HN who can imagine being like these people, so it's hard to relate. I just turned 37 and think that I'm a better dev than at 27. I've been thinking a bit about how my thought processes have changed. One thing I do now is mull through a lot of ideas before bothering to write code. If there are 50 ways to do something, it's worth taking a way to get a cup of coffee and think through a few possibilities. Along with that, I am less likely to believe that my current view into a problem or situation is accurate. What's the probability that the design I mulled over in the shower this morning will actually work out? As I've aged, I've assigned lower probabilities to positive outcomes, and I don't think my thoughts are of worse quality. So, I experiment more, and my experiments (iterations, or whatever else you want to call them) are faster, dirtier, and prove me right or wrong faster than the paths I embarked on before. My ability to hold a large, "working" model of a system in my head an perform experiments on it has improved over time. This is really what debugging is all about. I now ask better questions about how a system ought to function based on experience. What should happen if the async remoting process fails? How will humans know that a failure has happened? I think of these things because I've endured the pain in the past of finding out three days later that some background process has gone haywire. So, what are the negatives? I'm less likely to run off and push a new technology into an important system. Around 2001, I wrote a macro-processor-y thing in Python (1.5x timeframe). The company I worked for was a Java shop. I was intrigued with Python, so I decided to learn something. The thing I built worked really well, but it was later converted into Java so that any one of N competent developers could hack on it when issues arose. Today, I'd suck it up from the beginning, look at the realities of the organization, and end-up writing the thing in Java from the beginning. Maybe I'd use some alternate JVM language, but I'd have to think hard about doing so. I'm still regarded as a loose cannon when it comes to dragging additional open source dependencies into codebases, so maybe I've never grown up. Who knows. I really can't think of any downsides to having gotten older other than feeling agitated when "kids" don't know how a hashtable works. Back in my day....

by tom_b 15y ago

deleted 15y ago

[deleted]

spitfire 15y ago

Simple: Experience. With a little grey hair comes the wisdom of what paths NOT to go down, no matter how attractive they are initially. Also, math and analysis skills never go out of style. The fact is, the technology industry does not value experience it values novelty. Try asking a rails dev what a taylor series is sometime. I'll take the guy with deep experience and analytical skills and self awareness but just a little $cooltech exposure any day.

ahoyhere 15y ago
Grey hairs don't correlate with wisdom. Most people don't actually grow and change all that much, they just get older.
steve-howard 15y ago
How much programming requires you to know about Taylor series? I think they're nifty, but not very relevant to most work. I sort of agree with you that experience matters, but I'm not so sure math is useful unless you're writing programs for scientific computing or you want to be a professor.
- moultano 15y ago
  That's self-fulfilling. Math lets you solve problems that you wouldn't even have though of as problems before. If you don't know the math, your brain skips over them as a fact of life rather than as something with a solution. Programming doesn't require math because programmers don't necessarily know math, not because the opportunity isn't there.
- amcintyre 15y ago
  It's not so much knowing a long list of mathematical facts, as acquiring the mindset that lets you take those facts and apply them to new situations. Sure, you can choose a programming career where you don't need to know what a Taylor series is, how large linear systems are solved, or even what sine and cosine are. Maybe that will be a safe choice for the forseeable future, but more and more apps involve 3D, machine learning, computer vision, data analysis, etc. I personally view it as increased job security to learn as much as I can about the basic tools that let me understand how those things work. To not do so is (in my mind, anyway) very much the same as saying that caching, or complexity theory, or how to build a linked list is "not very relevant to most work": it may seriously limit the jobs you're eligible for in the future, because you'll lack the foundation to understand the work at hand at even the most basic level. That said, I've always been interested in math, and probably obsess too much over knowing how things work. I can appreciate that it's just not interesting enough for most people to pursue.
- cageface 15y ago
  Taylor series are very handy in DSP for finding good approximations to computationally expensive functions.
tsotha 15y ago
>With a little grey hair comes the wisdom of what paths NOT to go down, no matter how attractive they are initially. That's certainly true. After awhile you've been involved in enough projects you can pick out the ones that are in trouble long before the younger guys. The problem is this kind of experience/wisdom is hard to get across in an interview.

ShabbyDoo 15y ago

Yes. How many people have you observed in BigCo's whose value lies mostly in knowing some internal, proprietary process/technology/etc.? They might make $100K and be worth that amount for awhile to the BigCo compared to someone from off the street who doesn't know how to help out CustomerX who has been stuck on a customized version of the company's flagship product from 12 years ago. Maybe this person is compliant, polite, and completes near-menial work as asked. So, whenever a round of layoffs happens, he or she never gets cut.There are a bunch of reasons why those with scant technical skills end-up sticking around. However, the divide between this person's salary and that which he could get at another company grows ever wider. Whenever I read stories about out-of-work "older" engineers, I presume them members of the categories I described above. What never seems to be said is that their plights usually are the results of decisions they made over a decade before. Stick with the current company doing crappy technology X? Yeah, it's boring, but the benefits are good and the work is low-stress. Go out on job interviews? I know deep down inside that I'm a mediocre developer, but my current company seems to put up with my crappy code and low productivity. SO, I 'd better stay right where I am. In this latter case, it could be argued that the "older" person's previous employ-ability was an accident or aberration. There probably are few on HN who can imagine being like these people, so it's hard to relate. I just turned 37 and think that I'm a better dev than at 27. I've been thinking a bit about how my thought processes have changed. One thing I do now is mull through a lot of ideas before bothering to write code. If there are 50 ways to do something, it's worth taking a way to get a cup of coffee and think through a few possibilities. Along with that, I am less likely to believe that my current view into a problem or situation is accurate. What's the probability that the design I mulled over in the shower this morning will actually work out? As I've aged, I've assigned lower probabilities to positive outcomes, and I don't think my thoughts are of worse quality. So, I experiment more, and my experiments (iterations, or whatever else you want to call them) are faster, dirtier, and prove me right or wrong faster than the paths I embarked on before. My ability to hold a large, "working" model of a system in my head an perform experiments on it has improved over time. This is really what debugging is all about. I now ask better questions about how a system ought to function based on experience. What should happen if the async remoting process fails? How will humans know that a failure has happened? I think of these things because I've endured the pain in the past of finding out three days later that some background process has gone haywire. So, what are the negatives? I'm less likely to run off and push a new technology into an important system. Around 2001, I wrote a macro-processor-y thing in Python (1.5x timeframe). The company I worked for was a Java shop. I was intrigued with Python, so I decided to learn something. The thing I built worked really well, but it was later converted into Java so that any one of N competent developers could hack on it when issues arose. Today, I'd suck it up from the beginning, look at the realities of the organization, and end-up writing the thing in Java from the beginning. Maybe I'd use some alternate JVM language, but I'd have to think hard about doing so. I'm still regarded as a loose cannon when it comes to dragging additional open source dependencies into codebases, so maybe I've never grown up. Who knows. I really can't think of any downsides to having gotten older other than feeling agitated when "kids" don't know how a hashtable works. Back in my day....