It's not terrible advice. You mentioned SICP, funny thing is, years ago when I put someone on to SICP, next thing you know in our production code we started getting these weird ass recursive functions..... Also had similar issues with Design Patterns, all kinds of overly engineered class structures started popping up. On the side of ALAN, I used to work with guy who did a lot of machine vision research, he coded everything the way he knew how for years, and he was super productive doing it. I didn't really like the code. But he got stuff done. Having said all that, learning stuff is still good, practicing stuff on non critical code is the next step.

Taking some lessons from BJJ ( Brazillian Jiujitsu ), when you compete, you go in with your A game, the things you have practiced, the things you have made work over and over again, your high percentage moves. Over time, you add things into your A game as you gain experience in making those techniques work. You may occassionally find yourself in an odd situation which some "new" technique is screaming to be used and you might try it out. But usually, when you encounter a situation you don't really know, you start working at getting the problem to change to something you do know, then throw your A game at it.

I think programmers should understand what their A game is.

I would gather though that the best way to learn new things is to apply them and use them in the code. That's the only way to get seasoned and find out when and where to use these things (like design patterns, recursive functions, etc).

It sucks when this is happening to a production system, and then maybe it's a mentoring & leadership problem instead.

You lost me at "next thing you know in our production code we started getting these weird ass recursive functions...". I don't mean to be mean, but recursion is pretty fundamental to a lot of algorithms, and it sounds like the SICP coder was just writing stuff more advanced than you were comfortable with.

Anything that is more advanced than necessary is too advanced to be comfortable with.

think you kind of missed what I was saying, I was the one recommending, having already done a bunch of functional programming, and thought SICP was a nice intro ( at the time ) to functional programming. But they didn't quite get it and their code was a weird mish mash of OO and weird uses of recursion with badly thought out (stateful ) functions.

Might also be an inappropriate application of recursion in a language where loops are more common. I've seen people who learn new stuff go overboard with clever code in production that is less readable for their peers.

Recursion shouldn't even be considered advanced though, just like classes and first class functions. I'm all for making code as boring as possible, but to me understanding at least these concepts is a requirement of entering the profession of software development.

Sometimes recursion is the good solution, For example a back-tracking solution is more simple with recursion than without it.

But doesn't putting somebody on SICP in the hopes of helping them learn functional programming (is that SICP's concern?) sound to you as... aspirational advice? The book is as famous as it is infamous.

the point is more that anything you learn, you often want to try out the new toys. But those toys aren't your A game and we haven't learnt the lessons yet of applying things to achieve real results, so often that can skew our productivity. Whole new frameworks can leave us completely incapacitated when we hit the edges of what is commonly done until we either dig through things ourselves or find someone to answer our questions.

If you read what he actually wrote, he obviously means "Avoid Learning Anything Newly Invented/Created" not "Avoid Learning Things That Are New To You". In that context, SICP, Java, and Linux hardly count as new...

That's a charitable interpretation and good advice, but they specifically say "Only learn something new when forced" and give two examples 25 years apart. It certainly sounds like they aren't learning technology as it matures but literally as they are forced.

I don't know why so many people here assume that learning something ages ago and sticking with it is mutually exclusive to learning anything tangential. Those two examples are programming languages and their accompanying ecosystems, not switching those for 30 odd years is not an indicator of having stopped learning anything.

"All new ideas are bad" seems equally bad as advice.

I don’t think it’s that “all new ideas are bad” but more that it’s not always efficient to be the guinea pig. I have a pharmacist friend who says he tries to avoid taking any medication the first five years it’s on the market. Not because he thinks it’s bad but because he’s seen enough new medication to know that it takes about that long to really get a good picture of the risks and interactions.

"Wait for technologies to mature" sounds like a great heuristic for people who need to build things that actually work.

And for people who have better things to do than relearn a new JS framework every 2 years.

I dont mean to be offensive, but usually those things take like a month to learn if you're bad at it. People talk about that grind like it's anything other than the most basic of gestures for tracking the rapidly moving target of browser technology.

