Good practices, such as keeping things simple and small, and keeping things familiar together can be seen from different perspectives: From a function point of view, it might mean short functions that do one thing & with a few parameters. From a component point of view, it might mean a cohesive folder structure & good dependencies. From an architecture point of view, it might mean micro-services with their own database or a modular monolith.

Some time ago I ran into a tweet — one I haven’t been able to find since — of someone saying that one of the best lessons they’d learned through the years is to design code that is easy to remove. Initially, that didn’t sound natural to me — taking into account the death of our code in our programming process — but now I think that’s something we always want to do.

Containers are designed to be isolated but sometimes they need to communicate with other containers. This can be necessary when you have a container as your database server and you have a management tool, e.g.L: PGAdmin, running in another container in order to query and manage the database. In order to achieve this you need the container’s IP in the network bridge created by Docker. Follow either one of these two methods to achieve this:

Troubleshooting is one of those things you will do a lot as a programmer. Spending hours finding out the root cause of an issue may sound tedious — and it is — but that boost of dopamine you get when you find what’s causing a specific problem makes the whole thing worthwhile. The following tips are taken from more than 10 years of troubleshooting: 1. Check the logs This is number one for a reason.

Good practices are methods or techniques that have been generally accepted as the best option to use in a certain field or industry. They also faciliate communication between peers - if you bring a common practice in a conversation with your colleague they probably will know what you are talking about. In programming the Don’t Repeat Yourself (DRY) is one of most known and common practices. 1. The Don’t Repeat Yourself (DRY) principle The main idea behind the DRY principle is to avoid duplication of knowledge in order to reduce the risk of defects appearing when new code is introduced in the future.