I see this often with both new and old developers, they have one way of doing a thing and when presented with a new problem they will fall back to what they are used to even if it’s not the optimal solution. It will probably work if you bruteforce it into your usual patterns but sometimes, a different approach is much easier to implement and maintain as long as you are willing to learn it, and more importantly - know it exists in the first place.

On a less abstract level, I guess my question is - how would I go around learning about different design patterns and approaches to problem solving if I don’t know about their existence in the first place? Is it just a matter of proactive learning and I should know all of them in advance, as well as their uses?

Let’s for example say I need to create a system for inserting a large amount of data from files into the db, or you need to create some service with many scheduled tasks, or an user authentication system. Before you sit down and start developing those the way you usually do, what kind of steps could you take to learn a potentially better way of doing it?

  • NaN@lemmy.world
    4·
    1 year ago

    I loved my course on patterns. It was tough, but I now regularly feel like I can apply mastery of this tricky subject to my software projects. The course used a variety of techniques:

    • Read the seminal Design Patterns book by Gamma et al., for an overview of the concepts.
    • Every week, we’d incorporate three patterns into a preexisting XML processor project. My final one had like 25 patterns, which was challenging to keep working amidst refactoring. (You don’t have to do them cumulatively, but I enjoyed it.)
    • We’d have to ask pattern-specific questions of our classmates in forum threads; and occasionally we’d be assigned to answer some.
    • We each wrote up our own pattern. (I designed one based on my experiences handling data exchange between web apps and clients.)

    Together, this taught us

    • How the patterns could concretely look in practice.
    • Pros, cons, and other considerations for each.
    • Similaraties, differences, and nuances. (We’d joke that everything was the Template pattern if you squinted.)
    • The impact of modifications to the patterns.
    • How to recognize, create, hone, collaborate on, and share patterns.

    I appreciate this approach because patterns are an inherently fuzzy subject.