If this is what we mean by, "being a bad programmer" I guess I get it now. A refusal to actually track the state of the industry, instead being told by employers what matters.

> A refusal to actually track the state of the industry, instead being told by employers what matters.

Yeeees... so instead of being "told" by your employers, you're "told" by the hype-train? How exactly is this better?

Being fed up of the constant churn in JS frameworks is an entirely valid position.

Sure, maybe it only takes a month to learn the latest framework. Maybe it only takes a couple of weeks. But maybe I'd rather spend those 2 weeks doing something else that I consider to be more valuable (it's called opportunity cost).

And what about all the gotchas and quirks that every framework has? The pathological performance edge-cases, and suchlike? The ones you only discover after weeks and months of in-depth use? I'll have to learn a whole new set of those.

And what about my "legacy" codebase that used the last framework du jour. Do I just ignore it? Do I convert it? Hmm. Wonder how long that will take, and what else I could be doing with that time.

Maybe you enjoy the churn: endlessly learning useless knowledge that will be of no value to you in a few short years because it's no longer trendy. Lucky you. For me it got boring, because I've got stuff to build.

> Yeeees... so instead of being "told" by your employers, you're "told" by the hype-train? How exactly is this better?

Because occasionally our peers are right? Do you really have so little respect for everyone in the industry around you that every new piece of tech that comes along, you just assume it is a mass of incompetence and marketing?

A diversity of perspectives, ideas and approaches is a fertile ground for personal growth. There are never any shortages of such hype trains.

And at least they're made by fellow software engineers. Not, you know, corporate hiring comittees.

> And what about all the gotchas and quirks that every framework has? The pathological performance edge-cases, and suchlike? The ones you only discover after weeks and months of in-depth use? I'll have to learn a whole new set of those.

Getting domain specific, you'd be doing that anyways because of how rapidly browsers are growing and changing.

> And what about my "legacy" codebase that used the last framework du jour. Do I just ignore it? Do I convert it? Hmm. Wonder how long that will take, and what else I could be doing with that time.

> Maybe you enjoy the churn: endlessly learning useless knowledge that will be of no value to you in a few short years because it's no longer trendy. Lucky you.

Why is it that the value of software is defined by if it is trendy 5 years later? That's a conflation of concerns I can't follow.

> For me it got boring, because I've got stuff to build.

For me, squatting on one stagnant pile of never-really-that-good technology building the same boring things over and over again at the behest of others is equally boring.

You suggest all the frameworks are poorly designed hype, but then decide you want to take an arbitrary moment in time (when you showed up, that fated day) and freeze everything there.

That reasoning seems unconvincing.

If you're unnecessarily spending a month a year on platform churn, that's nearly 10% loss of productivity right there. Doesn't seem like a good choice to me, unless you're genuinely gaining something important.

This was about learning, not re-engineering. Why are you conflating the two.

Lest we forget, the opening post advised you never learn anything new.

You can still learn the latest technologies so that you know what's potentially coming down the pipeline, while using the best mature tools for your bread and butter day to day work.

It also sounds like an excellent recipie for being utterly beholden to every industry trend that gains critical mass despite numerous examples of how sub-optimal it is.

It's a strategy for a big corporate hiring committee, not an individual worker.

Of course the actual successful software companies "build the next proven thing" so even for them, this "wait and see" strategy is clearly not effective.

I didn't get that from the article. It's more like: most of the new tech won't stick and if you aren't smart enough to discern what will stick and what not, then focus on learning tech that has already matured and been adopted. Remember, the advice is meant for programmers who aren't that good.

I think it's a tongue-in-cheek way of saying "don't chase the latest framework/paradigm/trend/fad unless you have a solid reason to do so".

There's always an exploration/exploitation tradeoff when choosing your tech stack, and in my opinion most programmers overinvest in exploration, given that the terrain is infinite and covered in roughly equal local optima.

