Reflections of an “Old” Programmer

When learning something new, I find that this group implemented with $NEW_THING in a completely different way than that group did an implementation with the exact same $NEW_THING. I have a harder time understanding how the project is organized than I do grokking $NEW_THING. And when I ask "why not $THAT_THING instead?" I get blank stares, and amazement that someone solved the problem a decade ago.

Sure, I've seen a few paradigm shifts, but I don't think I've seen anything Truly New in Quite Some Time. Lots of NIH; lots of not knowing the existing landscape.

All that said, I hope we find tools that work for people. Remix however you need to for your own edification. Share your work. Let others contribute. Maybe one day we'll stumble on some Holy Grail that helps us understand sooner, be more productive, and generally make the world a better place.

But nothing's gonna leave me behind until I'm dead.

On the other hand, I think there is a bit too much fatalism in the article. Sometimes the kids are being stupid, and they need to be told so.

The vast majority of web apps could be built in 1/10th the code with server-side rendering and intercooler.js. All this client-side crap is wasted when you are trying to get text from computer A into data-store B and back again. It's the front-end equivalent of the J2EE debacle, but with better logos and more attractive people.

And people are starting to wake up[1][2]. It's up to us old guys to show the way back to the original simplicity of the web, incorporating the good ideas that have shown up along the way as well as all the good ideas[3] that have been forgotten. Yes, we'll be called dinosaurs, out of touch, and worse.

Well so what? We're 40 now. And one of the great, shocking at first, but great, things about that age is you begin to really, truly stop giving a fuck what other people think.

Besides, what else are we going to do?

[1] - https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...

[2] - https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

[3] - http://intercoolerjs.org/2016/01/18/rescuing-rest.html

I speak from enviable experience: game studio owner at 17, member of original 3D graphics research community during 80's, operating system team for 3DO and original PlayStation, team or lead on 36+ entertainment software titles (games), digital artist, developer & analyst for 9 VFX heavy major release feature films, developer/owner of the neural net driven 3D Avatar Store, and currently working in machine intelligence and facial recognition.

Our profession is purposefully amateur night every single day, as practically no one does their computational homework to know the landscape of computational solutions to whatever they are trying to solve today. Calling us "computer scientists" is a painful joke. "Code Monkeys" is much more accurate. The profession is building stuff, and that stuff is disposable crap 99% of the time. That does not make it any less valuable, but it does render it quite ridiculous the mental attitude of 90% of our profession.

Drop the attitude, write code freely knowing that it is disposable crap, and write tons of it. You'll get lazy and before you know it, you'll have boiled down whatever logic you do into a nice compact swiss army knife.

And the best part? Becuause you'd stepped off the hype train, you'll have more confidence and you'll land that job anyway. If they insist or require you to learn and know some new framework: so what? you're getting paid to do the same simply crap over again, just more slowly with their required dodad. Get paid. Go home and do what you enjoy. This is all a huge joke anyway.

The one thing in the programming world that is almost 100% applicable to almost every article like this ( and many other topics ) is..... it depends.

I'm fortunate in that for most all my career I have spanned many technologies from embedded systems to the latest crazes on the web. Mostly what becomes redundant is language syntax and framework. If your programming career is largely centered around these then you become redundant pretty quick (or super valuable when critical systems are built with them then need maintenance forever ).

Frameworks come and go so if you spend a lot of time creating solutions that shuffle data from a DB to a screen then shuffle data back into a DB.... then a majority of your programming skills will become redundant relatively quickly. ( maybe a half life of 4 years? ). But often when you are doing this, the real skill is translating what people want into software solutions, which is a timeless skill that has to be built over a number of projects.

If you work in highly algorithmic areas, then not a lot of your skills become redundant. Though you may find libraries evolve that solve problems that you had to painfully do from scratch. However that deep knowledge is important.

