We all try to choose the best tools for the job, but occasionally we may fall short. When did you choose unwisely? What have you learned in retrospect?
For further actions, you may consider blocking this person and/or reporting abuse
We all try to choose the best tools for the job, but occasionally we may fall short. When did you choose unwisely? What have you learned in retrospect?
For further actions, you may consider blocking this person and/or reporting abuse
Soma -
Roshan Sharma -
dev.to staff -
Dragos Nedelcu -
Latest comments (27)
Not choosing NX for a monorepo, while instead spending weeks trying to bootstrap my project with internal libraries using yarn workspaces… glad I found NX shortly thereafter.
Choosing angular over svelte.
This might be controversial, but for me it has to be using React for a little project at work a few years back. I had recently started learning react and thought to use it at work, even though we hand't used it before and the project was really small and simple.
In retrospect I should've used something simpler, for example Svelte or even just plain html/js instead. Adding react made the project quite a bit more complex than it should've been. As the project is small we don't work on it often so whenever I work on it I have to refresh on react and it takes a bit of time to get stuff done.
AG Grid in React
In hindsight, I regret choosing redux-observables, because a) redux requires more boilerplate than is good for your sanity and b) rx.js makes it simple to handle complexity and thus can trick you into adding unnecessary complexity to your code.
I chose to start a new admin panel app as a sister application to the public web app and went with Quasar V2, Vue 3, Vuex v4 with modules and Typescript.
Just too much cognitive load and poor documentation around getting Vuex4 to validate Typescript property with the module loader.
Pinia is official state-manager for vue 3 now😁
Yup!
:)
Like some others, I chose to use Mongo once and later realized I probably should have gone with an RDBMS. But it's a minor regret, because using Mongo mostly went okay.
Another time, I was creating a project and using MySQL. This was for an internal tool, where uptime wasn't necessarily critical, but data integrity and safety was. I wanted to use Amazon RDS because I felt confident in their replication and backup capabilities. But the IT guys insisted that we use the company's own data center and OS volume snapshotting for backups. I objected a bit, but ultimately threw my hands up and said "okay whatever".
Shortly after I left the company, I got called up because the disk failed and the backups weren't restoring and they were in complete panic. Fortunately they were able to fix a backup image and recover from it, and then they migrated to RDS. So it wasn't really my decision but it stands out to me as a time when I should have stood my ground more firmly on a tech decision.
I can't think of any tech that I've used in a project that I've regretted.
I have had projects where the tech we're using probably would have been better off if we had selected a different tech (e.g., if we had chosen F# instead of C#, or if we had chosen D instead of C++). But by the time those sour grapes came to light, it was not practical to switch languages midway through the project — and maybe it would have turned out to be be worse.
As I like to say, "If we switch from Windows to Macintosh, we wouldn't have all these problems. We'd have all new problems."
People are gonna hate for this:
I chose react. For building a simple 4 page website. Worst mistake ever , it was super overcomplicated. Maybe I did something wrong? 🤷
I usually don't regret the piece of tech, I typically regret either the implementation, poor requirements gathering, or lack of foresight in understanding how that particular stack component evolved over time.
But onto the list:
No offense for the people creating those techs of course, I know how hard it is to tinker with something and end up with some high-profile piece of software.
Although interestingly in most cases it's not that those tools are bad "for the job at hand" but rather bad "for the job advised as the project's reason to be" which is kind of unsettling.
I tried using twillio and that kinda turned me off due to the pricing... well now most languages have opensource built in frameworks for stuff like websockets
3rd party apis seem easy to implement at first but then can turn into a pain if you dont have a solid enough design + time for refactoring
I felt some pressure to adopt some JavaScript libraries in the ~2013-2015 time when they really were not upgrades over what came before them — just had some hype.
I was a less experienced developer at the time, which let me question some of my own hesitations, and should have trusted my personal evaluation of the developer ergonomics.
I'm not some kind of anti-new-stuff curmudgeon, by any means, but learned a lot about how to make choices which have carried me forward well.
Oh gawd all that stuff confusingly trying to fix browser compat and provide data bindings to the DOM but in a completely clumsy and unordered way. I'd say it's what gives JS such a bad rap about getting a new framework every day.
I think our puny human brains have a hard time understanding how quickly things shift and change in the computer world while keeping the same name.
Like, if you don't like spaghetti in 2012, you probably won't like it in 2020 unless your tastes changed.
Not that JS has clearly changed for the better, but it has definitely changed in many ways — I think we have a really hard time being objective about these things over time.
Well, JS was always a way to transform DB data into an interactive display and it's getting really easy to do so. I remember spending hours creating DOM elements by hand and binding events manually, there is nothing I regret :) [except maybe a few hours too many spent configuring Webpack]
Modelmapper (modelmapper.org/getting-started/) It was before I knew about Mapstruct, and I had several runtime problems with modelmapper (I assume part of the guilt, as my models were totally insane).
For me, it was a NoSQL database on a website that needed to manage relational data. This was about 5 years ago when these things were trendy and promised really fast performance. The relationships were simple (think users, groups, and memberships), and I thought I could just code my away around the things that an RDBMS would normally handle. It made my code way more complicated than it needed to be. On top of that, the database daemon would just randomly hang about twice a month and no longer respond to requests, effectively bringing the site to a stop until someone notified me that pages were not loading. Eventually, I rewrote it to use nothing other than SQLite. The website has been rock solid ever since. I learned a little about what happens you let hype get the best of your decision making. NoSQL has its place, but RDBMS has been solving a lot of problems for good reason over the past few+ decades.
amen!!
Oh I remember this pain, many years ago, I was consulting a startup and they wanted all the latest buzz words in their stack. I tried to convince them to use rdbms but they insisted on using mongo because no-sql is the latest buzz. no-sql has its place but nothing can be more assuring than a data where relationships can be visualized. The amount of code I had to write just to make sure data being accessed is proper, The amount of cpu wasted by nodejs just to process data that could have been processed by a simple stored procedures or views.
Oh yes, built a side project with GCP FireStore and then looked how much it would cost to even try an aggregation for a bit of high level reporting. Ended up having to code around it at additional expense in terms of time, and a real reduction in functionality over what I planned.
I think a lot of people found themselves in this kind of situation with NoSQL.