The Problem
For the last five or more years I've been doing it all wrong. I thought that learning the newest, trendiest, and hippest lib...
For further actions, you may consider blocking this person and/or reporting abuse
This reminds me of a quote from the dead poet society “ medicine, law, business, engineering, these are noble pursuits and necessary to sustain life. But poetry, beauty, romance, love, these are what we stay alive for. ” :)
It's true, thanks for sharing!
I remember when Rails was the hot new thing, I stuck with Java. Same with Groovy. Same with a bunch of things. When you feel like the world is passing you by, take a breath and look for language or platform usage statistics on Github or StackExchange.
As it turned out, there's still a lot of work in Java and it's kept me fed for over twenty years now. I built a killer app in Scala after discovering Akka, then did some more work in Java. Learned Kubernetes and it required Go, but Java paid more bills. It's a bit long in the tooth, but then they introduce something like WebFlux and you realize it's not dead, not by a longshot. Spring is a foundation that a lot of companies depend on every day and something like WebFlux allows developers to do a better job and have more fun.
Substitute your own languages here, but stay true to your roots. Great to hear you found this.
Whenever I hear of a new technology I will search "Criticisms of X" and "X vs" (intentionally blank to see what it competes with) and pay very close attention to the flaws of the technology.
This process eliminates many new technologies, and makes you an early adopter for the few that are left. For e.g. I skipped Scala and Groovy and fully embraced Kotlin. Not to say Groovy and Scala is not worth learning, but for my use cases were not (and to be 100% honest with you, Kotlin is a superior general purpose language and also superior in most niches).
I want to share some thoughts on it not being so bad to follow the tech trends though
There's certainly a lot of value to the hype languages. The longer established projects and languages are repeatedly taking the best parts from hype languages. Go has some painful flaws and limitations, but I think it popularised some concurrency ideas that have made their way into Kotlin. And when you "fall" for the hype and learn all of these new concepts, and eventually learn with the rest of the community about the flaws, you'll have a big head start at whatever more practical approach you move on to.
I've had to use some older frameworks for a while, and after long enough my approach to solving problems tends to stop changing. Then I'll be forced to use a trendy framework or language, and later come back to the older tech and I'll have new ideas just from being forced into a different perspective. I think this is a nice thing about the trendy techs
Btw, I recommend checking out "Quarkus vs" and "Kotlin vs" if you haven't already 😄
The ask in my post was to "substitute your own languages", which is to say the language wars have no end and there's no interest in engaging in them. I was just trying to illustrate that one's own path is the best path, really don't care for anyone else's opinion on language choices. I also do the " vs." trick, it's great. Thanks for sharing that!
I reckon language discussions can be more productive than they seem when people are just shy to concede at first and secretly come around later 😜 but yeah I should try not to bait anyone
Fantastic post, very easy to fall into the trap of always learning and never doing.
One of the greatest things I've read on this subject actually comes from the Quickstart in the StimulusReflex docs:
The joke here is that there are few things in tech less boring than StimulusReflex and CableReady.
Come on in, the water is warm!
Yeah, I will for sure. I was starting to investigate StimulusReflex when HOTWire dropped, so I played with that and frankly it just didn't sit well with me. In my day job I do a lot of Elixir, so maybe I'm just looking for something more inspired by LiveView (which I know you were with StimulusReflex).
Speaking only for myself, Hotwire sucks. I know that I am probably not supposed to say that as an adult who is involved with building a technically competing tool... but it's just true. It's not good.
Haha, I know you built StimulusReflex but for some reason hearing that is very validating. You've sold me this weekend I will spin up a greenfield Rails project and play with StimulusReflex!
Ha! That's me at my tired and grumpiest! :)
FWIW, I'm only one of an extended family of awesome folks who build SR and CableReady together. It's a labour of love and hopefully bigger than the mere sum of its parts.
When you're ready to get started, definitely drop by discord.gg/stimulus-reflex and we'll help however we can.
Been doing this for 20 minutes and I already love it, everything seems to just work and the docs are way better than HOTWire.
I can relate 100%: I've been doing Java for 25 years (and C++ before that) and seen many "come and go" languages and frameworks.
Who could forget Java EJBs? Hot, hot, hot for a while - I took a look and went "yuck" and avoided any contract that even mentioned the word. A few years later having skills in EJBs was like having leprosy :)
In 2008 I went looking for a good Java web framework. I drew up a "short" list of about 30 alternatives (yes I know, you think that there's a lot of JS frameworks these days!).
Tapestry looked really nice but I didn't like that the page/component layout was specified in a markup language that was not pure HTML so I kept looking.
One caught my eye: An MVC framework that moved web UI coding away from request/response and the awkwardness of JSP based UIs like plain JSP and the extra awkward world of 'struts'. And it's markup language was pure, valid HTML. I was like "how do they even do that?"
It was component oriented, event driven (AJAX events, partial page updating all done with ease), and being proper MVC it had separate 'M'odels that provided the data to be displayed in the 'V'iews. Having been an MVC fan from 1990s when using C++ desktop frameworks and the ease of use and high productivity they brought I thought this framework was too good to be true.
I created a few trial apps using it and fell in loooooove as it was the kind of framework I felt I would write myself if I had the time to write my own! I then adopted it as my small company's official UI framework for all web apps.
The MVC framework is called Apache Wicket (wicket.apache.org/) and it has easily been the most productive, easy to use web UI framework I have ever encountered, way more productive that pure JS front end/UI frameworks.
In the interim I've contracted to other companies and saw them inflict us developers with "the savior" Angular 1 (the so called "Angular experts" hardly understood it - I, a lowly Java developer, had to fix bugs created by the so called Angular experts who couldn't work out why various parts of their UIs were not working!) then they tried to upgrade to Angular 2 (what do you mean by "the app needs an almost complete rewrite"?)
We also discovered that the JS library ecosystem is not at all like the solid, stable Java library ecosystem we had been used to. About 3 or 4 times a year our build would break because someone in some country I had never heard of did an incorrectly versioned, breaking release of their library that was a dependency of some other library we used "17 levels of dependencies down the tree". Arrrrrggggghhhh!!!
With each new JS framework the key players danced throughout the office with great enthusiasm and had no problem convincing upper management that this "new shiny thing" was going to solve ALL their productivity, reliability and maintenance problems ... until it didn't ... and then they went looking for the next "new shiny thing". Management start getting weary of that game after a while...
So, here we go, down the React path then the Vue path etc., There has probably been another new JS framework released in the time that it has taken to write this post :)
Anyway ... thousands of developer and tester days wasted and, therefore, literally millions of dollars wasted.
Meanwhile in my own small company our apps powered on using Wicket and Wicket continues to evolve and has a very active community and answers to any questions are quick.
Our apps using Wicket can do everything apps based on the JS based frameworks do and have all the AJAX powered interactivity they do because its components have a Java and a JS side - but, as Java developers, we only need to deal with the logical, typesafe, high productivity Java side with it's stable ecosystem of libraries "to do virtually anything you need". The Wicket devs have gone through all the JS pain so we don't have to! (Thanks guys for taking one for the team!). However it's always possible to enhance or create a new Wicket component with extra JS if needed. With so many existing components available I've rarely needed to do that.
My learnings from all this: "Well established, well engineered, high quality, high productivity frameworks can outlive that new shiny thing you're tempted by and you won't need to rewrite your UI layer every 2 years!" ;)
Thanks for sharing this! I find it incredible how you have been working consistently with the same tools for years and still love them!
"When you're on a good thing - stick to it!"
It helps when the Apache Wicket devs are proper software engineers and each feature is properly thought out and each release is rock solid.
If I hadn't chosen Wicket in 2008 I would have probably had to rewrite my UI 3 or 4 times by now.
They say "A bad worker always blames their tools".
That could be one possible explanation for the insatiable thirst for "new shiny tools" in the software world ;)
The problem does not lie with "spending 4 hours per day for 5 years". It lies with the way you had been spending them. I mean, with so much time investment, you could have easily aced the whole Leetcode and landed a job at FAANG if you wanted to lol, or you could have built several awesome products or open-source libraries by yourself, all the while having a reasonable work-life-balance and hobbies. Learning things from various step-by-step guides could feel exciting and fun, but it ultimately produces limited value, since you were consuming things from the others, not creating on your own, which is ultimately how value is created.
Of course, focused and purposeful learning in order to be a better creator or to expose yourself to new ideas and fields is totally fine and should be encouraged. However, learning a lot of similar languages and frameworks which don't fundamentally introduce new ideas or thought patterns is a shallow form of learning, and guess what, you feel safe and happy because you encounter little resistance just trying to follow the instructions in the guide and seeing shiny things work exactly as described, but not trying to hack at actual new problems or new products.
I also fell into a similar pitfall during my undergraduate days. If I could give myself back then some advice, I would have said "quit dispersing your attention at various things and actually build and finish what you started, or at least heed the conventional wisdom a bit more and prepare for coding interviews" 😄.
I still think that reading HN etc. is helpful though. It's not necessary to put it into the same basket as reading similar tutorials over and over again. You could come across some really unique piece of thought that opens your eyes. You just need to strike a balance and make sure that you're not reading HN for 4 hours every day and end up not building :)
Hey, great post and I couldn't agree more!
Same thing happened to me, learning a new technology every 1-3 weeks or so, for about 6 years and the burn out was real (and recurring).
Finally settled on a "boring" stack (PETAL) that feels good for me and I actually started being WAY more productive on actually getting things done in very little time.
It's good to study up on fundamentals (knowledge that is generally applicable and NOT tied to a specific framework/library) but "boring" & stability are great productivity multipliers!
Remember these are merely tools. Spending 90% of your time learning how to use them will not really help you finish any actual work or solve actual problems(IMHO)
Cheers
The "homework everyday" REALLY resonates with me, I was doing that for YEARS, I read about a LOT of technologies over the last decade, problem is, I wasn't in a position to introduce any of them into my everyday work, I feel like I've become a jack of all trades but wish I'd just focused on a core set of skills.
Great Post, thank you.
I see myself in you, maybe not as experienced, despite not being in a position to introduce, I set up technical/knowledge sharing session with the fellow software engineers of all levels, explaining & demonstrating how the company / engineers can benefit from XYZ technologies that we could be using, and manage to exert a tiny bit of influence to see some of them being adopted gradually.
😂😂😂
I had a similar conversation with my work colleagues the other day and in a way it reminds me of what you are saying.
I think that wanting to use the latest technology is also driven by the community. I mean when you look for new opportunities or read success stories, you tend to think that the newest is the best and the old is the worst without checking what problem the new solves, and this is the fault of the developers but also of the companies, who adopt the new technology just for the sake of the trendy thing.
I think the industry put a lot of effort into praising people who are into the trendy technologies, but much less into people who had a lot of experience in maintaining a great legacy technology, the trend now is to change jobs every 2 years or so, but people who maintain a product for several years has a value that a person who is jumping every 2 years MAYBE not.
The point I'm trying to make is that maybe being a hipster in tech is not just your fault, we as an industry have a small part of the blame too.
I think the biggest problem is that hype-driven development easily creates viral posts on social media. In addition, newsletters also often report about the latest hot stuff, giving devs the Impression to follow or become outdated.
The best way to me is still to choose the right tech and concepts for the right scenario.
I've had a similar attitude about tech, sorta. I like to work on side projects, for myself that I know I'll use. Within that, I'll generally try a new tech out, but a majority of what I build I make sure to use all my old faithful tools. In that regard, I still get to explore, but I'm still incredibly productive in my stack. (current love Rails API + SvelteKit frontend).
I were in your position. My advices for anyone in the same position will be:
I bet that a lot of developers can relate to this.
It's understandable because regardless of what makes sense, if you want the ability to get hired for interesting jobs, you need to learn redundant technologies.
I learned Vue, React, and Svelte. Vue was my favorite by far although I make a point to use all three of them for hobby projects regularly, but Vue is the framework that I've put The blood sweat and tears into understanding every edge case and corner case, understanding how it works under the hood, and understanding good design patterns. Now, after taking the time to hone my craft - everyone is only interested in React developers.
I was originally a .Net developer who left .net for Node because all of the .NET jobs were for banks with legacy C#/Webforms apps. Now I'm a node developer and the jobs are all hiring Go/Elixir developers.
I genuinely think that the job markets perpetuate the mentality we have where we feel like we need to learn every new technology that comes out.
The force is strong in this one. 😊
Your words are wise.
I learned core JavaScript all the way back in 1998 and spent years with core web tech before frameworks and libraries became commonplace. I've forgotten more tech than I currently know, and I realized quite a while ago that new tech is not inherently better tech.
FOMO is a real thing, and it tends to hit young engineers and uninformed managers the most -- I definitely felt it as a young engineer. So, some teams/organizations spend a lot of time chasing the latest hotness, but they neglect to do meaningful cost-benefit analysis. And it's most meaningful when done at the team level since every team has its own unique dynamic. IOW, framework B may be a great fit for team X whereas framework A (say, the older one) may be best for team Y. It all depends on the problems you're trying to solve and the skill sets of the people doing the work.
Anyway, great post!
Hi Khalil, thank you for this post! I feel very relatable to this - I've had a similar process in the last year. Sometimes it felt like I have to learn the new things, so I won't miss out. At some point you realize you'll always miss out something, and that you just have to accept it :)
If you learned jQuery in the last five years thinking you were getting into the trendiest new thing then yes, you were definitely doing it wrong...🙄
It is exhausted to learn new tools every day. So that being lazy sometimes is a privilege for developer. Do nothing or something you love after work will benifit you in long term
There was once a book written in the 1990s which promoted the idea of the "Lazy programmer".
The book argued that lazy programmers wrote the best code because they would do things like 'reuse' rather than 'copy paste' and write 'high quality, well modularized' code instead of 'crappy spaghetti' code.
They did this because they knew they would have to maintain the code and, being lazy, they wanted the smallest possible code base (via reuse) and the easiest to maintain (high quality, no crap code).
Lazy programmers are too lazy to maintain crappy bloatware so they do their best to avoid creating it in the first place - hire a lazy programmer today! :)
And then code reuse and laziness became Ultimate Virtues, package managers were invented to facilitate it, and maintenance became a nightmare as many devs used other peoples' code with little care. Rather than write the smallest possible code base, easy reuse facilitated bloat and many devs freely indulged in it. I was there at the time. I built my own Linux From Scratch, then I got involved with a distro. I burned out hard.
I think the lesson here is that soundbites out of context get far more traction than actual sense. It's always been a problem. Don Knuth's Goto Considered Harmful was a well-reasoned and balanced paper, but it triggered a fanatical purge of goto which Knuth found disturbing. I think there are other examples, but I just got up and I don't like recalling the bad stuff.
It feels like the problem was worse in the era before most programmers were on social media. There have been "electronic bulletin boards" since the 60s, but I suspect the demographics were heavily skewed towards students. Probably, 90% of mature programmers didn't have access. Then came "eternal September". In 1993, half the kids in America got online and started plaguing the Internet with things they were enthusiastic about but didn't understand. Prior to 1993, September was always like that as new kids got into universities, but the professors had a chance to calm them down. From 1993 on, the hype just never stopped. But now, reading dev.to, I see matur*ing* programmers exerting some influence for good. It might just be my limited perspective, I don't know.
I think the book's author was being rather "tongue in cheek" or maybe even ironic with the term "lazy programmer". The term was probably just click bait in an era before the term "click bait" existed ;)
What I believe he was really promoting was "work smarter, not harder" but that mantra was well established, even back in those days, so would not have had the same eye catching effect on a Borders bookshelf as the concept of an IT author "promoting" laziness.
Everyone knows that the most laziest of programmers are too lazy to spend the time to refactor code to effect code reuse and thus a smaller, more maintainable code base. Truly lazy programmers will copy/paste themselves and the companies they work for into a code bloated, unmaintainable, spaghetti oblivion. I know this because I've seen them in action in various companies for multiple decades. It never ends well. Even if the company survives the bloatification and duplication of their code base their profitability is usually severely constrained.
I remember one project I was brought in to "fix" at the 11th hour. Customer complained about a particular issue in one of the pages and I worked out the cause and fixed it only to get a call from the customer to say the exact same issue happened on another page which I thought was odd ... until I worked out that this other page used virtually the same code (with the same bug) just copy/pasted. I thought, maybe I should search for other occurrences of this code and associated bug ... O_M_G the original developer had FIVE instances of this exact code in the code base when a simple refactor could have seen it done in one method that was called from the 5 places that needed it. Fix the code in that one place and the bug disappears in all 5 pages!
Radical reuse? No, it's just what a half decent developer should have done in the first place.
I remember the Don Knuth's "Goto" experience. Certain types of parsers are much harder to write without using goto but there was the potential for overuse in C, especially by self taught hobbyist programmers coming from BASIC where 'goto' ruled the seas.
I used to read Coding Horror, I do enjoy reading experiences like that. I'm glad I don't have to experience them myself! ;) But no matter how much we explain what the authors of this book and this paper meant, their titles have absolutely been taken out of context. I saw more of it in Linux in the '00s, I think. Perhaps it was the same self-taught hobbyist programmers coming from BASIC who took them out of context, but I think many of them were too young to have experienced that sort of BASIC.
Lazy devs are the best
There are 1087870432 tools out there which solve more or less the same problems. In other words, the set of problems is way smaller than the set of tools to solve them.
For example, high level languages can solve the same problem. What differentiate them is often their ecosystem, like their build tools or their libraries.
In short: learning the big ideas and the common problems in a general way is better than learning all the tools.
If somebody is interested, I've a blog where I try to write about these general problems and about mature and timeless tools which don't change much anymore: thevaluable.dev
I'm stuck with Just Angular and Laravel mainly for this reason. I'm not going to learn something new unless I'm paid to do it, at least for a couple of years.
The tech industry expects continuous learning, but those who do it are not compensated well for that (only burned out). The compensation is actually tied to shipping stuff. So we should focus more on shipping stuff with what we already know.
Great article, thanks for sharing.
Hello, I totally understand, it reminds me of me some time ago, I have the excuse of doing machine learning, or there is a three-way waltz with scikit learn, tensorflow and pytorch. Fortunately, I love python. I also swung between Javascript and these various frameworks, then I rediscovered PHP, but I still have to do NodeJs because of tensorflow.js.
Yes, the 2010s were the festival of the framework and the microservice. Docker / Kubernetes are good technologies
So obviously I don't know what kind of environment you work in but this entire post screams some sort of fundamental lack of understanding in what you are doing and what you think you should be doing. Tools are tools and you really just pick the best one for each project and the criteria for every tool depends on the nature of the project.
I learned most of my development practices in MERN stack but jumped into Vue and serverless/cloud native out of the blue for my work project partly because of what tech is used in my company and partly because I wanted to try out Vue. If you have your fundamentals down it shouldn't really be an issue to be truly tech agnostic and jump into different frameworks and tools whenever needed.
Constantly learning new tools to the point of burning out feels really weird and to the point where the issue isn't in the tooling but in your own approach to development.
I really love your point! I'm still in school, but my relative "outsider" impression is that a lot of changes in the tools developers use seem to be more out of some desire to change things than out of a need to change things.
For instance, there are a ton of JavaScript frameworks out there, but how many have made a noticeable impact since their release? What changes in the quality of production webapps and websites are attributable to a given framework? Given all the effort people put into making and learning to use new frameworks, I feel like there should have been some massive changes in the quality of websites over the past, say, 5 years, but it doesn't seem like the changes in that time have been proportional to the amount of work developers have put into learning and making frameworks in that time.
So, totally understand the need to be pragmatic in what you choose to learn, but feel you might have swung the pendulum too far the other way.
Nice one!
i used to be in this state of limbo, but am glad i took myself out of it