I tend to jump to the opposite conclusion. If a name is cute I assume it’s something open source, named for marketing or SEO. If a name is descriptive I assume it’s probably internal.
- Keep your code reasonably clean
- Use strong typing
- Make sure your tests don't test implementation details if possible
- e.g. using more integration like tests written with react-testing-library
- e.g. using visual regression tests
- If you sense something is off about the tech stack make a POC of partially migrating to something else as soon as possible
- If the thing you tried is better come up with a plan to migrate and do it as soon as possible
- If you've followed all the bullet points above then switching to a better solution shouldn't be that difficult
That's how I try to deal with it. Also if you're not sure which thing is better do POCs with both solutions. Alternatively if you're working on a greenfield project and a week in things don't feel right don't be afraid to try rewriting it with one of the alternatives you were considering, it'll be a slight hit to productivity for a day or two but it'll pay off long term.
By following these guidelines I've never felt on a project that I've painted myself into a corner with the tech stack, or chosen something very bad that is not reversible.
This is a good one. Also think about how confident you are you aren't breaking anything with your new feature, and how confident you would be that the next person won't break your feature.
I think the best case scenario here is something like the iPhone, yes the Androids did come, but they took a long time to catch up (some would say they still haven't), and owning the platform is very lucrative.
It's about being the first one to reach mass market, and holding onto that position as long as possible.
On the other side, the ops team sets up a system of slow and complicated deployments, but they don’t have to deliver features with it, they don’t feel the pain of working with it as much as the feature devs.
If the people working with tools like ESLint or TypeScript don't appreciate what they're doing for them, then yeah they'll work around them.
I guess you need to teach people like that how they can work with the tools to get things done, with higher quality results.
For my part I very much appreciate that ESLint and TypeScript can help me write better code, they're helpful and consistent reminders. I understand that I should use ===, I understand I should check for null, but without the tools I won't remember to do it in 100% of the cases I should.
