3 ms·
I disagree; there is almost never a "right way" and pragmatism and reality-based outlook always trumps "right way"-ism. This is especially true for mature produ
by arp242 3y ago
I disagree; there is almost never a "right way" and pragmatism and reality-based outlook always trumps "right way"-ism. This is especially true for mature products, which almost always have some history behind them: shifting requirements, "seemed like a good idea at the time, but with the experience we have now it probably wasn't", shifting trends in the industry, constraints in terms of dev time or budget, etc. Often this is sub-optimal, but it works well enough, so it's fine.
And never mind that opinions on "the right way" differ. Previous poster mentioned ORM: some people think "the right way" is to never use an ORM, some think "the right way" is to always use it.
Right Way Guys will insist that your codebase will always needs to be scalable, whether it makes sense or not. You've got a B2B product that will only have a few hundred customers? Doesn't matter. It needs to be scalable. It's the Right Way.
Right Way Guys will insist that this kind of ugly module that hardly sees any changes and is basically bug-free will need to be rewritten to The Right Way once they add a minor trivial feature. It doesn't mater it works fine. It's The Right Way.
Right Way Guys make things worse. Always.
In the case of juniors: they can be taught. They're just juniors. That's okay.
In the case of seniors: good luck... I'd argue these are among the worst people you can hire.
And you really don't need to be a Right Way Guy to write a few docs or set up a staging environment.
- deepnet 3y agoA balancing act between premature optimisation and technical debt.
- arp242 3y agoI'm actually not so convinced there's a lot of balancing in most cases. Most of the time, just do "the simplest thing that will work" is actually quite future-proof, because when (if!) it needs changing then this is usually not too hard, because it's simple. It's usually not too tricky to make something simple more complex, and the extra costs over "make it complex from the start" should be quite low. What I do see is people just writing bad code. "zomg this function is 5,000 lines long and nested 9 levels and I can't make head or tails of it, but somehow it magically works, kind-of, with bugs, but no one really dares to touch or refactor it because the last two times we introduced regressions and had to scramble a fix and there are no tests, and adding tests is hard and requires refactoring which we don't dare". That type of stuff. Not an hypothetical exaggeration either I'm afraid :-( But bad code is just ... bad code. People call this "tech debt" but it's not – it's just bad code. Probably took more and not less time to get that crap to work in the first place compared to if you had done it right. I think one of the major mistakes the Right Way Guys make is to "solve" this by adding patterns and architectures and whatnot. But the solution is to just not have bad code like this. I've seen all of the above play out more than once, with different companies with wildly different tech stacks.