Design

separation of concerns, encapsulation, cohesion, modularity, coupling

Software design helps keep code maintainable and modifiable.

Consider using the apply first, study second approach with the resources below: try a problem or exercise from the Apply It section first. If you get stuck, then use a course, book, or lecture in the Reference section. Or if you’re completely new to a topic, then learn just enough and apply right away. The point is: the quicker you get to the “doing,” the better the learning. Make your learning active.

Apply It

Awareness can be a great teacher. That’s why I recommend two tactics for learning and getting practice with design.

First, get feedback on the code that you write from someone who’s better than you, ideally it’s someone who’s code you admire. After all, you want to pick up good habits. They’ll see things differently, and will point out things that you can improve upon.

I distinctly remember one time I asked for feedback on a program I wrote. “You should improve your variable names,” he said. That was useful advice because until that point I didn’t realize that my variable names needed help. But once he pointed this out to me, I realized that he was spot on. There was work to do. The important point is this: feedback brings awareness.

Tip: Target your feedback. Ask the reviewer to focus on one or two things about your code. The reviewer will appreciate the specificity because instead of trying to do everything halfway, they can focus and do one or two things really well. In return, you’ll get much better feedback. It’s a win-win.

Once you get feedback, do something with it. In my case, I created a variable name checklist, which included important points to think about when naming a variable. I hung it on the wall by my computer monitor. It’s hard to forget about something when it’s in your line of vision.

Second, after you complete a problem or program, study the solutions of others who’ve completed the same problem or program. This, too, will bring awareness to good (or bad) design, depending on the code that you study.

Tip: An athlete can have a bad coach, which can cause the athlete to pick up poor habits and misinformation. The same can happen to you by choosing the wrong programmer’s code to study. Study the code of someone who you admire and who’s code style you’d like to emulate. This will draw your attention to what quality code looks like and what you ought to aim for. And, it’ll help you pick up good habits.

Platforms like Exercism or LeetCode offer community solutions and discussions, respectively. So after you solve a problem on one of these platforms, study the solution of others who’ve solved the same one.

Reference

I’m also a big fan of Dane Hillard’s book, Practices of the Python Pro, which is another book that teaches design. Hillard is a good teacher: the content is very approachable and clear. I appreciate his focus on the foundations of design (see part 2 of the book), like abstraction and separation of concerns, as well as the practical application of these ideas. That’s because Hillard walks you through a real application so you can see these ideas in action.

Another book I recommend is A Philosophy of Software Design by John Ousterhout. Yes, it covers the topics you’d expect, such as complexity, modules, naming, and comments. However, what I like best is Ousterhout’s approach to the topic: he offers his own, independent view, and it’s refreshing. And, like any good book, it’s gotten me to think and question my own ideas of what good design is.