It depends. Some things are visibly awkward, unpleasant to learn and use, and clearly short-lived. It only pays to learn and work on them if you are paid a lot of money. My pet example from the 1990s is Win16, which I skipped entirely for Win32. Many 4GL languages from the 90s stayed there too. Every second of time dedicated to Javascript frameworks before React/Vue was probably a waste of time. (OTOH learning the bare-metal JS paid off well.)

Ember is still alive and kicking ;-)

Also, having spent time on frameworks before React/Vue makes you really appreciate what React/Vue do for you.

Angular?

Angular is disputable, remember AngularJS? :)

While it might be a bad rule as stated, I took it as a tongue-in-cheek way of getting at a much better rule: Avoid Learning Everything New. Or maybe, for the sake of a better acronym, Stop Learning Ephemeral Dreck. It's certainly good to expose oneself to new ideas. Sometimes it's worthwhile to dive deeper into something different. The problem is that a lot of programmers make neophilia into a lifestyle, forever distracting themselves and never learning anything really well. Scratch the surface, get some quick wins at something that's still new to everybody, move on to the next thing. Avoid any domain or technology where true experts can show you up. That's just another way to succeed as a poor programmer. Good programmers have at least some breadth and some depth in a few areas.

6. Be aware that most coding advice is bad. Think about whether there is empirical evidence that a given piece of advice is true.

Indeed, Usually, all coding advices are too emphatic or clickbait. ex: The 10 languages you have to learn in 2020. The most important js framework. The 10 books you must read.

But in reality, all advice depends, they depend on what are you doing, what you know, what is your experience....

In other words, "Only I hold the real keys, everyone else is lying to you. Trust only me."

No, sorry. Invalidates the entire post, #3 notwithstanding. Such a cheap, low effort, lazy cop-out when writing about any topic.

What the hell was this guy thinking? I'm certain he's got better wisdom to share than this.

Personally I don't think that's necessarily what he meant, and I don't think it invalidates the entire post. I do wish he added more detail though. He doesn't come off as an asshole to me, like your comment seems to imply.

If he were to say that most coding advice was noisy... I mean, I get that feeling too. There's lots of different approaches to the same problem that work in different scenarios, different work environments, domains of expertise, constraints, etc. And yet lots of coding advice is similar to, "<always/never> do X". Unilaterally. Period. And you will end up receiving lots of conflicting advice.

It seems like the smarter thing to do is take everything with a grain of salt. You don't have to change everything you do as soon as you read a new blog post, it's just a different approach you could add to your toolbox, then use it someday if it makes sense.

He's not an asshole, but he gave in to the lack of any kind of rigor required to make a blog post. We're all guilty of it, but I hope we're all also willing to call each other on it.

I spend at least two hours a day on personal projects, for the pleasure and the challenge. They just have nothing to do with programming or software engineering, i.e. my job.

Yes, it's a terrible, second-stringer attitude. Curiosity and obsession are a couple of the key differentiators between a workaday jobber in it for the money (like many who flocked to tech in the dot-com times) and a badass. TBH, if someone's only in it for the money, they're wasting their life in the wrong field when they could be doing something else such that their morale and satisfaction would be greater.

Ahh yes, I'll be sure to let consults notes Distinguished Scientist at NVIDIA and adjunct professor at the University of Utah Peter Shirley that he's a second-stringer and not nearly "badass" enough for Hacker News commentator anon91831837 and he's wasting his life in the wrong field.

It is not like distinguished scientist credentials necessarily correlate with exceptional code quality or software development practices. And it is not like NVIDIA is particularly known to be a place that excels at such.

It's actually sad, his credentials suggest he's capable of a much better post than this...

Either the post is intended sarcastically, or there's something to learn from it.

> Curiosity and obsession are a couple of the key differentiators between a workaday jobber in it for the money (like many who flocked to tech in the dot-com times) and a badass.

Unit tests and sensible comments are a couple of the key differentiators between a workaday jobber in it for the money and a badass. And now what? While I kind of agree that some people might be in the wrong job, that's true for every profession and the comparison seems lacking. If we're talking day job programming, a badass is neither a requirement, nor desirable in most environments honestly.