4 ms·

Much as I hate to admit it I can relate to this. When you come onto a new project, the first thing you notice are all of the things that could be improved. But

Much as I hate to admit it I can relate to this. When you come onto a new project, the first thing you notice are all of the things that could be improved. But most seasoned developers know that knocking down walls right away violates the whole Chesterton's Fence[1] thing and so you make restrained changes and small commits while learning the system. A few years on when you finally have the mental model and understanding to make the changes... you don't see the inefficiencies anymore. I don't know how to square this circle. [1]: https://theknowledge.io/chestertons-fence-explained/ https://theknowledge.io/chestertons-fence-explained/

theamk 2y ago
option 1: when you are new, work with a seasoned dev. They can tell you if this design can be changed and provide guidance, you do the actual work. This is great for learning codebase too, btw. option 2: keep notes during onboarding. Revisit them after a few years working on code. option 3: help new people onboard. Pay attention to where they struggle and if those parts could be improved.
tossandthrow 2y ago
> you don't see the inefficiencies anymore. I don't know how to square this circle. I think it is because you are then able to assess the value of changing it - which is usually not very high. Also, when you are a couple of years in on a project, you probably have more important things to attend to. I think it is great for new developers to attempt to fix these things when they come in: If they are able to, without breaking anything (and also convincing the rest of the team in a cheap fashion that they did not brea anything), then they know the code base and optimized it. However, one should be aware that there is a high risk of them failing. Especially if the new developer is junior.
MostlyAnonymous 2y ago
Thanks for the link friend! I'm now deep diving into the knowledge ;)

theamk 2y ago

option 1: when you are new, work with a seasoned dev. They can tell you if this design can be changed and provide guidance, you do the actual work. This is great for learning codebase too, btw. option 2: keep notes during onboarding. Revisit them after a few years working on code. option 3: help new people onboard. Pay attention to where they struggle and if those parts could be improved.

tossandthrow 2y ago

> you don't see the inefficiencies anymore. I don't know how to square this circle. I think it is because you are then able to assess the value of changing it - which is usually not very high. Also, when you are a couple of years in on a project, you probably have more important things to attend to. I think it is great for new developers to attempt to fix these things when they come in: If they are able to, without breaking anything (and also convincing the rest of the team in a cheap fashion that they did not brea anything), then they know the code base and optimized it. However, one should be aware that there is a high risk of them failing. Especially if the new developer is junior.

MostlyAnonymous 2y ago

Thanks for the link friend! I'm now deep diving into the knowledge ;)