I started in this field in 1992. I've seen the coming and goings of many flash-in-the-pan technologies.

If you are a dev and are selling yourself on your skillset, ask yourself, "is this sustainable?" The answer is "no." A fifty-year-old brain simply does not absorb new technologies as fast as a 25-year-old-brain. If your plan is to continually adopt new cutting edge technologies in order to stay marketable, I politely submit you need to rethink your long term plan.

As an almost 50-year-old, I promise you that the world is not a gentle place for older devs. Plan your exit into management, a related field, or some other job altogether. If you expect to be a coder at age 50 you're going to be disappointed.

As for me, I jettisoned the "technical skill set" war decades ago. I do not sell myself on my technical skill set. I sell myself as the ultimate generalist. This comes with its own set of problems. However, it has allowed me to age more gracefully in my field, because I do not create the expectation that my primary value-added is code generation.

I'd like to simultaneously disagree and agree with you. If you were a 50 year old coder 10 years ago, then your only hope of remaining in the tech industry would be to add "Manager" to your job title. If you are a 50 year old coder today, that's still a sound direction to go, but increasingly becoming less necessary. If you'll be a 50 year old coder 10 years from now...I think you'll be ok.

Yes, at 50 you almost certainly cannot crank out as much code as you can at 20, but so what? As a coder it is important to understand that most problems in technology are not solved with more code, but less. That you will generate less code at 50 should be seen as a benefit. The advantage you have at 50 over someone who is fresh and new at 20 is that you can recognize that there is very little that's happened in the last 30 years that is genuinely new.

So, if you are 20, go ahead and spend your weekends on side projects learning the latest frameworks. As you continue to do this over the years and decades, shift to focusing more on patterns. By the time you reach 50, you might only generate half as much code as your younger colleagues, but you should be able to solve problems with a quarter of the code required, still making you twice as efficient as them.

When coding was new, code was the only metric by which to measure coders, and non-technical management types would view anyone who generated less code as less valuable. If you're not writing 500 lines of code a day, the argument goes, then you should be managing coders who can. But management and problem solving are not a completely overlapping skill set. Some engineers make good managers, but most do not.

Luckily, the more technically inclined individuals that populate the ranks of company management, the more this is being recognized and the more these companies are willing to hire the 50-year-old-coder-who-codes-less-but-solves-more-problems.

> If you were a 50 year old coder 10 years ago, then your only hope of remaining in the tech industry would be to add "Manager" to your job title.

People outside the startup bubble value delivering, regardless of age. Developers outside the startup bubble work consistently in a few areas of technology, they develop deep personal understandings with cookbook / solution / frameworks they personally authored enabling them to construct stable solutions that expertly address the problems being addressed.

Essentially, if you remain a "coder" and you use your brain at all above simply being a coder, you will become a software scientist. I never start anything from scratch, as I have about a dozen application skeletons ready for various specific purposes, plus similar libraries I wrote, plus a knowledge of several large commercial SDKs, and developer experience in several major FOSS applications. The work that I do now would give my 20 or 30 year old self a heart attack with the large scope, number of complex technologies, and the time frame I'm expected to deliver. But I've been writing code for 40 years now, and I may bitch at my tools, but it will deliver, it will be well written, fully documented, and so on because anything less just creates technical debt.

If you like writing code, start acting like a scientist about it. Few developers do, and in time you will accelerate away from your peers into a truly enjoyable professional space very few seem to occupy.

I have spent the bulk of my career working in larger, team-based environments. In my experience, being able to conform to cultural norms is essential to being a high-performing team leader or member.

Many, many teams have prejudices and / or litmus tests. For example, I've spent decades doing project management. I use Gannt charts. Why? Because they are the best way to communicate timeline expectations with stakeholders. I don't use them to manage the project. But I've encountered more than one Agile team that flat-out considers the use of these charts to be anathema. You might as well crap on the rug.

That's just one example. Obviously there are also the buzzword technologies. Here's an overgeneralization you might agree with: young developers tend to naturally gravitate towards newer, less proven tech. Us older developers naturally gravitate towards more mature, established tech. This creates a source of age-related friction.

