3 ms·
This is ambiguously stepping into "overly general / building for the future" territory. Perhaps that is not what you meant. There is a fine line where I do agr
by arnorhs 2y ago
This is ambiguously stepping into "overly general / building for the future" territory. Perhaps that is not what you meant.
There is a fine line where I do agree with you. Cases such as creating a relation table for categories, when you could have made a string array field instead. Or structuring a code in a way where you are not preparing for the future, but also not painting yourself into a corner.
Examples such as that do come to mind. But as I said it's a fine line.
This becomes exceptionally tricky when you are building towards a vision, but only 40% there, and having the code structured for that vision is hard to shake..
- Aeolun 2y agoIt’s much easier in biz software, where what the customer wants is very likely the same as what everyone before them wanted, even if they haven’t come up with all the requirements yet.
- strken 2y agoThe given examples of utf-8 support and reading headers from CSVs are things that (depending on stack etc.) can be nearly or actually free if you build that way from the start. I read the original post as saying something like "good engineers don't shoot themselves in the foot as much".
- Vinnl 2y agoOne challenge is when eg you're doing a code review and see that someone set it up with a non-utf8 column. In that specific case it's probably easy to fix, but it's still strictly extra work even if it hadn't been if it had been set up as such in the first place. I struggle with making that trade-off in terms of what's worth pointing out. Often what I'll do is point it out, but with an explicit disclaimer that I'm mostly pointing it out because it's good to know for the future, but that it's not a blocker (for larger chunks of work).
- arnorhs 2y agoYeah, that's the kind of tradeoff I have a hard time with as well. It's like .. well, you don't strictly need to.. but why not?