Design, the more complex a system is to engineer (that isn't provided to you via a framework), the more likely you will have skills that won't go redundant. Design knowledge is semi timeless. My books on cgi programming circa the mid nineties are next to useless, but my GOF Design Patterns book is still full of knowledge that anyone should still know. OOSC by Betrand Meyer is still full of relevant good ideas. My books on functional programming from the 80s are great. The Actor model which has its history in the 70s is getting appreciated by the cool kids using elixir/erlang

Skills in debugging are often timeless, not sure there's any technique I'd not use anymore. ( though putting logic probes on all the data and address lines of a CPU to find that the CPU has a bug in it's interrupt handling is not often needed now )

Maybe such a person would have chosen to learn ML as first programming language. If this person had then gone on to work in programming for 3 decades, and if you'd asked this person 30 years later, i.e. today, what's new in programming languages since ML, what might have been his answer?

Maybe something along the lines of: "To a good first approximation, there are three core novelties in mainstream sequential languages that are not in ML:

- Higher kinded types (Scala, Haskell).

- Monadic control of effects (Haskell).

- Affine types for unique ownership (Rust).

Could I be that somebody?

> Half of what a programmer knows will be useless in 10 years.

and the rest of the article seems to be based on it so it negates much of what is said.

Foundational knowledge does not decay. Knowing how to estimate the scalability of a given design never gets old. Knowing fundamental concurrency concepts never gets old. Knowing the fundamentals of logic programming and how backtracking works never gets old. Knowing how to set up an allocation problem as a mixed-integer program never gets old.

In short, there are many things that never get old. What does get old is the latest fad and trend. So ignore the fads and trends and learn the fundamentals.

I'm over fifty and just got back from presenting at a major conference. I've managed to say current through 35 years of embedded systems design (hardware and software) as well as a stretch of software-only business. It's really not that hard if you understand your job is to continually be learning. I must be doing it right because often those I'm teaching are half my age.

As an aside, I've done the management track and moved back to the technical track when I found it unfulfilling.

Great companies who have interesting projects will want to see what you've built in the past; the technology is just a tool. They will trust you to use the right tools for the job, and will respect you enough to let you pick those which you prefer.

For legacy systems, it's helpful to have some experience but it's not like you won't be able to be effective if you're good given sufficient ramp up time.

In my experience it's far better to hire the smart, motivated engineer who can actually get stuff done and has created high quality software before than someone who is an expert in a specific framework.

Also I avoid going to tech conferences about web stuff, unless it's a legitimately new technology. A new way to organize your code and conventions are not new technology, it's just some guy's opinionated way of doing things. And most of the talks are less about conveying useful information that will help you and more about the speaker's ego and vanity.

Exhibit A would be NoSQL. Little more than a rehash of the hierarchical and network (graph/pointer) databases popular in the 1950s before the ascent of relational databases, these systems enjoy increasing popularity despite few, if any, advantages over relational databases besides allowing 20-something hipster programmers to avoid learning SQL and the ins-and-outs of a particular relational database (like PostgreSQL) and allowing VC-backed tech companies to avoid paying senior developers who already possess that knowledge what they're actually worth.

If these new data stores were at last as reliable as the older relational databases they are supplanting, it wouldn't be so bad. But they aren't. Virtually all of them have been shown to be much less reliable and much more prone to data loss with MongoDB, one of the trendiest, also being one of the worst[1].

And these systems aren't even really new. They only appear that way to young developers with no sense of history. IBM's IMS, for example, is now 50-years-old, yet it has every bit as much a right to the label "NoSQL" as MongoDB does--and amusingly, it's even categorized as such on Wikipedia.[2]

1) https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-read...

2) https://en.wikipedia.org/wiki/IBM_Information_Management_Sys...

No, you get it. It's the people who get excited about stuff we tried and abandoned two decades ago that don't get it.

In fact, in many ways we've made things worse because not only does the sand keep shifting, there is now way too much sand. Young people come into the field and they want to make their mark. So we are constantly going through "next big thing" phases, some big like OOP, some smaller like React, only later to realize that what seemed so very interesting was really a lot of navel gazing and didn't really mater that much. It was just a choice, among many.

I can only hope one day some breakthrough in C.S. will get us past this "Cambrian Explosion" period and things will finally start to settle down. But I am not holding my breath. Instead I am learning Forth ;)