Then there's the inability of others to grasp the applicability of your experience. For example in the 1990s I built a lot of actually awesome Lotus Notes/Domino applications. Now that's a technology that, if you mention it in various meetings, will get you laughed at. However, Domino was kind of the original "noSQL" / "BigTable" world, and it turns out that my application architecture experience in the Domino world translates meaningfully into these "newer" (ha!) database technologies. But try to tell that to team members.

So I guess my comments are orthogonal to yours. I agree with pretty much everything you write, but it leaves out the important social aspect.

I've had a project manager (very insightful guy) tell me something similar before. He said "as you get more experienced you'll (ideally) write less code and instead reuse code from libraries you've written in the past". I've always wondered how that works for someone? I'm assuming certain projects will have requirements where specific technologies would be used in the front-end and persistent layers depending on the kind of project you are building and so those wouldn't be as reusable but perhaps algorithms you've written before might be reusable on the computational side of things. Like perhaps if you had a library that handles very advanced moving cost calculations you could ideally use that same library in different software forms (mobile, web, desktop, command-line).

Edit: Git might be a good example of a library that can be reused a lot and used within many kinds of applications (IE: inside web app, within IDE, from command-line, desktop app, etc)

Smart devs know this and cultivate their personal repetoire.

For example in the veeeery first days of .NET I had the opportunity to build a nice internal application for a client. Of course I didn't have a .NET library - the tech was just coming out of beta - but Microsoft was nice enough to provide a bunch of "example code" and "starter sites" to give all us noobs some patterns we could work from - at least most of the skeleton of a working, database back-ended website with a working security model.

From this .NET project it was easy to find another, and now I had a complete .NET library with solutions to all kinds of problems - how to do doc management, how to solve image resizing problems in .NET, how to talk to all kinds of heterogeneous systems using .NET, how to implement webservices, etc. because I'd built these once. With that toolbox I could easily solve all kinds of other problems with only a little creative remodelling of the skeleton app.

Then in 2007 when I jumped into OSS I got to start an all-new library building solutions on the LAMP stack. By 2009 I had a nice little library built up again.

The pattern is amenable to any software tech. Every project builds from the last one, if you do it right.

Another example of a library would be libjpeg[1] for reading and writing the jpeg image format and dealing with all the different ways the format can be adjusted, which gets incorporated into many applications, for example ImageMagick[2].

Basically, a library consists of code that is intended to be reused by calling it from other code.

[0] It's astonishing how often this gets reinvented. Here are just Python libraries: https://pypi.python.org/pypi?%3Aaction=search&term=git

[1] https://en.wikipedia.org/wiki/Libjpeg

[2] https://en.wikipedia.org/wiki/ImageMagick

Wow, I'd only heard of libgit2 before. I can't believe how many git-related python packages there are. Yes git isn't a library, it's a program like you said, good catch

I started late (38, 41 this year) and I couldn't imagine jumping from Ruby to Rust to whatever new hotness arrives when it's clear that there are handful of technologies that go deep (enough) and that are being used to solve problems that require someone to be more than a coder or even a dev.

I'm in the connected-car space and the only question I'm asking myself right now is: will my current skill set (mostly iOS in Swift/Obj-C/C) allow me to build for the future of augemented reality in vehicles or will going down the path of C++ -only- allow me to grow as a "software scientist" (perhaps a third way...)? Honestly I don't know, but I do know that I won't/can't find out if I jump into every HN rabbit holes that opens.

I have no idea what higher level language in-vehicle AR will be written in, but C++ may be overkill, or a blind alley, or both.

You might be better off learning one or more of C, Go, Rust, Python, or Java (each has its own advantages and disadvantages) over C++.

Could you elaborate more on this?

This is precisely my argument as a generalist.

I may not write code as fast or even as elegantly as I once did, but I'm much, much better at "seeing around corners" to avoid problems, and I'm much more likely to "build the right thing" due to my very broad but not deep technical base. I do not fall into the trap of "when all you have is a hammer everything looks like a nail."

