The Eternal Novice Trap
feoh.org
feoh.org
I know a guy who is seeking enlightenment writing web frameworks. He is streaming new frameworks at ever increasing pace. Unfortunately, he never gets around to supporting what he has created, thus, he never learns how to make something that actually makes life easier in the long run. His frameworks are pure zen, but only to him. The rest of the team while their days trying to convince management that their high regard for the guys capabilities is completely misplaced.
I know a bunch of people that spend their entire time learning new technologies. New frameworks, languages, patterns. The learning is typically shallow as it ends the moment the person knows how to do anything with it or when he/she finds some kind of huge disadvantage. Then there is a switch to another language/framework/library/tool/paradigm and the eternal cycle repeats.
Stick with a project/problem until completion. Don't be satisfied with first 80% and neither with second 80% of the task. You need to go all the way. Try to learn everything there is to learn about it. Try to figure out all different ways to improve it and then try to figure out why those might not be the best ideas. Go discuss with your team, your architect. Listen to their problems, then figure out how your ideas do/do not help solve them. Understand why.
Try to make things so simple everybody can understand them. Try to be able to explain every decision and how those decisions interact with each other.
And if you are one of these poor fools, who depend on work for income, than good luck not at least partially follow up on trends, them being silly or not.
> Stick with a project/problem until completion.
It's not about intelligence. Sticking is extremely hard for ADHD people.
People with ADHD are mostly learning and working on new things eternally. They keep doing that makes them look like smart people or fast-learners. However, if they keep focusing on one project without trying out new things, they would burn out very fast.
Any feedback would be very much appreciated.
I agree with this post (except for swearing allegiance to any specific programming language): learning programming languages is a poor way to prioritize. Learning algorithms, or math, or operating systems, or compilers, is more effective — and will make it easier to pick up a new language when you need to.
Now, over the last few years we have actually experienced a lot of growth and our code has started to require some scale and I have had time to focus a bit more on the code.
I feel like I have learned more in the last 2 years than the 20 before that.
I've had to focus so much more on actually architecting the system, thinking about how the data is stored in the DB, creating a smooth developer experience, creating maintainable code, and actually tracking and logging tons of detail about the app so we can find and diagnose bottlenecks before the become a problem.
So in my case, it hasn't been so much about having to maintain it for more than a few years (I have projects I have maintained for 10 years now), but the fact that this one is experiencing some real scale has really laid bare my bad (and good) decisions and forced me to learn about and start making better more informed decisions.
Learning to scale an application was certainly one for me. Another was writing a webapp where accessing the primary datastore was a 50ms round trip. Another was writing warehouse software that had to interface with hardware. And another was building a somewhat complex multi-system application that ran an ecommerce business.
Over time it becomes less necessary to deep dive on new languages, but that doesn't mean you should altogether stop, it just means that you're more of an expert now and learning a new language to the point of mastery that you are used to in your day to day work is a lot bigger task.
What the author describes is the dilemma with any kind of knowledge acquisition. You always need to be learning more, but you have to balance that against being productive with what you actually know. As an expert or senior or whatever, I have a pretty good understanding of what the knowledge landscape looks like. As a junior there's a lot more utility in doing a broad survey before diving too deep.
But why? what does that give you?
Then I started earning money, and began purchasing stuff. This avalanches into a full-blown addiction of constantly chasing / trying out new stuff. My playing suffered, my practice routines died, my creativity went to shit.
Even though I was still quite skillful, I found myself playing/noodling the same stuff, caring about pretty much everything BUT the actual playing/music.
I'm now back to owning a couple of guitars, and focusing on what's important. Writing music, getting ahead, and improving.
And for some reason, that mirrors my experience with programming, too.
I'm not sure, maybe some people are just prone to that kind of stuff? Getting caught up with the superficial things.
During my first few years of surfing, I would try (and buy) lots of different surfboards. Also happened to me that as I earned money, I spent more and more on surfboards.
I moved countries a few years ago and sold all my boards back at home, and just got two boards here (one for small waves, one for larger waves). That turned out to be so much better for me. I don't spend so much time looking at every detail of the surfboard, instead I just go surf. I try new things on the surfboards I have, and it tends to be about techniques and less so about the boards themselves. Occasionally I will try my mate's surfboards and I think that they're nice, but not enough to justify spending more money on another board.
I don't believe it's 100% about proneness to get caught up in that kind of stuff. I guess for me it was more just trying to get the most out of the experience. Ironically enough I wasn't surfing as much before moving to a different country, whereas where I currently live I surf 2-3 times a week. Maybe there's some parallels there? As in the more you actually practice X, the more you're likely to find the subset of tools that actually work for you?
That said, I do still believe (and agree with the link) in a few times a year testing out new languages, frameworks, etc, so see what the fuss is about, and in the process learn new things that I might bring back to my current project or toolset.
The technical risk of integrating some fresh technology has bigger, sharper teeth than most risk predators seeking to devour our success.
With the advent and surging popularity of multiple server-side alternatives to Java such as Javascript via Node.js, Python, Go, and others, Java is now viewed as "slow to startup" in comparison and therefore less suitable for cloud-scale deployments that must spin-up instances very quickly to handle the massive bursts of traffic that cloud-scale platforms have been designed to service.
I'm curious what people think is the best alternative to Java for cloud-scale deployments. Javascript - ala Node.js? Python? Go? Something else entirely?
If you look at companies they're all quite different though. Apple uses a lot of languages. Google uses a lot of C++. Facebook is a combination of things, but AFAIK their main platform is still written in Hack. Netflix is probably still mostly Java. Uber is Python + Go.
I honestly think Java is going to come back in fashion at some point after all the recent updates, along with all the newer JVM languages ala Scala, Clojure, and Kotlin.
If you're asking this for "what language should I learn?" I think knowing anything typed + Python is an extremely strong combo.
Recently I’ve been installing Python and I really like it, as it less server oriented and more computing oriented, and it has been a lot of fun. I think enjoying the journey learning a new language is also important!
I've written some greasemonkey scripts for automating work-related tasks, and done some very basic editing for helping others with visual stuff. I've fixed some folks node code, but that was just reading docs and applying the few lines of change.
There are a lot of positions that never really touch js. My most recent project was working a lot with Chef, which is just ruby all the time.
It's hard to outweigh the advantage of using the same language in both the client and the server, and right now, JavaScript is the only universally practical choice on the client side, so it rules both sides now, in spite of all of node's and npm's problems. WebAssembly will loosen JavaScript's monopoly as it gradually matures, but right now all other languages but JavaScript are second-class citizens on the client side, and it will be that way for a while.
I agree with your point about the industry now favouring the event loop model of concurrent programming. I know C# has introduced recently async/await syntax to match the idiomatics of JS (probably to appeal to JS-comfortable devs) ... but the concept of built in event queues is still not supported. (I may be mistaken as I only read a bit about this feature of C# in late 2017)
Take Java for example. You can make an event loop and use it on a web server (Play framework is just that). It doesn't mean you can retrofit all dependencies to do the same. It also doesn't mean business logic inside this server will necessarily use one instead of spinning up os threads nor that it can even plug into the same event loop. And it also means you just introduced opposing views into your ecosystem.
Maybe never quick enough to use in a CGI style environment, or for command-line tools you want to call from a loop in a script (at least, without AOT). But plenty quick enough for any normal server-side use.
https://news.ycombinator.com/item?id=21871645
I have had a lot of success using Node.js as the middle layer to route requests to a running JVM for all the computational work.
If you calibrate the definition of “learn” appropriately for your skills and goals that advice is great.
The advanced programmer in other language can fall into many traps and produce non-idiomatic (usually overcomplicated) code.
Goes the same when learning a big enough framework.
Most people can learn to speak a new (human) language from the same "larger family" (e.g. french from english) in less than 25 weeks.
I've been using Go for middlin' size projects for several years, and recently wrote about a 10K SLOC program in it. I still don't believe I have mastered the language, not by a long shot.
I've been writing C since the late 1970s, and I still discover things about the language. And I don't know anyone who claims that you can master C++ in a year.
Same with languages. You can be conversational pretty quickly but to truly understand a language takes many years.
But you can definitely reach a level similar to these people in a couple months full time. If you think the people who design languages have decades of experience, you will be surprised.
I personally would consider it a failure of the language if it really took more than a couple months to master. We are not talking about computer programming in general here; we are talking about a specific programming language: a programming language is an _artificial_ construct whose sole intention is to be easy for humans to work with it. If humans are generally terrible slow with it, then, what is the point of such language?
The same goes for programming languages. The syntax may be easy, depending on your language of choice, but mastering it is another story.
The CEFR/EU consider you only need around 800h to reach Advanced/C1 french level as an english native speaker, which is around 30 weeks full time. That is way more than "communicate basic ideas", which is more like an A. In fact, the oft-shared [1] map from the US' FSI considers than 24 weeks is enough for a US diplomat to reach _proficiency_ in French.
[1] https://img.theculturetrip.com/1440x/wp-content/uploads/2017...
I think people seriously understimate the amount of hours a single month has. Programming languages are much easier to learn. Very likely you can even memorize the entire specification of your average programming language (save for a couple exceptions) in such time.
Which I wouldn't do to learn a language, but just saying to prove the point.
There's more than enough examples of people writing C or Java in other languages.
* Whether you're learning in your spare time outside of your work and other commitments
* Whether you're learning something radically different to anything you've used before to teach you a totally new way to think about solving problems
* Whether you want to reach the level of "yeah, I've used it" or "go ahead, technical interviewer, try to stump me, your large production codebase won't contain anything I haven't seen before"
It's not like anyone would say the vistor who looks up words in a travel dictionary has mastered the language...
With some exceptions, most language people were using a decade ago are still around and have paying jobs. There's no reason why everyone should go berserk trying to eat, breathe, and think in code. Life is more than just computers. Personally, I'd rather spend that time tinkering, hanging out with friends and family, working on my side business, making moonshine, traveling, etc. Programming languages suck and I don't want to use them more.
> The advanced programmer in other language can fall into many traps and produce non-idiomatic (usually overcomplicated) code.
Kind of reminds me of when I came to JavaScript from Ruby and overcomplicated the code by treating it like Ruby.
Personally, I’ll study new languages or cultures or technologies or games. But I’ll also develop—and necessarily, ditch—ones I’ve previously learned.
It’s easy to get caught up in learning lots of basics. Right after the basics is the hard part of integration, which leads to deeper understanding. It’s also easy to do the same thing every day, tricking yourself into the illusion of mastery, and risking becoming the best in a dying field.
Wow, what an apt metaphor.
> You can talk the talk like a champ, and be up with the latest buzz, but in some corner of your mind you may recognize that your basic skills are fundamentally lacking.
Learning for learning's sake is admirable, and it's easy to snub practical application. But it's much like how you can only read a few thousand books in your life -- the modern world is so full of novelties that you must carefully choose what you learn. There is an inherent opportunity cost in all learning.
My personal razor for deciding what's not worth learning is: if I can't justify teaching others what I've learned, it's probably not worth learning.
Also, for each new language, there's a new build system, with a different directory layout.
So there's definitely some balance that is good to strike between learning a greater number of concepts and paradigms vs going deeper into fewer languages/frameworks.