Engineers who actively work on a software system are the only ones who can effectively participate in its design. Good design relies on a deep understanding of the specific codebase, making generic advice largely irrelevant for real-world issues. The author emphasizes that many design recommendations come from a limited perspective, often lacking insight into the actual complexities of the existing code. In large codebases, consistency often outweighs abstract design principles, and engineers must navigate unpredictable consequences when implementing changes. Concrete software design thrives in discussions among engineers familiar with the system. These conversations focus on specific details rather than broad principles. For example, debates might center on how to incorporate new functionality within existing subsystems, taking into account recent refactorings and information availability. While generic design advice can occasionally help with new projects or serve as a tie-breaker among practical options, its application is limited. The author argues that architects who propose high-level designs without hands-on involvement risk creating plans that are impractical for implementation. Companies often fall into a trap of prioritizing generic design work, believing it to be an efficient use of top engineers' time. However, this approach can lead to disconnects between architects and the engineering teams responsible for executing the designs. Architects can claim success for well-received designs while distancing themselves from failures, creating a lack of accountability. The article concludes that those who draft initial designs should also bear responsibility for their outcomes, ensuring that real software designers are involved in the process of shipping working systems.