> there is very little that's happened in the last 30 years that is genuinely new

This is true, but try to convince your 20something peer group of it. They are all convinced that their technical skills are revolutionary.

I studied waterfall systems engineering in 1998. But at the same time they also taught "RAD" iterative waterfall, or the precursor to Agile. I ran with RAD, and made it mine, so I've been doing something very similar to "Agile" for two decades. However, I still think that Gannt charts and top-down planning have value.

Showing that shit to the wrong 20something developer is a great way to be excommunicated.

Of course they do. What you're seeing is a backlash to the way GANTT charts have been misapplied to projects that are less well defined, and to managers that ask for estimates and then are unpleasantly surprised when an estimate isn't entirely accurate.

Anyway, if you want to provide the same sort of value but present it in a different format, consider using a network diagram or a user story map[1].

[0] https://www.quora.com/What-are-the-best-alternatives-to-usin...

[1] https://www.scrumalliance.org/community/articles/2013/august...

You think I don't know this?

I think you missed the point :(

(As an aside, in my experience, network diagrams and user-story maps pale in comparison to Gantt charts, as they do not effectively communicate timeline expectations IMO.)

Of course, that is in part by design.

If you are delivering solution X that is just an instance of iteration Y of system Z with a few customer-specific tweaks, Agile methods will work just fine in combination with GANTT charts, and teams that are engaged regularly in that sort of work aren't too likely to object.

However, as soon as a task is a known unknown (that is, a well characterized problem with an understood though as-yet nonexistent solution) requiring new code that isn't just a variation on familar themes (ie. whatever is the equivalent of a CRUD web application for your industry), you start having to deal with uncertainty and risk (which humans are very bad at reasoning about). GANTT charts can make things worse because they foster a false sense of control (padding time estimates by x% for example feels like it helps, for example). And if anything in your critical path is a known unknown, your timeline expectations, however consensus-driven and reasonable as they may be, are likely to get smashed to smithereens, and all a GANTT chart is going to do is tell you when your carefully constructed schedule is starting to slip.

Throw unknown unkowns into the mix (from "we haven't yet figured out how to solve this" all the way to "are we even solving the right problem"), and timelines become entirely fictional.

I am not aware of any chart format that incorporates this sort of risk and uncertainty well (FogBugz for example, which incorporates probability and risk based on an estimator's past track record, basically just sticks that data into a chart's tooltips)

Now, if you are willing to mitigate these risks by basing your timeline around deadlines for handoffs with the understanding that what gets handed off is "best effort working system in available time" (in which case continuous integration/delivery is your best friend) that's a different matter, but that just isn't how most projects are concieved or managed. Yet.

BTW, related to all this is the conflict between feature-based and time-based approaches to software releases.

Given that you probably have much more experience than many of the people here, I'm going to assume that your advice is more sound than theirs.

Generalism is insurance, while specialism can be more profitable if the speciality you pick ends up in demand.

I've been worried sick trying to learn the things I see people commenting here or in hackernoon. I had the idea that by the time I graduate, these technologies will be trending or have a good market share.

With historical perspective, you can choose a "v1.0" or even a "v0.1" modern tool with confidence, when you have reason to believe that it's effectively "v255.0" in a lineage of discontinuous improvement that spans centuries.

[1] https://news.ycombinator.com/item?id=7952209

[2] https://news.ycombinator.com/item?id=8158385

There's a good chance that something else could be trending by the time you graduate. The media mood is very ephemeral. For employment purposes it's better to look at job ads statistics (annoyingly hard to search for phrase) and make your own inferences from there; anything currently popular will take a while to sink. As with any statistics, also ask yourself what is left out.

Stackoverflow dev survey is a reasonable starting point: http://stackoverflow.com/research/developer-survey-2016

Javascript frontend has been big for a while, but suffers from a tremendous amount of churn. Maybe the best solution here is what people used to do with music: find someone "cooler" than you and copy their taste.