Age will matter more in a loose job market (more people than jobs). In a tight market as it is today, your skills are front and center, not your age. That said, the OP is correct. You're only as good as your last two years and even that's pushing it. If the tech changes, you have to adapt with it. I'm 53 as of yesterday (the 8th). I started with PDP-11's in the 80's, then VAX's, then PC's, BASIC at first, then C, the…
Age will matter more in a loose job market (more people than jobs). In a tight market as it is today, your skills are front and center, not your age. The fact that people are still claiming there is a shortage of tech workers, demonstrates that that isn't true. The industry wants young, cheap workers who come ready made with the trendiest skills, then it wants to ditch them rather than retraining or allowing them to…
On Getting Older in Tech
331–340 of 440 posts
Re: On Getting Older in Tech
#33248 yo here, started coding when I was 14, so that's 34 years of building things. Here's where I'm at. I look back at my career and I can tell you about great projects that I got to be part of, awards and plaudits that I won, big paybacks from projects that went well and literally saved the company. That's all nice to have war stories. But I can't point to any of it and say, "I made that" because - and here's the kick…
Re: On Getting Older in Tech
#333Any language is superior to JavaScript.
Re: On Getting Older in Tech
#334Earlier quoted context omitted.
Age will matter more in a loose job market (more people than jobs). In a tight market as it is today, your skills are front and center, not your age. The fact that people are still claiming there is a shortage of tech workers, demonstrates that that isn't true. The industry wants young, cheap workers who come ready made with the trendiest skills, then it wants to ditch them rather than retraining or allowing them to…
Devs should train themselves. If you're waiting for someone to train you, you're not going to last in software development for very long.
Re: On Getting Older in Tech
#335There's a reason why ageism exists in the industry and it isn't because of some undeserved stereotype about old dogs not being able to learn new tricks. 1) Most business-critical projects have long lifetimes. There's a reason why banks are still running COBOL and mainframes, and why Java's continued promise of backward compatibility with every new release is so valuable to companies. 2) Maintaining legacy systems is…
Therefore no employer wants to hire somebody who writes code which almost immediately turns into legacy code But what is "legacy" or not is not to do with technology, but fashion. Let me give you an example: everyone rants on here about what awful languages PHP and JS are. Is COBOL really a worse language than either of those? If so why? What algorithms or data structures can't be implemented in it? What tooling does…
The hardest thing about COBOL is the mainframe it has to run on. Without that access, I haven't done much coding outside of class.
Re: On Getting Older in Tech
#336Earlier quoted context omitted.
I used to be able to burn longer when I was twenty, but I'd spend that fuel on shit I've learned doesn't matter like 100% test case coverage, setting up continuous integration servers, and load testing against massive amounts of traffic I'd never see. I could go on and on about the stuff I'd do I don't do anymore. It's not that those things don't have their place, or that all young programmers are guilty of premature…
Do you ever get asked about this? e.g. what you don't do anymore as a result of learning from experience Either in your current role / in interviews / on the street?
Re: On Getting Older in Tech
#337I also try and get beyond the hype. REST/HATEOS is cool? What about the things it replaced? What are the edge cases? What was the original design intent?
I also read from/talk with older engineers (many of whom I have the privilege to work with) to understand what things were like during previous fads.
Ultimately, the problem is about staying marketable while giving fair due to our life outside of work (I prefer the term "unpaid responsibilities" to "leisure time"). I don't claim to have solved this problem, and I still have concerns about what the future holds, but my instinct is that staying on top of fads is a trap that I want to avoid.
Re: On Getting Older in Tech
#338> let’s look at the average age of IT workers at well-established companies. Facebook: 28. LinkedIn: 29. Google: 30 I had an interview at Google a couple months ago and noticed that most people were pretty young. When I asked the person who was in charge of taking me to lunch about this, he said that it's probably because there are just much more graduates of CS now than there were before, and that Google would very…
[1] source: I work for Google.
Re: On Getting Older in Tech
#33948 yo here, started coding when I was 14, so that's 34 years of building things. Here's where I'm at. I look back at my career and I can tell you about great projects that I got to be part of, awards and plaudits that I won, big paybacks from projects that went well and literally saved the company. That's all nice to have war stories. But I can't point to any of it and say, "I made that" because - and here's the kick…
Stallman, 63, can point to GNU Emacs or GCC and say "I made that in the 1980's". Not necessarily the most recent version of it, but that hardly matters.
Gerald Sussman and Guy Steele can point to Scheme and say, "we made that".
John MacCarthy was able to point to Lisp and say "I made that", right to the day he died and we can continue to say it for him.
Make the right stuff; then you can bask in it for longer and be a kind of living saint to a few generations after you.
Re: On Getting Older in Tech
#340Earlier quoted context omitted.
I would even say they favor people who have been cramming algo-on-the-whiteboard type of questions. I mean, there are several businesses built around this (CtCI, leetcode, ...) I know some North American universities have adapted to the practice and are now preparing students, but I assume this is relatively new. My algo and DS classes weren't about cramming at all. Now to be fair, reasonable companies will focus on…
Since everyone knows what they're getting into with a tech interview, I don't see why it's such a bad metric. Many companies purposefully give you a rubric/criteria to study. It's a good way of measuring whether a candidate can take the time to learn/prepare a specific set of knowledge, and then work through problems in a way that includes the interviewer (ie. other devs if hired) in the steps to solve the problem.
It's often so broad that to really cover everything that might come up you've got to have time to make the studying a part-time job.
And even then you might get hit with one of those "you almost have to have seen the trick before" questions, like detecting a cycle in a broken linked-list with O(1) memory.