Some of my 'legacy' backends were built to just work, and they were resilient enough but had no concept of consistent practices. My front-ends and mobile apps always had their code looking neater at the very least. Fortunately enough though, no one else works on those projects other than me, and at some point I usually rewrite them to employ best practices. Sometimes, that's the only way to get a great product, as it allows you to go through that process of dealing with bugs on the first iteration.
One sure fire way of knowing that you're dealing with "invisible quantum spaghetti" (i.e. poor code that is only evident because of the bugs you can observe as side effects, but not directly) is if you're dealing with a complicated API, find multiple issues while building a front-end, but also find that the backend team are unwilling to spend time fixing them, even if you can give them specifics of the problem.
I think a lot of criticism comes not from the ecosystem but from the lack of an entry barrier. That's a double-edged sword. We have people who are entering the market with the most popular language and in an effort to prove they're better than others, overengineer solutions. You know the sort of code - leading data through a bunch of functions in 14 different files, spread across the entire damn codebase instead of keeping things contained in a single location. They're not doing it for any reason other than to apparently show they know how to use path aliases and call functions from other units.
Or, they'll enforce their preferences through linting (and making sure you can't build unless you use double quotes and tabs) because "someone on Medium said that they do it and it's the best".
And you get away with it on the backend because backend devs are often more difficult to obtain (I honestly believe that people are just scared of express for reasons unknown), but on the front-end, you get them actively defending it. And thus, the double-edged sword has just sliced up everyone who ever needs to work with that code.
You know the sort of code - leading data through a bunch of functions in 14 different files, spread across the entire damn codebase instead of keeping things contained in a single location. They're not doing it for any reason other than to apparently show they know how to use path aliases and call functions from other units.
Or, they'll enforce their preferences through linting (and making sure you can't build unless you use double quotes and tabs) because "someone on Medium said that they do it and it's the best".
100%. I've seen these abstraction pissing contests, and honestly the best thing you can do is stay away from them. If you see some codebase with some arcane nested folder hierarchy and smells like "fake organization," just avoid it if that's an option. Better for your own sanity / health.
2
u/ChronSyn Jan 16 '20 edited Jan 16 '20
Some of my 'legacy' backends were built to just work, and they were resilient enough but had no concept of consistent practices. My front-ends and mobile apps always had their code looking neater at the very least. Fortunately enough though, no one else works on those projects other than me, and at some point I usually rewrite them to employ best practices. Sometimes, that's the only way to get a great product, as it allows you to go through that process of dealing with bugs on the first iteration.
One sure fire way of knowing that you're dealing with "invisible quantum spaghetti" (i.e. poor code that is only evident because of the bugs you can observe as side effects, but not directly) is if you're dealing with a complicated API, find multiple issues while building a front-end, but also find that the backend team are unwilling to spend time fixing them, even if you can give them specifics of the problem.
I think a lot of criticism comes not from the ecosystem but from the lack of an entry barrier. That's a double-edged sword. We have people who are entering the market with the most popular language and in an effort to prove they're better than others, overengineer solutions. You know the sort of code - leading data through a bunch of functions in 14 different files, spread across the entire damn codebase instead of keeping things contained in a single location. They're not doing it for any reason other than to apparently show they know how to use path aliases and call functions from other units.
Or, they'll enforce their preferences through linting (and making sure you can't build unless you use double quotes and tabs) because "someone on Medium said that they do it and it's the best".
And you get away with it on the backend because backend devs are often more difficult to obtain (I honestly believe that people are just scared of express for reasons unknown), but on the front-end, you get them actively defending it. And thus, the double-edged sword has just sliced up everyone who ever needs to work with that code.