Ask HN: How can I “reset” the way I approach building software?

(1) you are still young and learning

(2) you should broaden your toolset (patterns) and sounds like you are already doing this, good job!

(3) with time, you will become better because you have more options to select as the best option given the context

(4) all software seems to experience the curse of complexity, it's hard to keep it simple once you have to deal with the real world and all the edge cases that it presents

Sounds like you are doing the things you need to be doing and just need to keep at it.

---

edit, one strategy you may consider is to solve the same problem (program the same thing) with different languages, technologies, and patterns. After, try the same thing on something else. This will give you a breadth of contexts

another strategy is to work on the same project for a long time. This will uncover problems you only reach when a project becomes sufficiently mature. Often you will need to rewrite, refactor, and swap out technologies or patterns.

It blew my mind because, I was already applying it in my daily life without realizing it, but in a different method: I would write things down to help me clear up my thought process; eventually I would organize my notes as bullet points and whatever could be placed under a specific bullet point, it would end up as sub-category, well sub-bullet that is.

Eventually it helped me keep my mind organized, let alone my projects, and meet the deadlines with approximation 95% success; the rest percentage is for unpredictable circumstances that can happen to anyone of course.

So, my advice would be as follows:

    * Start small, start simple (KISS principle). 
    * Have your project's logic written down; personally I prefer on traditional notepad.
    * Monolith first; most of the times going full microservices in advance is a premature action.
    * Prefer battle - tested libraries than writing your own.
    * Ask for advice or feedback if you get stuck.
    * Invest time reading others' code; that's how you become better at programming.
    * Last but not least, apply the UNIX philosophy (if possible); "Write programs that do one thing and do it well."

That said, things often become complicated because you don't have the skills to keep them simple (for example, you draw the boundaries between your modules wrong, or you fail to abstract the right things, leading to tight coupling and information leaking). So it's pretty normal for your software to be a mess for the first decade or so.

You should just keep writing your project, and as you find as the developer certain things on it are harder than they should be / frustrating / take too long, that will indicate a problem. Then you can keep trying to refactor until you get it right. Writing bad software is how you learn to write good software.

You asked for an example and I just gave you a bunch of philosophy, so I'll give you at least one. It depends on your language and what you're doing but I use Go a lot, and I think Stripe is pretty good at keeping things straightforward https://github.com/stripe/stripe-go

My advice would be to try to optimize for what makes it possible for you to get things done the fastest. Ultimately that's the point of any abstraction, that and improving readability. Don't try and apply fancy patterns, just focus on solving the problems you're setting out to solve. If you find yourself working on a project long enough then you'll probably naturally find a need to start applying more complex architectures and abstractions, but it's almost never a good idea to start with those, even on a large project at a company that everyone "knows" will have to scale. Maybe especially in that scenario.