https://news.ycombinator.com/item?id=15462244
As I had to work more with teams and then supervising teams I changed the abstractions I value from when I was programming solo: Now I care less about my project's function than the structure of the team. There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us.
hacker-news-comment-code-inside-interface#independent-modules-clear-interfaces-hacky-code1I now favor code that has a lot of independent modules that can have hacky inner code but that must have clear, explicit and preferably simple interfaces. The project's manager role is to design these interfaces and has the last work on their implementation. hacker-news-comment-code-inside-interface#independent-modules-clear-interfaces-hacky-code1
This is a bit the Unix way. Every module has to do one thing (and optionally do it well). This allows veteran programmers who know all the subtleties of the programming language to collaborate with rookie programmers who may write okay-ish modules that we may have to rewrite later but that work well enough. It also allows programmers, these very territorial beasts, to have their own little realms they control and where they are acknowledged. It helps non-tech managers understand who has to be assigned on different issues and evolutions.