[ipsocannibal]

What I've learned of "good" program design in my career has come mostly from watching people maintain systems after the original authors have left the project. Compositional systems with well defined abstractions and ownership boundaries seem to fair better over time. They are generally easier to extend while maintaining the abstractions. Unfortunately, most systems in production aren't designed this way. The majority of systems designed at the companies I've worked for are done so by entry or junior level developers. This usually has do with how the promo process works at these companies but thats a separate discussion. Dealing with the pain that poorly designed systems cause really highlights the properties that make certain systems well designed. To gain the experience here get on a project team that has an oncall rotation, preferably a 24hr rotation. If the team has a group of dedicated support engineers even better. This to me is an indication that the team's systems have a high operational load which is usually caused by poor design choices. You'll quickly start to identify the pain points in the system. Next, try to address those pain points. Rinse and repeat for years and you'll understand "good" design.