In his sig he says he likes to write about making decision, and not a word about intuition, how it builds up in you over years from that seemingly pointless going round in circles? Very little about how we improve in relationships with people (going from 0% skill for many of us), and accomplish even more by making others pull in right direction?

I have never wanted to do anything else than what I do. Differently, yes, but no farming / opening a restaurant or an art gallery. Maybe that is the real culprit?

Last thing, knowledge does not "afford increased measure of respect and compensation". Adding value, helping people, and solving their problem does. If you have this trail on your CV, maybe that long list of the technologies is less needed.

I'd suggest not building a house on sand, and learn the fundamentals of how computers and programming language works. Don't learn anything closed-source. It isn't worth the brainspace.

Make of that what you will.

As a 40+ programmer, who knows what becomes of those who move into management, I am seeing lots of my cohort falling back into actually making things, as a way to preserve our hard-won value.

This makes me happy. And you whippersnappers better watch yourselves ;)

My conclusion: there is no formula for staying relevant. Perhaps an understanding of the roots and rapid skill acquisition, but beyond that every second I spent learning a new framework just because has been a second wasted. By the timne I was somewhere it was poossibly relevant, it was already dead and replaced or I was too far ahead of the time and had to write my own.

Further, and sadly, after 50 some years in the biz, I still understand the insides of current SOC chips, and I shouldn't - no progress has been made in practical computing thoeretics at all. Lots of embellishment, lots of band-aids, nothing really different. Otherwise I would not be able to do this job.

Yes, really, brief this time. $0.01 instead of a full $.

The parallels include the explosion of new knowledge, or at least variations on the old knowledge, that a practitioner needs to keep up with. In programming it's languages and frameworks, in medicine it's discoveries (basic science), new drugs and techniques, and aspects of the regulatory environment. In either case a few years out of school/training it becomes daunting to keep up.

I should add here a particular peeve, the proliferation of abbreviations and acronyms is way out of control. It's nearly impossible to read an article without encountering an avalanche of incomprehensible ABBRs. What's worse, the same ABBR is often used to mean entirely different things one article to the next. Cross-field usage is a naturally incongruous extension of the confusion, though at times it's humorous.

What the article doesn't emphasize is the blizzard of details to keep up with is just one part of the experience. As years in the trenches becomes decades the value of "time in grade" becomes evident. The ability to size up the demands of a complex problem, to have a clear idea of where to enter the path of its management, and calm assurance growing out of having been down the road before are all won only by virtue of real experience.

Having done what I have for 40 years, it took me only 33 years to realize I didn't know what I was doing, and that's when I got really good at it. Therein is an essential wisdom that time and effort alone confer, and can't be gained in any other way.

I got lucky to have this advice 10 years ago. I did a Master degree on this area and my life changed, my software has high quality, evolve fast and I sleep nice every night with all the "chaos" under control. I can change languages and development processes fast and painless. I think the point is: you have to understand the abstract concepts of technology rather than languages or frameworks. As an example, if you understand Object Orientation, new languages will appear and disappear while your abstract concept will still be completely useful and applicable. If you study software engineering, it does'n matter if you will use scrum, RUP, you will get it fast because you already have all the base.

More so, the ability (and desire) to learn the latest/greatest has waned. I fear that we only have the ability to jam so much new knowledge into our heads. At some point, we must discard the old to make room for the new.

I'm just afraid I'm gonna delete the ability to control my bowels.

- solving the problem at hand.

- solving it in the quickest time possible

- the solution to the problem should not introduce new problems

I think for experienced programmer such as yourself the knowledge that you "lose" or "decays" don't actually become useless. I think they will serve you in making better future decisions like for example what you are saying now. Realizing whether things are 'fads' or 'foundational ideas' is a big asset for an experienced programmer.

The same way with doctors. Their tools are changing rapidly but the underlying concept is still the same. She may not know about all the new tools but she understands how a heart works, and because of that she can gauge if the new tool is just a 'fad' or will it change how things are done fundamentally.

I think every career path has this in some degree or another.

I do agree that keeping skill levels up across a long career is difficult. Maybe these memes come up because it's a convenient excuse not to put the effort in? It's very easy to get complacent if you are smart, get things done and have a comfortable home life. We have to train to get that brass ring, to stretch the analogy ;)

