3 ms·
> Yet if I go back to my non-management dev friends and talk about this, they are all like "eeeew, what about X and Y" and I'm just like, but neither the citize
by Oras 6y ago
> Yet if I go back to my non-management dev friends and talk about this, they are all like "eeeew, what about X and Y" and I'm just like, but neither the citizens or my IT operations staff gives two shits about any of that.
That's exactly what I meant. I remember arguing with a colleague who over-engineered a simple ORM table by having 3 classes. One was just an empty class, the other was an empty interface, and the third was the actual class. When I asked why did you make it this way? He said: "What if we decided to use Mongo later?
Technically he was right but practically, he was wrong! I saw this overthinking and over-engineering pattern across many in-house dev teams. But this is just my experience, and I'm not judging what is right and wrong from devs point of view. Every decision has its context, but I saw how these complications affecting the delivery and customer experience badly.
- 01000101 6y agoFor some reason the first time I do something I always over engineer it... it took me a lot of self growth to take feedback like yours seriously and not get defensive of my “what-if” thought patterns.
- pocketgrok 6y agoI’ve gotten into the habit of just pumping out a naïve solution without worrying about anything and then throwing it away and re-building more thoughtfully because now I have full sense of the scope and some immediate edge-cases. As long as the thing is small enough to do that.