I might be late to the show, but here goes: It's tough to follow other's advice on how to design programs. Each program is different, and applying a paint-by-n

I might be late to the show, but here goes: It's tough to follow other's advice on how to design programs. Each program is different, and applying a paint-by-numbers approach like making everything an object just adds unnecessary bloat to the code. The code should always be crystal-clear, so following design frameworks is not going to be helpful. You are pretty much on your own in terms of design. A good rule of thumb for designing programs is to prioritize code simplicity. It's fine if it's too simple -- once a piece of code no longer works, iterate and redesign it. Generally, simple code is most flexible. Puting off design decisions until later => more knowledgeable decisions => less technical debt => more flexibility later on. Be very wary of making abstractions early on. Spaghetti codebases usually result because of bad abstractions. Don't be ashamed of duplicating code many times, as long as it's simpler to read than interfaces and implementations.