4 ms·

I'll try to do it without doxxing myself too much. The team is criminally prone to overengineering. Feels like they read GoF and Uncle Bob's stuff, stopped the

I'll try to do it without doxxing myself too much. The team is criminally prone to overengineering. Feels like they read GoF and Uncle Bob's stuff, stopped there and concluded that engineering is a solved problem, with no tradeoffs involved. They're writing 2003-style Java in a language that's not particularly conducive to OOP (Javascript). Any time I solve something by writing a plain old function, my MRs are brigaded with kind suggestions that have an undertone of condescension. "Do you think this would be better solved by implementing the [Strategy pattern]?", "This hashmap seems a little out of place, have you considered adding some encapsulation here?" etc. The signal to noise ratio in the codebase is woeful and finding out how anything works requires a JetBrains IDE and spelunking gear. I don't mind that, I love brownfield projects. The problem is that we keep moving in this direction and that I'm being forced, or at least firmly suggested, to keep producing more "brown". The lead agrees that the codebase could be improved, but believes the churn (a couple of longstanding members with a revolving door of people) is on par with the rest of the industry and since the company is happy with us why fix what isn't broken. The team lead also don't code pretty much at all, so it's hard for them to perceive it as a priority. And the company is happy with us because the specific work we're doing is incredibly valuable -- we could be doing half as good. and still blow every other team out of the water because of the intrinsic value of our work. As long as our production doesn't go down every other day, we're the starchildren :\

v-erne 5y ago
Is this overengineering attitude coming from those few longstanding members? Because if so, I don't see how You can convince them of the value of simplicity (and that any kind of abstraction have a cost) if they themselves does not see value in it. This intuition can only come from long exposition to consequences of adding to much of accidental complexity. And what is more by openly contradicting their intuitions You directly threaten their status in company (because Your solutions will be directly opposing their way of solving things). There is of course second possibility - are You sure that the problem is not You ? Are there other team members that also complain? OOP style of programming takes a lot of time to get used to, but sometimes it can work if programmers are familiar enough with it. The use of strategy pattern can be good if there is enough variability in parts of algorithm that is being implemented. Personally I hate this style but its because I lack imagination (which is necessary to select proper patterns and create proper abstractions). I can only create them as an afterthought (by extracting them from existing codebase). But I know that there are people that can do it up front and hit the right spot enough times (and refactor if not).

v-erne 5y ago

Is this overengineering attitude coming from those few longstanding members? Because if so, I don't see how You can convince them of the value of simplicity (and that any kind of abstraction have a cost) if they themselves does not see value in it. This intuition can only come from long exposition to consequences of adding to much of accidental complexity. And what is more by openly contradicting their intuitions You directly threaten their status in company (because Your solutions will be directly opposing their way of solving things). There is of course second possibility - are You sure that the problem is not You ? Are there other team members that also complain? OOP style of programming takes a lot of time to get used to, but sometimes it can work if programmers are familiar enough with it. The use of strategy pattern can be good if there is enough variability in parts of algorithm that is being implemented. Personally I hate this style but its because I lack imagination (which is necessary to select proper patterns and create proper abstractions). I can only create them as an afterthought (by extracting them from existing codebase). But I know that there are people that can do it up front and hit the right spot enough times (and refactor if not).