19
scripta55
74d

Okay. For fuck sakes, writing complex code that's meant to handle "everything" and is "super generic" can be a fuck up. Like just keep shit simple. THAT is the show of great and impressive work. Over engineering is not it. Yes your shit works and yes your shit is fancy but was it needed? How long did it even take you for this over kill? How long will it take the next person to understand or not.
Someone now has to sit and run through your shit to get what you were doing. Instead of just being able to look and once and have it all figured out.
Keep things simple.
Lost 2 hours on bullshit 🤬

Comments
  • 11
    Me: explains exactly what needs to occur
    Dev: let's do it my way instead
    ....
    Dev: it don't work
    Me: explains again
    .....
    Dev: it don't work
    Me: looks at code, that's not what I said
    Dev: I know, I'm doing it this way
    Me: 🤦‍♂️what ever
    .....
    Lead: why is this error occurring?
    Me: ask dev, I give up.
  • 4
    I had a colleague who was a fan of writing overcomplicated pieces of code. Initially I had no problem with whatever he did... But he left the job and now I have to maintain his code and add features to that shit. I cannot even reengineer it from scratch as it is very rightly coupled with other modules. FML
  • 0
    I'm guilty of this in my own projects. I hate duplicating code so I create generic classes instantiated with reflection, hidden behind interfaces and patterns.

    I get that it can be frustrating for other devs. Especially inexperienced ones. But as long as it's well documented it shouldn't really be an issue. At least in my case where classes/methods aren't big because of the way I write. In work, leader should make sure not to throw an newbie to work with a code like that and it shouldn't be an issue either.
  • 0
    Over engineering is certainly a problem but if a well designed, complicated piece of code works, it's the developer's responsibility to make it approachable & understandable. Good names, test cases, comments, documentation, whatever it takes. That's where the review process comes in. If someone else gets assigned to it, it's that developer's responsibility to understand it and improve it.
    The requirements analysis should keep over engineering in check.
Add Comment