I've been doing this a long time and it doesn't matter to me.

The newer stuff is most of the time just a variation on a theme that I've seen turnover three or four times since i've been doing this.

What older coders have that younger ones do not, is experience. This can often halve the workload on some projects. The older I get in this profession, the more results I get out of less and less code.

Also, let's not immediately fetishize the newer stuff. It is often a less well implemented retread of older technology. Seems like people have less patience for learning existing systems, so they just re-write some quick and dirty replacement and call it good.

Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years.

And this attitude is why older developers find it harder to get a job (I’m in my mid 40s myself).

What older coders have that younger ones do not, is experience. This can often halve the workload on some projects. The older I get in this profession, the more results I get out of less and less code.

I keep seeing this as an excuse for older developers who don’t want to keep up the date and stay marketable. Code is code. At some point you have to put lines in editor to make stuff work.

Also, let's not immediately fetishize the newer stuff. It is often a less well implemented retread of older technology. Seems like people have less patience for learning existing systems, so they just re-write some quick and dirty replacement and call it good. Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years.

The market can stay irrational longer than you can stay solvent.

My post above didn't mention it, but I also learn new stuff. And some of it is really useful.

I don't insist the client use my preferred technologies. I may recommend them, sure, but in the end I'll learn what I have to do get the job done.

This whole thread reminds me of a story:

A small town barber has been cutting hair for decades, and charging his customers a fair price.

One day a national chain opens a salon just across the street and advertises $10 haircuts.

A customer asks, "Aren't you worried they'll drive you out of business?"

The barber grabs a piece of cardboard, scribbles something on it quickly, and props it up in the window.

The sign reads: "We fix $10 haircuts."

I think the best business model for an older developer is to fix $10 haircuts. Seek out those kind of jobs that capitalize on your experience.

There are so many messes out there that if you can bill yourself as a cleanup guy, you'll never run out of clients.

That's pure gold. Not to say there haven't been advances--there certainly have been. But, there's also the issue of the shininess of new tech giving it undue cred, while simultaneously translating to an outsized denigration of the tech it purports to replace.

Frankly, a lot of these problems have been solved, and solved well.

Look at NoSQL as an example. There are certainly use cases for it, but then people went nuts, exclaiming things like "RDBMS must die" and touting no ACID transactions as a feature/benefit. Then, you get the trickle of reports that maybe NoSQL wasn't the best choice for this or that.

Finally, fast-forward to 2018 and you have announcements from MongoDB that they now support ACID transactions.

Many older coders have seen enough of these cycles, and have adopted a justifiably-cynical posture of "wait for it...".

Yet "Wait for it" usually turns out to be correct.

I think if you pick a concrete example of this phenomena (say, Java applets vs. WebAssembly) and you ask "so why didn't someone take Java Applets and update them, why do we need WebAssembly?", the answers to why this happens start to become more apparent. It's not so much that Java applets were good and then we decided they were unfashionable, as that Java applets were always kind of ugly and we eventually stopped tolerating them.

For examples from before say, 2000, say Turbo Pascal a lot of the answer is because the thing in question was a proprietary product so once the financially backed dev team stopped working on it users were forced to move on to something else. Other times it's because the thing was written for an 80's computer platform that no longer exists outside of emulation and retrocomputing collections. Sometimes it's that the graphical standards the original used were for hardware with very different capabilities and making the thing usefully work on a newer system would almost require a total rewrite anyway.