This is the point you think in a wrong direction. All of this Jobs need a basic knowledge (a developer need it too) and all auf this Jobs need tools or regulations to do the job.

A doctor need knowledge about new medics, new instruments. A good teacher teaches not the same way for 40 years. ...

React or whatever are tools. And yes, the most tools reinvent the wheel and this is not development specific, this is valid for many jobs.

But the thing is, I really like that I must always be learning. I just have that kind of brain that is attracted to learning new things, so for me this career has always been a natural fit.

In the last few years I learnt Meteor.js and built an issue tracker from scratch; I made several attempts at gaming projects using C++, C#, Swift, and others; I played Microcorruption and Cryptopals and Starfighter to learn a bunch about assembly, reverse engineering, crypto and security; I learnt Go and built a compiler with it; and right now my attention is moving towards lua to do some pico8 games. I did all this on the side of my boring corporate java developer job, and for no other reason than I wanted to learn new things. (OK, maybe I had big dreams of a startup with the issue tracker, but the others were purely for fun.)

I'm probably never going to be well known for any of those things, and I really haven't built up the chops to be considered an expert in any of them. But I'm content being a dilettante. Perhaps one day I'll get exhausted of exploring new things, but until then it's just fun to just dabble in whatever takes my fancy.

The time I spent mastering, adobe flex, javas struts framework, GWT and the likes. Could seem like wasted time. But in the larger scheme of things it just made me smarter. I know what worked for them and what didn't and that helps me understand the future frameworks better.

That's the key quote, I think. There seems to be far too much focus on 'programming knowledge' being about new frameworks, languages etc. That's just ephemera. Picking up React Native takes what, a couple of weeks? The basics are still the same, and still far more important.

I guess my conclusions are trivial. Many of us have amazing technical skill but our education and experience is not on par. It results in a lot of waste, of time and quality.

Perhaps concepts in programming change more rapidly than in other fields but technology ascends there too. For example I've heard dentists discuss new tech and methods they use as if it was a new web framework with different thinking.

Doctors need to learn about new methodologies all the time since science and technology discover new shit all the time and develop new methods to finding and fighting diseases for example. I think most people would be extremely disappointed if they visited a doctor that gave them medical advice that was 40-50 years old and wasn't updated with more modern medicine.

All technology is a means to an end. You don't have to learn the new tools to complete the job if you can have the same outcome and I think many times people are so afraid to become less relevant that they learn stuff they don't actually need.

If you really benefit from learning something, that's when you should learn it and use it.

Further on, the core of computer science has even better shelf life. It basically never expires.

Personally I split two things. The stuff that I need to learn just now to get my current work done, and the stuff that matters in the long term. The former can change quickly and I don't fuss about it. If It's the buzzwords and latest tech gimmicks or just a new technology I didn't use before, I learn as much as I need to and as much as sticks naturally over the course of my work, but I don't always actively try to retain it.

The latter part however is the real "gold". Once you know the core computer sciency stuff you can always build on that later on using whatever tools and technologies.

It's not that frightening to me, a mid-30's developer, at this point. I find the fundamentals are more important than the fads and it's relatively easy for me at this point to separate the wheat from the chaff. Is Redux or the Elm architecture good? Yes -- it's a left-fold over a state tree; great! I want that.

Are new things coming out constantly? Yes. Some of them are incremental improvements. That's a good feature to have. It means there are a horde of passionate people constantly improving the tooling and libraries available. I wish some of my preferred languages received even a fraction of the attention that JS gets.

We live in interesting times.

Interesting, I found this writing also, which is about new frontend frameworks: https://medium.com/@edemkumodzi/how-to-choose-a-javascript-f...

About How to choose a framework... and it suggest, if you already an experienced dev, who prefer OO patterns and you believe in serious computer science, you should use Ember.js. If you are a designer, Angular is good for you. However, if you are young and you don't have any experience, go with React, because it is easy to learn... like PHP back in time... I'm afraid React will be the new PHP, because we will see a full generation growing up with mixing logic with view, and they follow this kind of patterns... :)

