As a software developer there is no such thing as being done with learning, ever.

80% of the tools and technologies I work with today didn't exist 10 years ago, and 80% of the tools and technologies you will be working with 10 years from now are just being invented right now.

There's apparently also no such thing as regular sleep ...

@fribbledom Conversely, I still use the tools I adopted 20+ years ago. I prototype in perl, write perl-inappropriate code in C, on my Unix system, using the same editor I've been using for the last 35 years. All the new-fangled tools I've seen do little more than lipstick the pig. Keeping to the same tools means I don't have to spend my time learning the latest whizzy toys; I can spend it all on actually getting work done.

@billblake2018 This.

I started with a toolset over 30 years ago (Unix).

It's changed and evolved, but a central core remains consistent and useful. Learning has been incremental and accretive.

Over the same period I've had exposure and use (often professional) of a wide range of other tech. That's .. often not aged so well.

I think mostly in terms of OOS, but that includes associated utilities, editors, interfaces, and development tools (scripting languages, compiled). CPM, DOS, Classic Mac, VMS (EDT, EVE, DCL, ...), MVS (TSO/ISPF, JCL), Windows (3.11, 95, XP, ...), OSX ....

As AlvinnToffler pointed out 50 years ago, the future will be relearning and unlearning, but if you pick your tools right you can minimise this.

Yes, infotech is an almost wholly constructed reality. But it's not uniformly without stable landmarks.


@dredmorbius @billblake2018 @fribbledom
The sad thing is, at least half of the new technologies people develop are reinventions of square wheels.

@wolf480pl @dredmorbius @fribbledom Just so. Except that they add pretty tulips on the corners of the wheels. :)


Sure, I still use C, C++, Java, PHP, and a bunch of the same CLI-tools that I already used 20 or even 25 years ago. Some of that accounts for the other 20%.

But it's also worth noting that most of these technologies have undergone their own evolution.

C++20 feels nothing like the C++ you know from the 90s. Linux and its system administration has changed a lot, and much of your knowledge from 15 years ago is useless now.

@fribbledom Yes, my tools have evolved. But the changes have not affected their fundamentals. I still use the coding standards I wrote some 30+ years ago for C, with only minor modifications--the language has not changed that much. I *don't* use C++; it provides no real value over C. As for Linux, I use Unix. And, though Unix has accumulated a lot of ignorable cruft in the last 35 years, the core--including admin--has not changed. I can, at need, use other tools, but mine let me be productive.

@billblake2018 I was taught assembler in my second year of school. It’s kind of like construction work with a toothpick for a tool.

@Sandra Assembly is largely useless, but when you need it, it's pretty much the only tool that will do the job. The real importance of assembly is that learning it allows you to understand what higher level languages are actually doing, which is important when it comes to optimization and debugging.

@billblake2018 I mean I usually recommend people learn two languages:

Assembly (especially some clean and RISCy assembly like ARM or MIPS), and Lisp (I like to recommend Scheme for this particular purpose because of the function namespace thing).

High level is awesome♥

@Sandra I used Scheme for awhile when I was doing AI. Must have been around 1991, because that's when I archived a copy of the Scheme spec. :) It was fun, but I'm not sure that I'd recommend Lisp to a general purpose programmer.

@fribbledom Even classic technologies like C get updated. C99, C11, C18, etc.


How many of these tools are simply re-implementation of existing concepts or tools


Not too many, really.

Things will evolve and build on each other. If they were merely re-implementations without any improvements, said technologies don't typically gain traction.

@fribbledom I take a minor issue with "no such thing as being done learning": you can only learn until your brain says "ENOUGH!". While I'm learning more things wrt hardware design and such, when it comes to software, for some reason, I'm not only not learning anything new (at least enough to support myself professionally), I'm actually regressing.

This is not by my choice. But, this is really happening.


Sounds like you're just more interested in hardware than software. You'll probably experience something similar in that area.

Learning often involves unlearning & forgetting things you previously learned. Don't worry, though, you'll never fill up your entire brain 🙂

@fribbledom The cultural drift can get very… concerning though.

I haven't figured out how to manage that in the context of continued learning yet, especially because “pushing habits and coordination points for environmental control” comes at you from a lot of angles nowadays, even moreso than the previous “for commercial gain” which at least seemed more limited in wanting access to the “spend money” part of your mind rather than the “ontology” part, and which was more legibly avoidable.

@fribbledom “One who codes using proprietary services should be careful lest ey thereby promote them to gatekeepers. And as you learn habits for SaaSS, the SaaSS learns your habits too.” Or something like that.

@fribbledom Imagine being in a discipline where learning compounds instead of adding up linearly.

@fribbledom A related principle I try to live by: no tech assumption should survive unchallenged longer than 5 years. Things like “Android sucks” or “Webpack is the bundler to use for JavaScript”. If that conclusion was reached before 2016 at the latest, it’s worth re-evaluating. Maybe it’s still true, but often times circumstances change dramatically in those few intervening years.

@fribbledom I was thinking about this today, and how much worse I made it my by jumping around so much

@fribbledom I have nothing against learning, but the constant churn is a problem and indicates that we don't really know what we're doing.

Put another way:
The tools we built 10 years ago turned out to be bad tools.
We threw them all out and made better ones.
In 10 years, we'll realise we fucked these ones up, too.

@fribbledom "80% of the tools and ... didn't exist 10 years ago" is not my experience by far.
Some technologies and concepts age like wine and allows your knowledge to build on itself for decades.
Some hyped high-churn stuff ages like fish and so does your knowledge.
We choose to learn but also learn to choose.

Sign in to participate in the conversation

The original server operated by the Mastodon gGmbH non-profit