Application composition may lead to microservices -- which is good -- but microservices require some ideas about how applications "talk" between them over the wire (protocols and such) which you don't need to start with.

When we were discussing the magical number seven, I mentioned that it made more sense to actually call the functions in sequence instead of each calling the next. That's basically a "function composition", one thing you can also do with your applications.

In this day and age, when everything has a graphical interface, does it still makes sense to add command line options to your application? In fact, it does.

Do not ignore the power of configuration files.

One thing you must learn is how to break your project into smaller libraries, to avoid doing rounds to deal with "the same, but a bit different".

On a previous life, to understand how a system behaved, I added a ton of metrics: how fast things were going in, how fast things were going out, how many things were in the middle, how many the job processed... Not doing it so makes me feel... naked.

Let say you need more performance on your application. You may be tempted to look at your code and think "How can I keep this same logic and still remove a few cycles, so things seem to go faster?" Well, if you want performance, you need to change your logic.

A lot of projects assume that you'll put things with the same functionality in the same place, no matter what data they deal with. This makes things harder to break apart later.

When working with source control tools, keep one change per commit. Avoid bundling more than one change in a single commit just to "save time".

"This is my stupid application that I just want to learn something" is not even a good excuse to not use a version control system.