3 ms·

So you have 3 years of working experience. How many code bases of similar size are you familiar with? When working on a new code base of that size, figure out

So you have 3 years of working experience. How many code bases of similar size are you familiar with? When working on a new code base of that size, figure out how old it is, and how the requirements changed over time. It might be more likely your don't see the big picture of why things are done and structured the way they are. obviously, it would be great to have someone around to ask why every time your see something that doesn't make sense or seems overly complicated or backwards. You don't have that luxury. But try to get to know the code more. Sure, you might be right and the code is just complete garbage, but I'm just reminded of how third semester CS students also know everything better as soon as they learn some pattern X and consider it the best and only way to do things. :-)

jaclaz 3y ago
Good advice that more generally amounts to Chesterton's fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
rawgabbit 3y ago
To expand on this. Shit code is not the result of poor developers. It is the result of bad requirements. Bad communication. Bad business processes. All of this is usually the result of a VIP or someone who thinks he is a VIP screaming to make an exception for his special needs. This shitty exception results in illogical processes. And shitty code. At the end of the day, it is all boils down to weak management who cannot stand up to problem customers.