This article was originally published to my newsletter.
There is a common joke in the JavaScript community that a new framework or library gets released every single day. True or not, it's funny because it definitely seems like that is the case. With so many new things to learn, how can you possibly keep up? Or should you?
Learn patience, not a new framework ⏳
I love keeping up with the latest technologies. In fact, I built a site called DevNews a few years ago in which I still use today for finding new tech and software related articles and products.
However, there is a big difference between reading up about a new framework versus actually investing time to learning and potentially even migrating your current code over to it. A lot of the time, it's not worth it because that framework becomes obsolete or even non-existent in a few years.
I've been bitten by this problem many times in the past, and the best advice that I can give is to simply be patient.
For any big projects that you expect to stay around for at least 5 years, you probably want to observe a framework's community long enough before making the decision to learn and use it. Consider the time that you put in to learning a specific framework or tool to be an investment. That return on investment should be a positive one.
The story of AngularJS and React ⚔️
Do you remember AngularJS? Many developers were using it around 5 years ago, and it was deemed the go-to framework for making a dynamic website or entire web app. It was even backed by Google, so what could go wrong?
Angular 2 was announced and it was completely different from the first version. In fact, backwards compatibility was not an available option early on. Thus the usage of React, a competing option from Facebook, grew.
I personally worked on an AngularJS project, but I never invested into it deeply. I was skeptical and continued to build my own projects the traditional way (a monolithic Laravel backend with a jQuery and Bootstrap frontend). Fast forward and I am now building multiple React apps.
I believe that this is the correct approach. Use the tools and technologies that work well for you until you know for sure that there is a better way.
Cool cool... but how do I know when there is a better way?
— Avid DEV reader
Ah, I'm glad you asked. I did an entire podcast episode about this topic! While I talk about React specifically, the principles (community, efficiency, and longevity) apply to any framework or tool. Recommend you check it out 👇
In general, a large community size means more resources available to you for debugging issues and finding accompanying libraries. Even in the case of Angular, there are still tons of resources out there to continue maintaining those projects.
Question: How do you manage to stay on top of technical debt, or how have you been bitten by it in the past?
Top comments (35)
Learn all the things (that you want to learn).
I suggest people play with new frameworks, new tech, new languages.
Learn them, learn FROM them, make yourself overall better.
But that doesn't mean you have to shift your entire life over to them, refactor everything, and destroy productivity. And balance this with your life of course.
Don't get stuck in analysis paralysis on what to do next. Go with your gut. Learn, adapt, move on. Your cumulative knowledge will grow and you'll be a better developer/engineer/sysadmin/etc.
I really love this article and insight. When I first started on my engineering journey, someone told me don't be invested in frameworks, they are forever changing. Know the fundamentals, everything else you can learn on the fly or even on the job. Not saying, you can't learn programming languages on the job as well, but it's a lot easier transition if you know the fundamentals and you're just coming behind learning the frameworks at your particular place of employment. That's why I don't really like companies that insist on hiring only Angular or React developers, as if JavaScript isn't the fundamental language behind it.
Thank you Donita! I agree, fundamentals are way more important than knowing the trendiest framework.
I think there's no magical trick, it's the sum of all your experiences as a developer which guides your decisions. I have had to learn the hard way on this very issue. Fortunately, I had an architect at a previous job who suspicious of all new technologies (iirc he had a very successful startup and framework hype led to a major refactoring which brought the company down), and it really pissed me off at first when he told me that he didn't want any of this "crap" in our codebase. We both definitely could have communicated more neutrally on the topic, but in the end, he was right. Many of the libraries I wanted to use are no longer maintained. Sometimes I had absolutely no reason to pull in a tool, it was just shiny. I think NPM has made us all a lot more aware of dependency hell, although I don't think it's causing us to question our actions as much as it should.
Nowadays, I just pick things up that are intuitive to me. I really like functional programming, it seems very logical and it just clicks with my brain. It took me several years to get to he point where it licked; at first I was doing it because a lot of programmers I respected were dong it, and I wanted to follow in their footsteps. Eventually, I realized that I had slowly picked up enough over time that I was naturally coding according to FP principles without even having to think about it. Therefore, a lot of technologies that adapt FP concepts click with me and I am drawn to them.
While there are realistic questions that need to be considered with new technologies (the community aspect you mentioned probably the biggest one), you also have to remember to f*** all the haters. There's always going to be someone out there on the Internet waiting for a chance to crap all over your preferred technology. If it works for you, it works and that's all the evidence you need. I can't blame them for doing so, I have to admit that sometimes being a judgmental snob can feel pretty self-satisfying in the moment. At these moments, I have to jump back to my experiences with these individuals over the years and remember to keep an open mind. Not everyone does things the way I prefer them to be done, yet the sun still rises every morning and the Earth keeps spinning.
100% agree with you Scott, well said! Experience is a huge factor in this because I learned a lot of these principles and the ones you mentioned from dealing with problems in past codebases.
And yeah, ignore the haters and definitely don't be one of them. Use what feels best to you and respect others' decisions.
Quality unit tests with decent code coverage, keeping dependencies to a minimum and vetting them prior for community/financial support before installing/using. When dependencies are being used, I constantly check/scan/read the change-log and I make the effort to constantly update.
opinion: I really think the word choice oftechnical debt, emphasis ondebtis the perfect name/term (naming is hard), because it really does accumulate compounded interest of pain over time; just like in finances if you let it accumulate too much you usually file for bankruptcy.Kicking the can down the road, ie:
we'll fix it in the next release/versionHaving good code coverage definitely helps with ensuring an upgrade won't break something critical.
And yeah, procrastination can kill maintainable software.
Agree, I made the same experience with a project that was migrated from JQuery to AngularJS and was updated to Angular just one year later, the ROI was super negative. And I face this problem everyday with older projects that use old tech-stacks. People always discuss about new technology, but in many cases it does not really make sense to migrate, especially if client does not care.
I myself used Vanilla JS for years because I did not like JQuery. I skipped Angular, tried React but did not really like and now I use Vue. So my receipe is:
I think to be slow and focusing on your fundamentals is more important than just picking up another framework.
Like for me GraphQL and Web assembly are great but I will just play around till I know this is good to switch over or till there are not enough developers for it which makes it expensive to maintain.
Yep exactly. There is some stigma between developers to constantly stay up to date, but that doesn't mean you have to implement every framework that gets released daily into your project.
REST APIs will stay around for a long time and is still a safer choice. I do love me some GraphQL though, depends on the project.
Sometimes it is also important to avoid grass is always greener syndrom.
It is not a technical debt just because you aren't on the latest hottest framework. It is technical debt when you didn't design your software well.
The reason that front end code change often is because, where every few years, the management or market pressure to need to do redesign, in which case, often times you have to rewrite the front end, since design changes will change all the code anyways. So front end frameworks changes often.
But for backend it is less change often. I remember I went to a startup meet up, and each startup talked about their tech stack, their front end may be refreshened, but their backend is almost always the hottest "framework" around the time they started. For example, companies that started in 2006 to 2010 tends to be ruby on rails, before that Php, after that, a lot of Node.js, etc.
Too much focus on the technical stuff! No truly end user give a damn about design patterns, variable names, libraries and frameworks. The non-technical people, the ones that in the end pay for the technology want - ux, speed, simplicity, value (business logic) etc. Simplicity is the most complex thing.
Totally with you, although I wasn't for a long time. It's hard as a developer to step away from the code to consider the bigger picture, but we really are just building software for other people. Providing them a good user experience is most important.
Indirectly, efficient developer practices allows building out good user experiences, but only until you get into diminishing returns of over engineering. I try to consider the ROI of an improvement in development workflow to the end user.
Very good statement.
I really like this article! Especially with the heading "Learn patience, not a new framework"
I suggest every developer to spend some time learning whatever technology they are interested in. I am a firm believer that a company should give their developers this space for creativity and learning. Although, I think it needs to be mentioned that it there is no promise that the learnings will be directly used in the company's business. However, there have been times that a developer on their exploration time brought some great new ideas & tools that were implemented into the business software.
In terms of introducing change in the business's software, I think it highly depends on the trade off between risk & reward. I usually inquire about what would happen if things go wrong with the change and what problems do we seek to solve making this change. For example, I would be more okay with adding a dependency than changing/adding the framework for a project.
My 2 cents :)
Thank you, that means a lot. I'm quite proud of that heading honestly.
Completely with you on risk & reward. You don't want to introduce too high of a risk if the reward isn't great. This is why incrementally introducing changes makes for an ideal compromise, especially in preparing for an eventual framework change when needed.
:). Looking forward to more of your writings.
I would also add that I think there is an unspoken amount of entropy that it takes to get new developers to utilize a new tool + practice. This should also be included in risk assessment of introducing a new tool.
One of the worst things that can happen is that your software is filled with various tools that various people. Bloat :O
Either that or developers creating their own utilities that duplicate existing functionality, simply because they don't like the current solution or didn't know it existed. This is of course mostly a problem in larger codebases but still plays to your point, installing a library is simply step 1 to adoption/integration.
As a young developer, I always get caught up in wanting to learn the next new thing without really knowing the fundamentals. This was a great wake-up call for me to stay focused and to be good at what I know. Thank you for your insight!
Super happy to hear that Miguel!