DEV Community

loading...
Cover image for I Regret Being a Hipster in Tech

I Regret Being a Hipster in Tech

Khalil Najjar
I am a Software Engineer from Costa Rica living in Berlin, with experience working in both, a fast-paced startup environment, and a global S&P 500 company.
Updated on ・4 min read

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

Luke Skywalker - 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.

Discussion (45)

Collapse
booyouon profile image
Vince Abuyuan

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. ” :)

Collapse
knajjars profile image
Khalil Najjar Author

It's true, thanks for sharing!

Collapse
briantopping profile image
Brian Topping

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.

Collapse
caelumf profile image
CaelumF

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 😄

Collapse
briantopping profile image
Brian Topping

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!

Thread Thread
caelumf profile image
CaelumF

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

Collapse
tfantina profile image
Travis Fantina

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:

We are only alive for a short while and learning any new technology is a sacrifice of time spent with those you love, creating art or walking in the woods. 👨‍👨‍👧‍👧🎨🌲
Every framework you learn is a lost opportunity to build something that could really matter to the world. Please choose responsibly. ⏳

Collapse
leastbad profile image
leastbad

The joke here is that there are few things in tech less boring than StimulusReflex and CableReady.

Come on in, the water is warm!

Collapse
tfantina profile image
Travis Fantina

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).

Thread Thread
leastbad profile image
leastbad

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.

Thread Thread
tfantina profile image
Travis Fantina • Edited

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!

Thread Thread
leastbad profile image
leastbad

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.

Thread Thread
tfantina profile image
Travis Fantina

Been doing this for 20 minutes and I already love it, everything seems to just work and the docs are way better than HOTWire.

Collapse
golfman484 profile image
Driving change • Edited

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!" ;)

Collapse
knajjars profile image
Khalil Najjar Author

Thanks for sharing this! I find it incredible how you have been working consistently with the same tools for years and still love them!

Collapse
golfman484 profile image
Driving change

"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.

Collapse
golfman484 profile image
Driving change

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 ;)

Collapse
xji profile image
Xiang Ji • Edited

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 :)

Collapse
spirosmakris profile image
Spiros Makris

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

Collapse
sixman9 profile image
Richard Joseph

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.

Collapse
wotzhs profile image
Sean Wong

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.

Collapse
ben profile image
Ben Halpern

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

😂😂😂

Collapse
dastasoft profile image
dastasoft

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.

Collapse
saulburgos profile image
Saul Burgos Davila

I were in your position. My advices for anyone in the same position will be:

  • Learn the basic of programming: Naming, OOP, algoritm, etc, concepts, standars, how to write good code, good documentation, etc.
  • Every year a new framework is created....so forget it. Learning it when you need it.
  • Learn to lean faster.... on interviews I said: "I don't know that framework but I know language so...it will be easy to me learing it "
  • Be the person that your team need at the moment. Don't try to learn things that your team will never use
Collapse
jankapunkt profile image
Jan Küster

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.

Collapse
davidwparker profile image
David Parker

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).

Collapse
716green profile image
Bob Bass

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.

Collapse
omril321 profile image
Omri Lavi

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 :)

Collapse
squidbe profile image
squidbe

A New Hope

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!

Collapse
differentsmoke profile image
Pablo Barría Urenda

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...🙄

Collapse
phongduong profile image
Phong Duong

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

Collapse
golfman484 profile image
Driving change

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! :)

Collapse
eekee profile image
Ethan Gardener

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.

Thread Thread
golfman484 profile image
Driving change • Edited

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.

Thread Thread
eekee profile image
Ethan Gardener • Edited

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.

Collapse
phongduong profile image
Phong Duong

Lazy devs are the best

Collapse
phantas0s profile image
Matthieu Cneude

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

Collapse
hseritt profile image
Harlin Seritt

Yeah, you kind of forget why you're learning all these things. Sure these things can be fun but ultimately they're for work. There's a reason we try to keep it around 40 hours per week. You'll learn all you need to know at your job anyways. More does not mean "better". Each person decides what "better" means to them.

Collapse
shivenigma profile image
Vignesh M

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.

Collapse
iaauteco profile image
IA_AU_ECO

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

Collapse
lollyyy profile image
Jaakko Ihanamäki

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.

Collapse
mykelswitzer profile image
Michael Switzer

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.

Collapse
nathanmp profile image
Nathan McKinley-Pace

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.

Collapse
alexjohnsuarez profile image
ASuarez

Nice one!

Collapse
sesay profile image
sesay

i used to be in this state of limbo, but am glad i took myself out of it