He seems to ignore that his experience just paid off. It is not that his knowledge of JSP is out of date and not useful, it is that back in the day he learned the anti-pattern and can apply that now. Programming has the same long term advantages as any profession. Most of what I know after 20-some years is not any specific tech, but ways of doing things, recognizing good and bad habits, patterns, etc. The specific techs come and go, but the real knowledge transcends them all and builds on itself. His 3 stages graph shouldn't logarithmic but exponential.

I don't think knowing how a computer actually works will ever go out of fashion. Now there's Falcon framework for PHP for example, full of speedy functions written in C by smart people that actually knew what was happening beyond the stuff they typed into their .php files.

Obviously you may substitute any fashionable/unfashionable language pair in the above.

It would be interesting to see the graph of the careers stages with happiness overlaid.

Source: http://www.bennorthrop.com/Essays/2016/career-stages-program...

To the author: Hang in there, man! You're just feeling the time crunch, now that you have kids and other responsibilities. Based on your age, it would have been the mid-1990s when your professional career started. Back then, the economy was a lot better and outsourcing hadn't yet taken over at large companies. It's a little more dog-eat-dog economically, but your brain probably still works fine. Just take a breath and keep going.

Learning 30 different imperative languages (c, pascal, ada and descendants) might not add as much value as learning an imperative language, a functional language, a logic programming language, a language emphasizing concurrency (go, erlang), etc... meaning, learning paradigms and high level design constructs not syntax.

Try to stay in touch with new paradigms, instead of just new applications of them.

i.e. Life is all about reinventing your own wheel.

State management is the more important topic and the React tool chain has some great options for addressing it.

If by "worse", you mean more forgetful of the details of latest fads? Sure. But definitely not less able to put together solutions (Not if you've been spending your time doing that, of course)

When you're a kid and fresh into programming, everything you pick up has some magical power to do all sorts of awesome and cool stuff you've never done before. It's a grand adventure and you're just collecting all the trinkets you can on the way there. You look to other programmers to see which ones have the most potential. Whatever job comes along, you've already got the solution in your toolkit.

Over time you begin to realize that many, many problems have been solved hundreds of times. You note that there is an ecosystem around tools and frameworks, and as a developer? You are a market for lots of people who want you to use their stuff. That there's quite a bit of social signaling going on around which languages and tools people use. I'll never forget the first time I heard somebody say about another programmer "He's a nice guy, but he's just a VB programmer."

Actually he was one of the best programmers I knew at the time. He programmed in many different languages. It was just that for the work he was doing, VB was the right tool. But that's not the way it looked to the cool kids.

Know what's sad? It's sad when you look back 10 or 20 years and remember a ton of effort and pain you went through to fuck around with WhizBang 4.0 only to see it replaced by CoolStuff 0.5 -- and then you realize that CoolStuff really wasn't all that much of an improvement. And then you realize that CoolStuff is no longer cool. And then you think of the hundreds of thousands of manhours coders spent mastering all of that and comparing notes with each other. Looking down on those poor folks who never made the switch. Makes you kinda feel like an asshole.

I think you lose a lot of detail recovery ability as you get older, no doubt. I keep very little implementation detail active in my memory and only dig it back out as needed. But we are communicating on this wonderful little forum that, last I checked, was built using html tables! Yikes! And using a language that's a derivative of LISP! Yet somehow the world keeps spinning around.

I have no doubt that as you finally smarten up and focus on the important stuff that you will appear to other, perhaps younger programmers as losing it. I just don't think they know what the hell they're talking about.

Meh.

And the same is true of programming. There are still variables, arrays, syntax errors, IDEs and so forth - the underlying algorithms don't change that much. Lawyers and accountants have to keep up to date to keep their credentials, and doctors almost always do (but not actually always - just like some programmers don't update their skills). Fads come and go in teaching as well.

I know less about plumbers, but there are few white-collar professionals where you don't have to keep on top of things throughout your career. From architects to engineers to social workers to pilots to biologists to meteorologists to managers, things change in your profession and you need to adapt. It's just that usually those changes don't have the ridiculous levels of hype and fanfare that they have in our bubble (management being an exception here as well, lest I draw the wrath of a six-sigma black belt!)