Why age in software is bullshit | Hacker News Reader

Why age in software is bullshit

medium.com

31 pointsmoonlighter18 comments

I think the author misses what is being said by the individuals making the 'age' comment.

I'm in my 20s and I've said this comment before plenty but it isn't in the context of someone being too old to ship code but instead the fact that as we age we usually take on additional commitments, responsibilities, etc.

All these extra factors often limit the amount of time that most people have to dedicate to coding.

So what you're saying is basically you have "no life", and you are willing to dedicate your waking hours to your job (or playing Pokemon Go). Been there done that, found out the hard way that it usually ends in a way that is not so advantageous to you. I am still writing code at 58 because it's what I like to do. I have founded, managed and CTO'ed. But when I code I feel better during the day, I feel like I have accomplished more, and I sleep a lot better then when I herded cats. Retirement is a slow death... I am going to be coding until I die, at least 30 more years!

mostly "ditto". 54.

Oh what a crock of nonsense! The best thing you can do is to stop reading cliches (even by the so called famous types) and ask those so called older folks with additional commitments, responsibilities et al, what life is really like.

I'm in my 30s and have what you call "more responsibilities" and can tell you that I now value my time more, get more s--t done in less time and overall are more productive than in my 20s when I had none of those responsibilities.

Its usually not the age. But its common for people effected to think that they are being discriminated because of their age.

There is a tendency for a lot of people to hang on to tools and ideas that worked for them in the past. e.g someone who comes from a relational world, finds it very hard to get used to nosql unless their boss gives them no choice.

The irony I find in this depiction is the "hot new" stuff in today's ecosystem is very often stuff that's already existed for 2-3 decades in some less trendy form, given a new brand identity (complete with cookie-cutter .io website), and grows a Twitter & conference clique around it as though it's being discovered for the first time.

"Reactive", "Streams", "Containers", "NoSQL", "Big Data", "Blockchain", the list goes on. I work, or have recently worked, in each of those problem domains to a non-trivial extent, so I'm absolutely no stranger to the leading edge of the marketplace, but I still find it amusing how gaga people get over the new branding, and I'm even more amused how indignant people get when you show them work from 15-20 years ago that was materially similar under the "hot new" brand name it had back then.

Sure the show might be new to a lot of people, but to a lot of other people it's just re-runs that have been in syndication for a long time with tired plot devices and predictable story arcs.

Reluctance to jump on the bandwagon may very well be rooted in the scar tissue built up the last time around, not purely reticence to try something new. They may just be withholding their enthusiasm until they try can something actually new.

What is your analogue to bitcoin from a decade ago ? Merkel trees are old (1979), Hashcash goes back to 1997 https://en.m.wikipedia.org/wiki/Hashcash But bitcoin is not just a rebranding of a combination of hashcash, merk trees, forth, pgp, BitTorrent.

Also what is the analogue to reactive in the past ? The main reason for reactive is different screen sizes and orientation of handheld devices. What similar problem would reactive have solved 2 decades ago ? There are a couple of references from 2001 and 2004 https://en.m.wikipedia.org/wiki/Responsive_web_design , but really there wasn't a practical common use case before the iPhone in 2007 and ipad in 2010.

"Blockchain", not bitcoin, and "Blockchain" is quite literally a specific application of Merkle Trees and Merkle Proofs, and they've been used almost exactly like this in payments clearing & settlement + dispute systems for tranlog coherency checks and resolution for a long time.

"Reactive", as in http://www.reactivemanifesto.org/, and it's manifestations in various Akka projects like http://www.reactive-streams.org/. Reading the "manifesto" reads like somebody going to really, really extensive lengths to talk about Erlang without actually saying "Erlang" and that's been around publicly, along with its runtime semantics, since 1998.

When you work in a team with other people, certain collaboration skills are useful and necessary. I am god and have seen it all and i am going to reject other's ideas is not a productive attitude. Cost conscious managers are going to ask tough questions like if you are so good why are you competing with a 3 years experience software dev?

