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 library, framework or language out there was the way to go. I've curated a list of some of the technologies I've learned thought-out the years:
Docker, Kubernetes, Terraform, Rancher, Helm, Angular, React, Vue, Adonis.js, Prisma, Gatsby, GraphQL, Postgres, MongoDB, Cassandra, Socket.io, Webpack, SASS, Gulp, Next.js, Nuxt.js, Meteor, Express, Koa, Elastic, Algolia, jQuery, TypeScript, Node.js, Deno.js, Go, Python, Ruby, PHP, Java, among many more.
What is the problem with this list? Well if you look closely, I learned many tools that solve similar problems, I am getting ahead of my self but pro-tip: you don't have to learn every single one out there π.
Also, there's been a lot of software architecture changes during this time, we've had the monolithic approach, then client-service came along, need I remind you of the complicated microservices architecture? and now we have serverless.
Look, I could keep going on... As you can see (and probably you've been in a similar situation) I've invested a lot of my free time learning different tools that achieve similar results.
Like so many developers out there, I started to burn out.
Long story short, I took some vacations and went to the German Alps π to contemplate about life and find what was I doing wrong. During my mountain retreat, Apple had the WWDCοΉ‘, and of course, me being a nerd, I just couldn't miss the event therefore I joined.
And all of a sudden it was clear to me what do I needed... it was stability in my day-to-day as a developer. Something Apple offers with their WWDC.
Allow me to explain...
The beauty of this is that it gives guidance to the Apple developers, there are no new disruptive technologies that pop out of nowhere, it's a clear and predictable roadmap, which allows the developers to follow this guided path, and simply focus on getting better at what they do and very occasionally learn the new way of doing things.
Now... I love the web, I was not going to change my career and become a mobile developer overnight. So naturally, I started looking for alternatives in my domain. That's when I crossed paths with the well-known and battle-tested MVC frameworks π π.
A New Hope
I've worked with different MVC frameworks in the past, like Django, but they were more like stepping stones towards my career as a wheel-reinventor engineer.
I tried Adonis.js, which is a very good JavaScript MVC framework, I truly enjoyed working with it, although at the time it had a small community and many new breaking-changes were being introduced to the framework as it was being actively developed.
That's when I decided to go with something more mature, hence boring, and what is more boring than Rails?
I immediately fell in love with the framework and the community behind it.
After a few months of learning the Rails way, I started to realize something... I felt lazy, before I used to learn new skills for at least 4 hours/day (after working 8 hours). Now, all of a sudden I was finally using my free time in a different and healthier way, but why was I feeling lazy?
Throughout the years I got used to the idea that I had to be studying every single day, like if I had some sort of homework because you know - that's the life that I chose by becoming a software engineer (although it's true to some extent).
Don't get me wrong, learning new skills during your free time is important, but it's also important to enjoy other aspects of life, while still learning occasionally in your free time or during work.
This is what I did, instead of using most of my free time to keep up to date with tools I probably will never use. I leveraged my job to introduce new technologies (when the need arises). This way I can stay relevant and scratch my itch for learning new stuff.
Nonetheless, it took me some time to stop feeling guilty and start appreciating the stability that I was looking for, and let me tell you something, it is well worth it βοΈ.
Now after work, I don't open Udemy or Hacker News, I'd rather go for a stroll πΆββοΈ, bike π΅ββοΈ, cook for my girlfriend π§βπ³, do some yoga π§ββοΈ - you get the point. I am no longer a prisoner of tech and guess what? I enjoy my work, coding and life more now than ever.
Learnings
There will always be something new to learn, you can try and stay up-to-date, get burned out, take some vacations and repeat this never-ending cycle.
It's okay (and encouraged) to learn new and hipster tech every once in a while, I certainly still do it occasionally for fun, but it's not longer (and thankfully) part of my day-to-day life.
If you feel that you are in a similar situation don't wait to get burned out, act - make a change. I did it and it has improved my life drastically.
Being a good, happy and healthy developer it's not knowing everything, but rather understanding what you need to know.
"Life is really simple, but we insist on making it complicated."
~ Confucius
Appendix
WWDC
It is a yearly event where Apple presents to their community of developers the improvements coming to the Swift language as well as new features arriving to their operating systems.
Top comments (44)
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.
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!