Hacker News new | ask | show | jobs
by verdverm 1397 days ago
A better way to think about this is

(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.

1 comments

Thank you for the reply!

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

This is one of the parts I feel like I'm actually behind on in my career, despite (and probably in part caused by) having read tons and tons of articles about things like Hexagonal Architecture, DDD, layered architectures, Functional Core Imperative Shell, etc. Despite my almost now 10-years of programming experience, I still could pretty much only come up with two designs for my side-project, on two different extremes

1. A fully de-coupled and well layered event-driven solution that is way too complex for a small side project (and probably too complex for me to implement properly at this point)

2. A "simple" design where I have a few large classes that handle just about everything, with no good model on how to break up the different concepts, aside from just...naively breaking up big classes into smaller classes

Maybe I'm just being overly-critical of what I created for #2, but I just wish I had a better feel for where to draw the lines in my app.

Yet another strategy is to go work on other people's projects. Go find something close to what you built (or several) and see how their code is organized. Spend some time with it, change things, add a feature you want.

I have lots of todos of various sizes on my project if you are interested, and one of the goals is to explore, capture, and reuse software patterns much more easily

https://github.com/hofstadter-io/hof

ping me in slack if you'd like to give it a shot