Being reluctant to readily abandon "tools and ideas that worked for them in the past" in favor of adopting HN-buzzword-compliant technologies on flimsy pretext being presented by earnest people who nonetheless often have limited experience with the thing they're proffering and more often zero awareness of the similar fads that came before it is really, really far away from, "I am god. I've seen it all. I reject it all!"

Cost (dev, support, maintenance, etc.) conscious managers are going to ask tough questions like, "Why would we use Node.js and MongoDB to build a financial transaction processing switch?" and "Why would we deploy a Hadoop cluster to do offline analysis of only 4GB-5GB of transient data per day?" and "Why would we front Elasticsearch with Kafka when our write-load is well below what a small ES cluster can handle and the data is non-critical?" and "Why would we deploy Mesos for infrastructure of <20 machines that has no dynamic multi-machine scheduling needs and never will?"

There's an almost never-ending barrage of stuff like that I contend with. Which is fine. It's part of my job, and despite hard-earned cynicism... myself and my teams have still managed to build all manner of things with all manner of relatively esoteric tech.

Erlang, Rust, Elixir, Scala, Cassandra, Riak, HBase, Kafka, Storm, Spark, Ansible, Cobbler, Packer, Consul, Vault, LING, Rumprun.

No stranger here to including feedback and ideas to determine the best tools for the job that needs doing and their associated costs (dev, support, maintenance, etc.). I'm also no stranger to the flights of fancy that beset engineers who end up inventing reasons or overstate their problem space in attempts to justify using new shiny things.

Take it easy mate. Cheers!

Everything you said needs to be judged based on the context. There is also a case of tallest tree grabbing all the sunlight and overshadowing other potential talent.

If you want to build a strong resilient team you should allow your devs to fail.

For your every valid example I can show you terrible choices people make in realworld because someone with a lot of experience told this was the perfect thing to do and they resisted changes.

Ofcourse you have to exercise sound judgement in everyday life. I have seen managers who are reluctant to hire rockstars simply because they don't need them.

> There is a tendency for a lot of people to hang on to tools and ideas that worked for them in the past. e.g someone who comes from a relational world, finds it very hard to get used to nosql unless their boss gives them no choice.

I work on a system at my dayjob that was "NoSQL" in the 1980s and is functionally similar to modern document-databases.

So...yeah. I'm sorry but the idea these things are "new" is the perception of someone who hasn't touched older technologies.

Yeah... I was just looking at http://leaningtech.com/cheerp/ and wondering why everyone is trying to tack on static typing to JavaScript when they could just use C++...

It might be that I am beyond redemption at this point.

Good luck getting that C++ code to run in your browser, for starters...

C++ in your browser today? Check. [1]

C++ in your browser tomorrow? Check. [2]

[1] http://kripken.github.io/emscripten-site/

[2] https://github.com/WebAssembly/design/blob/master/CAndC++.md

The link I had in my comment was a C++ compiler for the browser. DOM and everything.

I'd say the problem (which may be correlated with age) starts when we repeat "I know" too much and "I'm learning" too little.

I don't think it's surprising that older people have the ability to be so prolific. What's surprising is that they still have the patience to put up with all of the BS that goes along with writing software. When you hit the ten thousandth broken library API or build-system idiosyncracy of your career, it's tempting to scream "Enough!" and retire to farm fish or something. Ditto for dealing with well-meaning users demanding features to support an impossible use case, or not-so-well-meaning haters trashing you on Twitter/HN/Reddit. If you can only code, on what you want the way you want, without caring even one little bit if anybody uses or likes it, that might still be fun. Otherwise, all that other stuff gets pretty old, and that's more of a problem than you getting old. As you see your friends starting to pull back or retire altogether, and you realize that you could do the same, the idea gets pretty tempting even if you love to code.

BTW, since somebody's likely to ask, I'm 51.

Reply on news.ycombinator.com