Hacker News new | ask | show | jobs
by NTARelix 1601 days ago
I've found that code colocation is great, especially combined with a directory structure that mimics the application's hierarchy/layers. At my place is employment we try to follow a principle of "keep related code contained to a single place". On its own this ended up causing some problems with "reinventing the wheel" and a relatively inconsistent experience when crossing borders between team ownership. The big thing that has helped a ton is having a regular meeting with nearly all employees working on the same part of the stack. We used the meeting as a space for talking about what we're working on and even get into the details of "I'm solving problem X by building solution Y." At which point others can chime in with interest in using it for their own upcoming projects, describe how they already have a solution to problem X, or provide suggestions. It's not the only thing discussed in this meeting, but it has been important for improving the consistency and general quality of the product. The resulting code follows the same principle above, but reused code ends up bubbling up to a "common" space in the lowest common shared layer; whether it's a new directory or a new package used by multiple projects.

A couple new problems we're dealing with now:

1. Finding older common things and deprecating them. When it's in a common space it feels like it's everyone's responsibility which means nobody ends up working on it. Maybe more narrow, clear ownership would solve that problem.

2. Someone finds the common thing that almost fits their need, if only it had one more little feature. The problem is when this happens many times and you end up with this complicated beast of an abstraction. This is probably solved by finding ways to decompose the abstraction and by following a principle of "do one thing well" or something about simplicity.