I am of extremely average intelligence. On the absolute top of the bell curve, looking down at the rest of you. I am extremely tired of the whole attitude that _anything is possible if you just put your mind to it_. I put my mind to it. That is how I got through CS in university. I worked at least twice as hard as the people that said _just put your mind to it_ and then cruised through even the hardest course without ever studying more than an hour a day and then doing an all-nighter to get an essay in.
Working hard as hell to understand what some low-effort-high-intelligence "just put your mind to it" brat understood as soon as it left the professor's mouth is hard. It just shows me again and again that I drew the short straw in the gene lottery. I have to work a lot harder to do the same things.
Being told to just try harder by someone who's idea of intellectual work is "wherever my curiosity takes me" is really friggin taxing on my self esteem.
----------
Now, he was drunk and angry, but there is something to it. I think both him and I agree with you on a matter of principle, but it is more to it than that.
Some people start programming at a very young age, by the time they’re in college they have the ability to relate all kinds of concepts. An ability that I have as well now, which I obtained after my bachelor and used in my master.
I have a bachelor degree, 36 years old, and I feel like I have reached my ceiling. I still think that I make progression, but it is so slow compared to some really good programmers at my job.
It sometimes makes me feel insecure, and I think of quiting my job, because it feels like I will never be able to be as good as others. On the other hand, maybe I should just accept that this is it, it wont get any better.
CS is an extension of math, a hard science where you seek validation from reality instead of others. If you take the style of the mathematician all comes easy. CS is an extension of linguistics, there might be a style that works there too, but there is also the lost people who count snowflakes instead of noticing snow is all about the same.
Example: Learning CoffeeScript was a total waste of time. Learning JQuery helped me for a few years, but now JQuery is basically useless to me.
Based on past experience, I strongly suspect the same will happen with React, Rust and a bunch of other new exciting tech. There are countless examples besides the ones I mentioned.
But on the other hand, the time I put into mastering SQL or Unix will probably continue benefiting me for the rest of my career. Even C will continue to benefit me, even though it'll only ever be a small part of my job.
So I would modify his rule: Avoid Learning Anything New – Learn Something Old
The failure there is learning something that is not useful to you right now, not "learning something new".
Are their opportunity costs associated with learning one thing over another and making the "wrong choice" in terms of which stuck around longer? Sure. But you can't predict the future. Focus less on what you learned that didn't get much mileage, and focus instead on what you can learn next. Learn new things and old things - just keep learning! In the end, there are very few things you can learn that are a total waste of time - the more things you learn, the more perspective you have, whether or not you are specifically using the exact thing you learned.
And recent experience has shown me that you can both be working with the worst legacy code and CGI has to throw at you and also having to learn pre-release ECMAScript and TypeScript, to use on the same project. Some skills transfer — I’ve never had to fully relearn how to loop through something in a new language once I managed to master both for loops and map/each functional approaches, for example.
Other things are maddeningly poorly developed — tools to help you understand and refactor code are still very much language-specific at the moment and it’s always a one-off to port out-of-fashion languages and syntax to newer ones. Let’s not start on how testing guidelines and TDD haven’t significantly changed since 2003 unless you maybe include SRE work and better “testing in production” techniques... Some knowledge seems evergreen... or stale.
But it’s amazing how when you do keep an open mind, and focus on how something really works at a lower level, it still pays off over time. I still haven’t deployed anything in production with Docker and K8S but that doesn’t mean it wasn’t worth learning, it helped clarify that there’s more to production reliability than simple deployment scripts or imperative commands vs declarative repos — simply knowing it helped me better understand related topics, including additional reasons why immutable, fully-reproducible build systems are a good thing, or how deployment can be seen as a complete system instead of simply “what version of the code is on the servers now?” It also provides a promise of a cloud-agnostic future, and an alternative look at why 12-factor was good, but incomplete.
And there, again, one might say, why did you bother learning 12-factor when most places let you store log files on local EC2 drives, for example? Well, because if you can get over the information overload, having multiple ways of doing things means you’re more likely to be flexible in your approach, or ask “why” when someone says “just do it this way”. It of course has to be balanced with healthy pragmatism, to both ignore the “best option” when it’s too much work, or to recognize that there’s always a chance to continue improving things later on, or as a team.
What’s key is trying to think strategically about your code rather than tactically. A tactician would say “learning nothing new outside of what I need at this moment gets the job done faster” or “this fixes the bug” while a strategist recognizes that there’s always a future opportunity cost, or asks, “but what caused the misunderstanding that allowed it to occur in the first place?”
Also, it’s inevitable that things will change, so you should always either keep up with your specialty or keep expanding your generalist skill sets. And even your knowledge isn’t constant — there’s always something to re-learn if you haven’t used a thing in awhile or in some new way...
(now, of course, you I may be wrong on the cost benefit analysis here. I don't think I am, and the ubiquitousness of the new stuff implies that most of the industry agrees... but no matter the answer, that is the way to think about whether learning something is worth it)
Out of all of the languages I have learned over the years, only one has stayed important in every job and mostly static - SQL
There are many languages and libraries, but at this moment in time, all of them have to talk to a database at some stage, and in order to do that all of them convert the request to SQL.
Besides, having problem context makes the learning much easier, vs just saying...I’m going to learn react today in a void.
If you don't know said tools beforehand, how can you be sure they are right for the job? When building a new website, for example, should you reach for jQuery? Or is React right for the job? Or is Vue even more right? Or will it be Svelte? Or is vanilla javascript the tool that you really need? How would you know?
'A few years' is a solid return on investment. Besides the reason Jquery is now useless is because Javascript now has those capabilities, so your skills were 'grandfathered' to ES6/ES7.
Learning an applicable skill is almost never useless.
While the payoff of learning old > new is typically much higher (search: Taleb Lindy effect), I think matching your learning to the 'human api' is more important. For me, learning is very emotional: when I feel a sense of curiosity and intrinsic drive to know, I'll follow my nose, spend my time where it takes me. I want to spend this kind of energy in a certain way.
When I find myself with an instrumental cause or external need to know, it's most likely going to be because it's something typical, something old, in which case learning about it and being useful with it will require less of my spirit and drive to crack.
New language/tech fanatics tend to pressure through both sources (a la "look at our ingenious design breaking paradigms" and "it's so good your boss will want you to work in it (well, soon)"). Often the former argument is stronger, so it appeals to your curiosity - in which case you're best off searching for the useful kernel, followed by a swift exit in order to preserve your sense of discernment. Should you return there, provoked by your general interest, that ought to be your indicator of importance. How hyped you felt that one afternoon you learned about it after reading HN comments is likely not.
On the other hand, the 'should learn' brigade will tend to target the latter source of pressure (employability & centrality). If you find yourself feeling resistant to this and force yourself into it anyway, you'll easily burn out and douse your curiousity for the day. I've arranged learning resources to languages I find fundamentally dull multiple times, and made only very shallow dives into them.
When choosing what to learn, your built-in heuristics will tend to serve you much better than either a long list of common 'shoulds' or a tangle of overhyped 'musts'. Let natural forces do their thing in shaping what things will be presented to you: avoid paying much attention to the loud people where marketing, shills and zealots tend to roam.
I'm generally the guy who knows the boring shit. C, networking, 'Linux', hardware, RF... But I keep telling myself I'm going to jump on the next bandwagon just to see how the ride goes.
That said, some technologies are fads that learning them for the sake of learning doesn't have a big payoff. I learned TCL at one job and have never used it again. There will always be things you learn for software development that proves to be dud. Get used to learning and be happy when something has long term success. It is vary hard to predict that the long term success will be.
Probably not, because even if you don't use it today, the problems and solutions you learned while using it probably made you a better developer and you know what was good and not very good about it, so even if you are making something with React, you probably remember the "old jQuery days" and don't make the same mistakes.
That is exactly how I understood it.
Then you see that syntaxes and framework API changes but it’s not a big deal because you already know what you want to do, look it up in the docs, and can pick up new languages in a few days.
For example learning high level concepts like filter-map-reduce with the appropriate data structures is relatively language agnostic, so I have the same reasoning between languages and all I see is syntax choices. It greatly improves learning speed and then I am free to choose the best tool for practical considerations for each project.
In what way? I too jumped on the CoffeeScript train, but considered it on the whole time well spent. First of all I wrote a couple of useful things with it so there is that. But more importantly having gotten used to the CS way of doing things made it much easier to jump to ES6 and many of concepts from CS could easily be re-used.
Given how CS inflenced the ES6 (and later) revisions of Javascript, I find that hard to believe unless you stopped writing CS and went back to writing JS exactly as you did before.
He said he was annoyed that he always had to manually join other peoples code. They would send the files they changed to him, and then he would search what changed, and add their changes to his own code.
I asked why they didn't use source version control like Subversion. He asked me what it was. He was so happy to hear that such tools exist, and was going to look into it further.
And I on my part, was perplexed that none of those 4 programmers knew about it.
If you don't regularly read shit to improve yourself, maybe it's time to find another job.
When you go so low-level, then everything else just translates to "overhead" and it's always a trade-off (for example exchanging performance with "fast coding" or "easy of use").
At that point, you know there is nothing better, if better is understood in terms as "performance" (I develop firmware), so there is little room for improvement. Maybe rust? I don't know. It may just be another trade-off.
"Ease of use" and "coding speed" are things that should be interesting to our bosses in order to save a few bucks.
> others are doing that might be better
Of course, in my case I am always open for new techniques: I'd be rather looking and understanding how John Carmack splits and scans BSP trees instead of thinking that X language will do it for me (at the cost of "insert trade-off here").
But no. Just as the author, I'm not going to learn node.js because "new".
I would make no such assumption. Most C++ programmers I've known would have a hard time being productive in a language where they had no collections, templates, virtual functions, destructors, lambdas, exceptions, etc. Trading deep knowledge of how C++ manages memory for knowing how to do it yourself might be even more of a challenge. A lot of C++ programmers know C because they were around as the two evolved, but at this point there are many who entered the profession with C++ and would find C almost as confounding as COBOL.
So yeah, somebody who knew C++ in 1990 was probably within spitting distance of knowing C at the time ... but now, they know it the same way I know Lisp or Prolog, since I used those long ago too. But if they've stuck with C++ ever since, do they effectively know C today? Could they be productive in it more quickly than they could in Rust or Go which they'd never even seen before? That's not clear at all.
(I was looking at the source because the stupid thing would disconnect whenever the PPP connection went donw; it was over-reacting to EHOSTUNREACH errors on the socket, which are recoverable; I fixed that, at least for myself.)
Here it is: https://github.com/marado/netkit-telnet/tree/master/netkit-t...
Focus on platform languages and be a late adopter, it saves a lot of frustration advocating stuff that eventually never takes off, or happens to die and then one is stuck doing maintenance work.
ALAN is probably a very good heuristic for precisely the type of person who reads HN. I would be most of us err too far in the direction of learning new stuff, while letting the projects we've started stagnate.
On the other hand I'll repeat an anecdote I've put out here before - I had a friend I was in a JavaScript course with in 1998 and one day I went over to his house and he showed me the really beautiful table-based demo site he had made to entice employers and I showed him how CSS worked at which point he thundered "That's the problem with this business, there's always something new to learn!"
> After one semester at the University of Illinois at Urbana-Champaign, he transferred to Reed College in Portland, Oregon, where received his BA in physics in 1985, and then received his PhD in computer science from the University of Illinois, Urbana-Champaign in 1991. He then joined the faculty at Indiana University as an assistant professor. From 1994 to 1996 he was a visiting professor at Cornell University. He then joined the faculty at the University of Utah, where he taught until 2008 when he joined NVIDIA as a research scientist.
I think he probably knows more than you give him credit for.
It is phrased a bit ambiguously for shock value, I think.
There are some things that are relatively easy to learn, and would make it so much easier on you. How, as a poor programmer, can you afford not to learn them ?
I think the exact opposite advice is far better: never assume the way you know how to do something is best, and always be on the lookout for what others are doing that might be better.
Here's the thing about learning: the more you learn, the easier learning the next thing becomes. You form links, insights on relationships, new concepts that apply to old things, etc. If this guy thinks learning is such a burden, it's probably because he refuses to learn anything in the first place.
If he thinks he's a poor programmer, it probably has less to do with innate ability and 100% to do with the attitudes he gives as "advice" in this blog.