So you actually see “1 year of experience repeated 10 times” as a positive! I like that, but do I think there’s value in thinking about how a system should evolve over the long term and in seeing the long-term consequences of your own architectural decisions.
I’ve seen this play out so many times I’m tired of it. New team member joins. Super “productive”, rewrites enormous chunks of existing code and builds six new things. Great.
Then they leave, and you find out the bits they rewrote were the carefully crafted and well documented protobuf APIs now replaced by ad hoc JSON where the parsing and spec are strewn across thirty places. The new projects you quickly realize make no sense whatsoever and don’t actually do the things they were supposed to do, but kind of look like it if you aren’t paying too close attention.
Now they’re a “senior engineer” at the next company.
very often development teams will value re-use and dry to the point that they'll conclude they need to stuff most things into a common library and share it amongst all their codebases.
Anyone who has seen this done long term has seen this accrete until everyone is afraid to change the common library for fear of breaking _everything_.
IOW, the risk profile of something like this grows over time. It starts out small but each time a project adds it as a dependency the risk grows.
and yes, I understand everyone is going to post about versioning and change management and all the myriad ways one can try and mitigate this.
the point here is that when using a common library like this you must be circumspect in what you put into it. The risk threshold for it being worth going into this common library is going to be much lower for someone who pushes for a common lib and then skips to the next job vs someone who was there over the next 3-5 years and personally experienced the pain and fear such approaches invoke longer term.
and to repeat myself since I know this is HN.
No one is saying you can never have common libraries like this, what's being said is that the long term risk is much more likely to be respected by someone who long term experience and therefore that person with long term experience is much more likely to be able to design a system that can be worked on productively over the long term.
