The pragmatic programmer | Insights, and thoughts part 2
Hello reader if you read the previous article I started talking about the book “The pragmatic programmer” a book that certainly aged very well and remains with great lessons becoming a must-read book for programmers, and as you can see I got very excited about it, and here I'm going to talk more about the many insights I got while reading the book
Communication
Programmers have a tendency to forget the human factor and only focus on the code and how to communicate with the hardware, but communicating is the most underrated super skill a programmer must have(I'm still working on it) because
A good idea is an orphan without communication
And that's true if you can't communicate properly with your team your project will eventually end up with broken windows if you can't communicate you will have difficulties showing your value to your clients(if you don't have a company like me, your career is your company and your bosses and coworkers are your clients) and if you can't communicate in the IT fields you will certainly find yourself in a lot of troubles that could be avoided.
Appropriate pitch to every group
Very related to communication, you need to plan the right moment to do your pitch for your necessities and the necessities of the group
For example, if you tell your boss that the company needs to invest more in solutions of logging and monitoring next to a big release, your boss probably will not give the proper attention to your requests, but he will certainly care about it if you talk to him about the logging tools a few hours later a critical bug that had no tracing appears in production environment and breaks the system, choosing your fights and the right moment to strike with your requests are normally more assertive because you can make sure that the other part interests will match with yours.
There's no such thing as a final decision
Let's suppose that you are starting a project where the cloud provider “xpto” was already chosen and will not be changed, so you can use all the necessary “xpto” libraries in your code without caring much about coupling, and one month after the release of the project “xpto” provider informs that they are going to shut down their support for the target country of your system and now basically all your system needs to be rewritten with another cloud provider. Pretty sad but happens all the time, the business team makes assumptions and the developer squad believes in those assumptions.
To avoid these software tragedies, you should create your systems and integrations with a non-corruption layer between your business rules and your cloud provider, API partners, etc. At the end of the day, your code shouldn't be dependent on only one provider or in the business team assumptions, because there are no final decisions your code needs to be reversible and detachable from the providers' choices or business contracts.
A view of everything
As programmers at work, we tend to surrender to the temptation of only focusing on our own tasks and features for a long time, but that may not be a better approach, or at least not always, because we may fall in the error of creating features that can't generate value to the client while integrated to the others, or we wouldn't be able to collaborate and warn the business team if the choices of priorities are going to be effective or not if we don't have a view of everything and a view of what part connects to what part.
Of course, if your project is a huge mesh of microservices with a lot of requirements, tools, middleware in the whole system It's impossible to know everything so relax you don't need to know everything, but you need to have an intuition and a good way of locating the knowledge of the other components and how they orchestrate together while coding your features.
So I think we covered a lot of my insights for one episode, it was a little shorter but also deep enough. Also, it was nice to document my interpretation of the book and I hope it didn't get very heavy to digest the content, and as I said, in the beginning, this is a book that aged well, and these above are just a few insights I got while reading the book.