Live data from Hacker News

On Getting Older in Tech

corgibytes.com

331–340 of 440 posts

Re: On Getting Older in Tech

#331
post #109

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…

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

#332

48 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…

I like this aspect of software development. I've not seen the permanence and ephemeral aspects of things so cleanly expressed in any other field. The fundamentals don't change but the software artifacts expressing those fundamentals do. Not sure why I enjoy that dichotomy but it tickles my brain the right way.

Re: On Getting Older in Tech

#334
post #109

Earlier 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.

What other fields operate like that? Doctors, lawyers, accountants, etc all get CPD on the company's time and dime.

Re: On Getting Older in Tech

#335
post #212

There'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…

COBOL has its limitations for sure, but I am an oddball because I love it. I took it for two semesters as part of my master's degree and am keeping an eye out for COBOL jobs by me. I would love to work in COBOL day in and day out.

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

#336

Earlier 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?

not that i can recall. why do you ask?

Re: On Getting Older in Tech

#337
FWIW, I'm still on the earlier side of my career (though certainly not just starting out) and the direction of my learning has been away from fads and towards older, more established technologies. Erlang, Unix, etc. have all been around for many years, and while they do receive active development are still pretty well established and based off of sound engineering principles.

I 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
post #44

> 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…

Actually the average age of software engineers at Google is much higher than 30.[1] It's the non SWEs that being the average down. The cited source in that article lists average ages for all employees, not just technical ones. This is unfortunately an overlooked distinction when writing about the industry.

[1] source: I work for Google.

Re: On Getting Older in Tech

#339

48 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…

Torvalds, 46, can point to Linux and say "I made that, over half a lifetime ago".

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

#340

Earlier 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.

> 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 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.

Post reply on HN