3 ms·

Good, that is already half the battle. Not jumping to the conclusion that the others must be incompetent can be more difficult than it sounds, and judging by yo

Good, that is already half the battle. Not jumping to the conclusion that the others must be incompetent can be more difficult than it sounds, and judging by your comment it looks like you have that down. Were you able to ask the devs directly about their reasoning? Asking them about certain decisions, or trying to get them to explain the thought process and repeating it back to them in your own words is an incredibly important step. You might not agree with them at all, but the part of what your own ideas are is parked at that stage. Then, once you've confirmed their thought process, and they agree to your version of it, is the point to ask about improvements or different strategies that you see. 'Would there be any drawbacks to [your approach], because I think it would provide benefit [x], [y], and [z]' is a great point to start off from once you have that confirmation on your version of their thought process. Now, if you don't have any access to the original devs it will become much more difficult to try this process. Best you can probably do is try and see if you can find a person that is willing to play devils advocate, or working backwards from your reasoning to see if there is any knowledge that when eliminated from the thought process will make you arrive to the conclusion of the original devs.

Ma8ee 6y ago
I did interview some of the devs about their reasoning, and they kind of admitted that they probably had screwed up. The problem is the "tech-lead" that claims that he has 20 years [sic] of .NET experience, but can't implement the strategy pattern correctly, but most importantly doesn't understand when and how to use it, which is evident by him hardcoding the "strategies" in the calling methods. He also has six layers before above dapper (no exageration, I have counted them) of classes for a simple stored procedure call. One of the problem is that five of those classes don't add any functionality, since they just pass through the string with the name of the stored procedure and the arguments. "This is how it done", is the answer I get when I question the wisdom of all the empty classes, and then he walks around and telling other people that I don't understand OOP. After failing in my attempts to be transferred to an other team I'm sending out my resumé.

Ma8ee 6y ago

I did interview some of the devs about their reasoning, and they kind of admitted that they probably had screwed up. The problem is the "tech-lead" that claims that he has 20 years [sic] of .NET experience, but can't implement the strategy pattern correctly, but most importantly doesn't understand when and how to use it, which is evident by him hardcoding the "strategies" in the calling methods. He also has six layers before above dapper (no exageration, I have counted them) of classes for a simple stored procedure call. One of the problem is that five of those classes don't add any functionality, since they just pass through the string with the name of the stored procedure and the arguments. "This is how it done", is the answer I get when I question the wisdom of all the empty classes, and then he walks around and telling other people that I don't understand OOP. After failing in my attempts to be transferred to an other team I'm sending out my resumé.