The Language of Software Design
My novice apprenticeship last year was both an exciting time and a frightening one. Exciting because I was quickly learning about something I was passionate about and frightening because I realized how little I knew. My conversations with other developers often required (most likely annoying) laymen’s descriptions of the jargon they were using. Without a shared vocabulary I couldn’t speak the same language and often had no idea what they were talking about.
I was able to glean shallow conceptual understanding of technical terms like garbage collection, staging environments, integration tests, etc., from these conversations, but there was another piece to the communication puzzle: design language. This was where some real learning happened for me. My mentor tasked me with learning about design patterns in order to understand the language of software design rather than a new programming language or a stack of technical terms.
I would argue that learning a programming language’s syntax is the easy part. The design is the hard part, and thus the shared language we have for software design is paramount. If we can’t easily talk about abstract concepts like dependency inversion or decoupling, how can we design and build quality software within reasonable timeframes? Consider a conversation talking about “that time I did <insert long description here>” compared to “that time I used the strategy pattern.” A shared design vocabulary shortcuts the descriptions and gets us to the conceptual heart of the problem far more quickly.
That said, learn as many design patterns as you can. Both your designs and your ability to talk about your designs will be better for it!