Even beyond all that, there's another problem: Software is fairly hard to do literature review for. If I want to know if a particular research idea has been done before, I can hop on Google Scholar and figure it out with a few hours of carefully constructed search queries. Doing the same thing for software is very difficult, especially because most products for the majority of the fields history were proprietary. As a consequence, we don't have our history available to analyze in any easily accessed form. The Internet Archive has been doing what they can to rectify this situation. (See: https://archive.org/details/BeyondCyberpunkMacintosh) Nonetheless, there are still serious problems in this area.

I'm a younger person (23) who shares your frustrations, but I don't think that you can really wag your finger at people when there are real barriers to what you're proposing.

I've been asking this exact question on various HN threads with WebAssembly announcements, and the answer is always one of "Applets are insecure" or "Java is insecure".

So I don't really follow your example here... whatever security model you want to have, it seems much more obvious to implement it for Java applets than to implement WebAssembly and then implement your preferred security model for WebAssembly. Why do you think we replaced applets with WebAssembly?

(It's kind of a leading question -- my experience as a browser user suggests that we stopped using applets, spent a while not having them, and then started working on WebAssembly. By that analysis, we never replaced applets with WebAssembly -- we replaced applets with nothing, and then replaced nothing with WebAssembly. That would tend to support the more crotchety answer of "people developed WebAssembly because they just forgot about applets".)

Now where webassembly comes in is a compilation target for anything to the browser. I had the sorry misfortune of working on a project that had an applet that interacted extensively with the host page. It was excruciating, the api's were not up to the task. At the time, before the canvas tag, that's the length we had to go to get "advanced" functionality into a page. Nowadays that could all be done with js (or X compiled to webassembly) and canvas element. Things evolve.

Before that, computer networking killed most of the running systems. And before those, any new computer would require all new software, so there was no continuation at all.

Things seem to be getting slower with time... maybe except on Javascript frameworks.

Only security and network seems stable. All are sand dune like.

This eliminates much of the proprietary lockin and portability problems you mention. I never was saying people should just keep using Delphi into the 21st century.

Also, my comments apply to broad categories of solutions not just software implementations in the narrow sense.

For example: I just replaced (had to for perf reasons) a NOSQL solution in one of our applications with MySQL.

Ironically, the application would actually scale better with NoSQL in theory, but the choices the developers made along the way (data modelling and API design) made it perform worse on the NoSQL DB than on MySQL.

The tactical solution, which fits our needs and the size of our user base, turned out to be to replace a new shiny thing, with an older technology. The benefit gained was more flexibility with queries, which in turn allowed us to speed things up significantly with little effort.

The previous team burned a lot of time learning the new NoSQL thing to then not get any benefit from it at all.

Creaky old software tools from the 70’s that are actually still in use have fought off decades of competitors that attempted to improve them.

I think the reason older coders don't "keep up" is because you have to lose ground first. If I want to adopt a new technology, I have to first learn how to handle problems I ALREADY KNOW HOW TO SOLVE with my current technologies. The better I am with solving the problems I encounter already, the more I will have to backpedal before I can go forward in a new tech. And while I definitely get better overall from learning a broader base of techs, over time there are definitely diminishing returns. The cost-benefit of learning something new vs spending that time either learning more of what I'm already in, or just solving any of the infinite things I want to get done is a balance that will slide more and more towards not bothering to learn new tech unless there's a real need.

Add in that this is an industry rife with Imposter Syndrome that DEFINITELY bites you in the face during any moment of struggling to "get" a new tech, and there are plenty of incentives against embracing new tech beyond just "I don't like change". (though that is definitely present - I'm a JS dev currently, so I'm well familiar with the dismissive and arrogant attitudes that can be tossed around).

So most of the issues I fix are due to mistakes I never would have made, because I already made them 10 or 20 years ago.

The worst part is that I no longer think in code, I think in piping data around and working functionally or declaratively because my brain is so apprehensive of side effects. I've found that younger programmers don't tend to realize how dangerous imperative programming (especially object-oriented programming) can be in the long term.

So what I really struggle with is motivation, because it can be so disheartening to not be listened to, or to work hard on an implementation only to have the elegance of its abstractions muddied beyond recognition by developers who don't take the time to understand them.

It's probably too late for me. I cling to a fantasy though of saving enough money that I can take a step back from programming and work on some of my own demo languages/frameworks that illustrate the flaws with the status quo. Because of handwaving and cargo culting, today's apps and websites encode so little core logic in proportion to lines of code that I'm hopeful I can make a niche for myself working at a higher level of abstraction and bidding less money on contracts someday. But it might just be a fantasy.

This post hit really close to home for me. It's especially depressing to be caught between these "pearls before swine" moments and Impostor Syndrome and for a while this made it very difficult for me to work up the courage to go to job interviews.

I am currently working somewhere that I genuinely love, as one of two senior engineers on a team of 7. I think I love it so much because I work with people who care about the quality of their work and respect the experience I bring to the table. They've been around long enough to see the cost of making the same mistakes I made 5 years ago, and have outgrown the "just ship it" mentality so many startups are born with and rewarded for. When you're trying to build a 100-year company, you value good engineering.

Most software jobs in California are at startups that are not trying to build a 100-year company, more like 100-week companies. In fact, most venture-funded startups are trying to have as short a lifespan as possible, because they exist to generate short-term returns through big-money exits instead of creating reliable revenue streams. This often actively disincentivizes high-quality engineering, and I think is a big reason why it can be so depressing to work with startups.

If a new technology is good or seems like it has potential I dig into it, and due to experience I can generally pick up something to the point of productivity in a day or two that takes junior developers weeks or months to reach. Or at a minimum know enough to figure out how to trouble shoot blocking bugs others can't solve by knowing where to look for solutions and what those solutions might entail. So to an extent I keep up to date in that I read the value propositions and reviews on new technologies so I know when they might be an appropriate tool in my toolbox to tackle some solution or other, on the flip side i'm not in a rush to pick up every flavor of the week framework or library that is more than likely to vanish with out a trace in 3-4 years.

Meanwhile outside of a persistent google recruiter whose been asking to do an onsite for the last year I've gotten dear john'd for something like 3 roles in the last month including one where i'm personal friends with the SVP of engineering. Is it missing keywords on my resume, my age, my career path, education, wth knows but unless the market has tanked it strongly differs from my experience a few years prior.

https://www.dropbox.com/s/haod1gpfjd723lg/Keith-Brings-Resum...

1. Objectives on resumes are useless fluff. Yours doesn’t add anything useful. It’s so vague, I couldn’t even tell what type of job you are looking for. Project management? Test? Software Development?

2. Your whole summary of skills sections is word soup. I would completely ignore it. Anyone can list technologies they touched once. It’s too unfocused. In your experience section list how you actually used those technologies. Why put you know how to use source control? That’s like listing you know how to type. Why list 8 different languages? Could you handle a deep technical dive in all eight?

3. In your work experience section, you listed your accomplishments, but I have no idea what technologies you used to accomplish anything. You didn’t list the languages you used in any of your jobs since 2007.

I wouldn’t call you in for an in person or a phone screen based on your resume. You claim that you can pick up a language in a day or two but I can’t tell from your resume where you feel technically in any specific area. Again, it looks like you think because you can figure out the syntax of a language you’ve avoided learning the ecosystem, the tooling, the frameworks etc.

You can ignore picking up popular frameworks but you won’t be competitive with people who have stayed up to date.

If you came into an interview saying that you could advise on a technology based on “what you read” and you said you decided not to actually put it into practice, that would be a red flag.

I’ve been working for 20 years. I at one point had an encyclopedic knowledge of C and C++, that’s nowhere on my resume, neither is VB6, Perl, or PHP. I don’t want a job in any of those languages and I don’t want to discuss them.

My resume for the last 8 years has been entirely focused on telling the story I want to tell. I’m a backend C# developer/architect with some front end Javascript experience.

Slowly it’s been morphing into an architect who specializes in “cloud native solutions” with AWS and I’ve added Python and Node and hopefully will be adding the $cool_kids front end stack over the next year or two.

I can deep dive into Elixir, Embedded C, C/C++, Java, C#, and PHP. I've used all of these on the job excluding perl, python and ruby in the last 5 years, and python and ruby i've used on side projects or for tutoring a friend on algorithmic programming for a evangelical role google asked her to do a follow up interview on. This is also not a comprehensive list of every language I've ever worked in or touched. I don't list Lisp, F#, Haskell, ActionScript, etc.

It probably makes sense to prune out outdated frameworks. And I should probably be updating this with some of the more recent frameworks i've worked with. But the thing is I'm bright, top 1% of the top 1% IQ, inability to write a compelling resume aside. I can pick up frameworks like candy, I read the manual. Further when I want to figure out how to do something that's not initially obvious or covered in the documentation I just read the source code or look it up, which is what everyone does but I do it better. That 2-3 day number includes getting a handle on libraries and frameworks being used on the project. I can pickup just syntax in the 10-90 minutes it takes to glance over existing code and documentation for most languages. For existing code I can usually follow the flow on first read with out knowing the language in advance. I learned C/C++ when I was 14 from reading intermediate level game programming books and reverse engineering it to figure out what the constructs do since there was no internet or other books handy, and the skill stuck with me.

So how do I stress that flexibility on my resume, or tell that story with out coming off as braggadocious?

P.s. do you mind if I ping you with a modified version in a few days that takes into account your suggestions?

But for the more generic comments that are germane to the topic....

Fair feed back. The Summary of Skills is mostly a Keyword hack for passive job hunting I can move it around.

You don’t need to move it around, you need to get rid of it. Your resume should express how you’ve used a technology/framework/language in a method that added business value to a company.

Besides, if you’re waiting for the job tooth fairy to show up and hand you a job because you list a bunch of keywords on your resume - you’re doing it wrong. At some point in your career you should have built a network of former coworkers, managers, and even good local recruiters that you can reach out to.

I can deep dive into Elixir, Embedded C, C/C++, Java, C#, and PHP. I've used all of these on the job excluding perl, python and ruby in the last 5 years, and python and ruby i've used on side projects or for tutoring a friend on algorithmic programming for a evangelical role google asked her to do a follow up interview on.

“Deep diving” is not knowing the syntax of a language. It is having enough experience to know the ecosystem, libraries, frameworks, pros and cons and to have written and being involved in large projects using the language. By definition, you can’t have been focused on five languages in five years. What exactly is your focus? Your resume doesn’t give a clue with what you’re good at.

Again, you come across as someone who thinks they are a special snowflake because you “learned C when you were 14”- you’re not. You’re posting in a forum with a lot of greybeards who are looking at this entire exchange just thinking “that’s cute”. I

And “knowing algorithms”, leetCode and how to invert a binary tree in Python puts you about on the experience level of a new grad.

So how do I stress that flexibility on my resume, or tell that story with out coming off as braggadocious?

From your responses you come across very much as an “expert beginner” (https://daedtech.com/how-developers-stop-learning-rise-of-th...).

I’m a reformed former dev lead, what you call “showing flexibility”, I would see as a jack of all trades and a master of none. If in 2019, you’re in any major metropolitan city in the US with years of experience as a software engineer and you’re not getting lots of hits - it’s you.

Your resume doesn’t (A) tell a coherent story with where you’ve been, which technologies you’ve used to bring business value or your focus and (B) where you are trying to go.

Learned C, Algebra and Calculus at 14 for what it's worth. I wrote a general purpose game GUI system, scrollbars, font system, picture in picture, keyboard and mouse handlers, etc. thousands of hours over the summer break between junior high and highschool. On my own, I mean little brown kid, whose mother dropped out of highschool and didn't know any one else involved in computer stuff, or access to people with math backgrounds own. I wasn't just writing hello world and simple console apps.

I know there are thousands of other developers on here with similar background, many who are much better than I am but I started off good. I took AP C/C++ freshman year of high school and was in the top of my class etc. Although I quit programming for a few years after getting refused entry into the specific program I wanted to attend in the college program my sophmore year of high school, and after the shift from dos to Win95, GameSDK which I just didn't enjoy working with as much.

I never got into the 31337 coding or algorithms side heavily, although I've been meaning to now that I'm down to a nice 40 hours a month work schedule. My focus has mostly been performance tuning high volume web sites, system/software architecture, and internal systems and tools. I'm a strong autodidact so I constantly go out of my way to learn new things and usually go out of my way to do things the hard way (e.g. investigate the best possible solution on a given platform/framework for a given problem instead of just going with the tech debt laden good enough solution based on what I already know), but I've been tied-up picking up IOT development, and Elixir/Phoenix for the last few years instead of electron or whatever is hip these days.

I'm currently the primary developer and architect on a multi million dollar IOT stack that includes a GAE Java with Objectify client api layer, Elixir/Phoenix + Mnesia, Riak and formerly Redis backend, and an Angular4/Bootstrap4 TypeScript admin page. I've had to help debug issues in the Objective C iphone client, and wrote some of the initial framework code and library wrappers for it to interface with some of the Elixir Libraries and to add a layer of indirection around the generated GAE apis. I maintain some node.js admin tools although I've migrated most of that over to elixir. I also have applied some patches to a weather forecast proxy service maintained by another developer in GO to enable better handling of null values and some other odds and ends and read through documentation and plenty of articles on here and elsewhere discussing the high level pros and cons of the language versus elixir to get a feel for it, and it's use cases although I don't know it well enough to list having only spent a few hours here and there with it. I could work in the language today if I had to but I don't know all of its quirks yet.

In addition to the above recent java/elixir and some node experience, I had to go in last minute and spend a good chunk of time rewriting my clients product line's 2017 firmware after the chinese hardware team failed to get the product to reliably function. Prior to that I had to help troubleshoot SSL connectivity and resolve a SSL cipher issue after another hardware team with much more experience than me in the area had failed to do so. These were my first real exposures to doing embedded system work, discounting designing and writing an x-mode GUI on the 386 when I was kid, and I objectively did incredibly well based on outcomes.

In addition to maintaining these Java, Elixir, Typescript (mostly pushed off on the junior dev as of the last year) Admin Page, and C Firmware projects I maintain a php rpg game which, because I wanted to dig into it I setup to run on a docker cluster a few years ago. Senginx with dynamic ip resolution (because it cost extra on vanilla nginx) routing to phpfpm, elixir and static containers, mysql on containers, postgres, jira/atlassian containers, with consul.io DNS for hooking things together with out loosing connectivity after rebooting. Here I don't mean I checked out some existing containers, I went in and figure out how to do a lot of things (should probably include that somewhere in my resume), so I could help give others advice on the stuff.

In the previous five years I've additionally helped trouble shoot some C# issues for JetzyApp although i'm starting to get a bit rusty. At Great nonprofits I helped push the change to bootstrap 3 and responsive design, updated parts of the code and API to run on laravel (because it looked more interesting than previous php frameworks I'd used and had good enough performance characteristics), improved the work flow by setting up production like vagrant developer sandboxes, and circle ci continuous deployment, etc.

At microsoft I took a crude poorly working batch processing script responsible for converting test data from one system and converted it into a reliable system service. I didn't need to make it a system service, It just seemed like the most reliable approach to get to the point it was supposed to be at, and I'd never written one so I wanted to dig into it.

I continuously go out of my way to learn new things, but I think I've been making the mistake of learning the things I find most interesting instead of what the market most values lately.

In school, many of us were use to being the smartest kid in the room. It’s just like being the star basketball player in high school and going to college and being surrounded by a dozen kids who were also the best in their high school.

For instance:

I know there are thousands of other developers on here with similar background, many who are much better than I am but I started off good. I took AP C/C++ freshman year of high school and was in the top of my class etc.

Bragging about being good at C based on how well you did in programming class is not saying too much. High school programming classes have historically been easy for anyone who was already a programming geek. Do you know how many of us wasted time on comp.lang.c on Usenet before the web even existed?

On any technical subject that’s posted here, you could have experts in the field that could put either of us to shame.

I don’t think I was a special snowflake, but by the time I was 14 (1988), I turned my nose up at any “high level” language because they were too slow and non performant for the little hobby projects I wanted to do on my 8 bit computers. I had already been doing assembly for 3 years. A lot of the grey beards around here can tell you much more impressive stories.

The whole point of this lecture is that your professional experience is no more impressive than plenty of people I’ve worked beside every day and certainly not any more impressive than people on HN.

I am not trying to discourage you. But as has been said by myself and others, you don’t have a consistent easy to follow resume that tells a story about what your area of expertise is, how you stand out from dozens of other applicants and I couldn’t tell where you would be a good fit from reading it.

So much this. I’m in my 40s and I am on my third pivot. The first was a C++ bit twiddler for 12 years. The second was an MS stack “enterprise developer” and now a third - JavaScript everywhere, $cool_kids front end stack, AWS, and the Docker ecosystem. It’s been about a year and it’s going to realistically take 2 to 3 more.

That's a good point. But you also need to consider it from the point of view of the person sitting across the table. You might be very productive solving a problem in COBOL (to exagerate the point), but they are much more comfortable in Python/Vue.js and don't want to burden themselves with legacy ways. Because they can find someone solving the problem in the stack they want.

I switched jobs recently and tried to adopt a zen-like attitude of beginners mind. It definitely helped...but I'd be lying if I said I never hit frustration points where I'm trying to go from A to C but I have to learn all about B when I don't WANT to care about B, I want to get to C. A good attitude helps, but I think the underlying reason is still true and is part of why experienced devs aren't adopting new tech at the rate of newer devs.

There's an awful lot of cyclical patterns in development, and an awful lot of convergence. HTML5 canvas for example is an awful lot like writing custom 2d graphics back in the day. Docker, Vagrant, etc. are neat but there was chroot, zones, vmware images, cygwin etc. before. A lot of hot new language features as well are just existing patterns from the functional discipline being tacked onto imperative languages and vice versa.

The fact that the constraints and reasons for adding generics to java or lambdas to c/c++ are different from the constraints and reasons for adding templating to c/c++ and lambdas to lisp doesnt mean that you can't go in if you understand one well and identify the pit falls or gotchas of newer implementations.

Is it really meaningful to go all in on learning how feature x from 2000 repurposed to solve solution y is all that fundamentally different? WebSockets are great, so was long polling and comet architecture, restful is great, so was SOAP, and their non web based COM messaging or just cross application communication ancestors.

There are a lot of pitfalls and unique characteristics to knew technologies but there is a lot more of new spins on old ideas, common underlying concepts and reinventing of the wheel.

You had me until that (j/k)(mostly)

> Is it really meaningful to go all in on learning how ....is all that fundamentally different?

That'd be the diminishing returns I mentioned up-thread: each iteration of learning a new way to do an old problem gives you less. I'd argue it's still more than 0, but we aren't comparing to zero, we're comparing to the opportunity cost.

That said, I think, as a generalization, experienced devs tend to be prematurely dismissive. That is, however, a personal opinion.

* stealth edit.

But if you don't do it, you're stuck on the local maximum of Hill X, and as it gradually erodes away, one day you realize that you don't have any lucrative jobs that you're qualified for, and you're so far away from what Tech Z is nowadays that you're effectively starting over from scratch, except that also you need to unlearn a bunch of stuff that's no longer true.

And this happens fast. If you try to coast for even, say, five years, so many of your skills will have turned to dust.

This is why the only real way to have a long-term career as a developer is to genuinely be interested in this stuff for its own sake. You need to want to go learn the latest new tech not just out of a cynical career calculus, but because you think it's genuinely cool and interesting and sounds fun. As long as that's true, I think you'll be able to be a valuable dev even as you get older; as soon as it stops being true, well, time to consider what's next for you.

Now, a lot of companies do over-engineer and cutting edge tools aren't necessary in a lot of cases, but that's a separate problem.

Learn things that will be important for forever. Life is a breath and then we are gone.

All they are is dust in the wind.

Within 10 years here I had encountered more than 10 different CPU architectures. I've lost count now, but it is probably at least a dozen. The same goes for OSes.

I'm pushing 40, and like reggae, acid jazz, electronic. I keep up to date (as far as one can) with tech, programming, cloud and the like.

It's not just me - it feels like a lot of older people around me don't match the old stereotypes. Older colleagues are learning Typescript, my grandmother reads erotica...

Youth culture is of course always changing, but older people are perhaps more liberal than they used to be, and don't feel like they need to behave a certain way any more more.

I'm proud of your grandmother, but TMI, man. TMI.

Any sane person with half a brain hates Electron.

(Not that there are any good alternatives, but still...)

I think it comes from having more and more empathy.

The more I live, the less I feel I can judge people and their choices. Even if it is to prefer Mongo over Postgres :-)

Can we please kill this myth already? That was extraordinary so during the era when social changes swept through society, but someone who spent their formative years during the 70s will hardly regard today's society anything else than an extension of the changes which took place then.

There are many different ways to act conservatively. Resistance to new ideas because "but we've always done it this way" is a lot more common with people whose definition of "always" stretches to five (maybe ten) years.

> Electron anyone?

Well, let's put it this way: Most ideas are bad. But you can't dismiss all ideas on that statistical ground, because then you would miss the really good ones.

Serious consideration: I wonder how the cost of "older programmers not being as up to date" compares to the cost of younger programmers too quickly adopting newer technologies.

If your bank has some COBOL systems running to keep accounts up to date, do you really want some team of pinheads to 'fix it' by porting it to python?

But you're not talking about distributions. You talk about the individuals you meet in interviews.

That's a different issue. New music really is garbage; the entire industry has changed over the last several decades. There's a reason so many younger people are listening to classic rock.

Can I ask where it is you live to see hordes of young people finding solace in classic rock (or any sort of purely guitar-based music) ? Except maybe in US rural communities where it's all about country music (always has been, always will be) those days are well and truly over. "Nobody wants an electric guitar anymore" : https://qz.com/1013293/rock-and-roll-is-dead-sales-of-fender...

Meanwhile electronic music has taken millenials by storm. Tomorrowland festival sold out nearly 400.000 tickets in 40 minutes a few weeks ago. Same kind of numbers every year for Electric Daisy Carnival in the US.

Never in history has there been so much quality music released every day in all genres, because musicians can now do so without the gatekeepers of the past, much like Youtube has shattered the TV networks.

The consequence of that is that it's all about fragmented niches and discovery can be challenging. But there is gem after gem in my Spotify "Weekly Discovery" playlist. There has never been a more exciting time to be a music lover !

This for example: http://www.hawaiianreggae.org/artists

Nice and mellow, lots of young new artists. It's a pretty good scene.

Ask the kids what they think about today's mainstream music. They will say it's amazing. Who do you think drives the charts?

Yes, yes, I know, you are or you know a couple youngsters who think anything newer than Pink Floyd is shit. And you think that the charts are not organic, they are "marketing", where the record label pay to get entry and rank.

If you look at my resume over the past 10 years and the tech I’ve used, it’s indistinguishable from younger developers.

But...it was popular in the late 90s, which corresponds to us mid-40 age people anyways.