Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Getting Older in Tech

corgibytes.com

Post reply on HN
Print view View original

221–230 of 440 posts

Re: On Getting Older in Tech

#221

Post by AlexCoventry »

timemachiner wrote: post #215

I'll probably be ~36 by the time I complete a PhD in CS. Should I be OK in terms of finding jobs at hip companies upon graduation (big 4, etc)? My areas of interest is in ML, algorithms but I'm completely OK with normal software development positions. Reason I'm older is I decided I had a passion for it in my late 20s / wanted to do research, but had to go back to school to take classes before enrolling into a PhD. H…

My experience has been that if you've got the chops, you've got no worries at all. Also, fashion is fickle, but right now you'll have people beating down your door to hire you if you're skilled with ML and algorithms.

I am in my 40s.

Re: On Getting Older in Tech

#222

Post by JustSomeNobody »

I think the industry you choose matters. I have done work in the Medical and Transportation industries and the devs there seem to be older. I tend to gravitate towards development where the code simply has to work correctly. This means proven technologies are used as opposed to the new and shiny.

Re: On Getting Older in Tech

#223

Post by larrik »

ash wrote: post #114

Article mentions "RPG" many times: "RPG back-end", "RPG developer". For those who wonder what it it (like me), it is not a "Role Playing Game", it is IBM RPG language: https://en.wikipedia.org/wiki/IBM_RPG

I spent my first 5 years out of college as an RPG developer, and even I was like "wait, can he mean THAT RPG?" I'm not even old, I started that job in 2005!

Re: On Getting Older in Tech

#224

Post by blub »

DanBC wrote: post #185
blub wrote: post #104

I don't find this post inspiring, I find it sad. It's partly self-encouragment, part PR. The fact that it even exists is proof that the author is facing some issues, no matter how confident they would like to appear. That recipe to stay current looks tiresome. Listen to two podcasts, two webcasts, subscribe to four magazines, teach courses, go to one conference per year, blog regularly, read blogs, follow the latest…

> And why is it that most older people answering on these threads are so passionate about learning ...because older people are told all the time , even on HN, that they're too old to learn and that they don't keep up with technology. It's not surprising that they pre-empt these doubts by saying what they do to keep learning. > Why not have an honest conversation What's the honest conversation?

Well, an honest conversation would involve acting like a regular human, and not a lean mean learning machine ready to go head to head with any younger developer.

Because most people want to live their lives, not jump on a learning threadmill.

Re: On Getting Older in Tech

#225

Post by hocuspocus »

Eridrus wrote: post #207
rifung wrote: 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…

I don't know your definitions of older/younger, but I interviewed at Google NYC recently, and my perception was that most people were in their 30s, with a few older and much older folks. Maybe a factor of the teams I was talking to, but it was clearly an older bunch compared to FB.

I can't speak for NYC but this is also my experience at Google Zurich and London.

Re: On Getting Older in Tech

#226

Post by fulafel »

lisper wrote: post #74
fulafel wrote: post #70

Earlier quoted context omitted.

Isn't there a good big comnunity in Clojure now?

Depends on what you count as "big". If you look at languages used on github, for example: http://githut.info Clojure is doing OK (better than Common Lisp), but not great (worse than Haskell and Emacs lisp).

I bet more people are getting paid to do Clojure work on production systems than Haskell or Emacs lisp.

That's a really nice web site. It took me a moment to realize it's showing quarterly data (sadly last updated in 2014), and that the ranking is based on the first metric ("number of active repositories").

Re: On Getting Older in Tech

#227

Post by nsxwolf »

neeleshs wrote: post #77
soham wrote: post #71

Elephant in the room, IMHO, is the technical interview process. In software engineering roles at big/desirable/fast-growing companies, the interview process favors faster (by definition, younger) minds. Both young and old are put thru the same/similar coding interviews at many of these places, and often faster coders are younger, and get the job. You can't fix ageism without fixing the interview process. Being jovial…

Why do you think often faster coders are younger? With many more tricks up their sleeves, a more experienced coder will be faster. Or are you saying compared to literally older people, but not experienced?

Young coders can code that 10,000 line bad idea they had really fast, while older ones can recognize that a problem isn't new and avoid the 10,000 lines altogether.

Re: On Getting Older in Tech

#228

Post by blub »

IshKebab wrote: post #119
blub wrote: post #104

I don't find this post inspiring, I find it sad. It's partly self-encouragment, part PR. The fact that it even exists is proof that the author is facing some issues, no matter how confident they would like to appear. That recipe to stay current looks tiresome. Listen to two podcasts, two webcasts, subscribe to four magazines, teach courses, go to one conference per year, blog regularly, read blogs, follow the latest…

> And why is it that most older people answering on these threads are so passionate about learning and about new technologies and the latest and greatest javascript frameworks. Do they really enjoy having such ephemeral knowledge and basically competing with anyone that's finished a bootcamp or not even that? Nobody enjoys having their hard-earned knowledge become obsolete (hence the "X11/bash/sysvinit/etc were good…

I am doing just that (but Go and Rust don't belong on that list). However, if a lot of people are doing things radically differently it starts limiting my options too.

Re: On Getting Older in Tech

#229

Post by delegate »

qznc wrote: post #176
delegate wrote: post #156

Take acid and go to crazy festivals if you want to stay young. No really, do it once at least. You need to bathe in youth from time to time in order to experience it - it's fantastic. Of course you need to keep up to date, try to use your wisdom to understand which technology/language is going to survive the test of time. For example, C/C++ is going to stick around for a while; make sure you're up to date (C++ 14 and…

> use your wisdom to understand which technology/language is going to survive the test of time I usually use statistics. If you select a random point on the lifetime of something. There is a 50% chance, that you are closer to the middle then either start or end. Thus: Always assume you are roughly in the middle of the lifetime. In other words, if some technology is only one year old, assume it is dead in another year…

Nice piece of wisdom right there, thank you!

Re: On Getting Older in Tech

#230

Post by dagw »

kornish wrote: post #38
vacri wrote: post #19

Earlier quoted context omitted.

I find that - very broadly speaking - old guns are better at strategy and young guns are better at tactics. The energy and interest of the young lead them to find the local maxima more readily, and the experience of the old help you find the real maxima rather than the local. Or put another way, young'uns will get you out of the rabbit-hole more quickly, but old'uns will take you down fewer rabbit-holes. Both mindset…

Would you mind expanding a little bit more, from your perspective, on what falls into tactics and what falls into strategy?

I've seen several examples where the younger developer (often me) comes up with some really clever code to make a certain thing run really fast, and the older developer coming along and pointing out that my underlying premise is wrong.
Post reply on HN