Misconceptions about code comments

Misconceptions about code comments I have been working in this industry since 2008, and it seems an idea is spreading through software companies: code comments are considered harmful. Is that true? Where did all start? I think that this idea started with the Clean Code book and the subsequent talks by Robert C. Martin. Uncle Bob (as people use to call him), has the idea that code should be self-explanatory, and if there is a comment, it is because code is not well structured. [Read More]

How to manage docker secrets

How to manage docker secrets The product that is produced by most software developer teams is a docker image. How can be sure that we are not leaking secrets in docker images? If we include them as building arguments for sure they are going to be stored in the own image. Is there any way to avoid having them inside the docker image? Introduction Suppose you have a docker image that requires a secret, you do not want to include it in the image, but you need during the process of building the image. [Read More]

Software engineer, programmer or wizard

Software engineer, programmer or wizard Introduction I have been named many things (with respect to my profession) some of them were not actually correct. Should I correct people? Should I be worried about this? Naming They say that naming something creates it. Does being called a Software Engineer increases our work level? Does it give more respect profession-wise? As our discipline evolves, we have had many names from programmers, to software developers, software engineers, or even wizards! [Read More]

Code reviews or understanding the code

Code reviews or understanding the code How would you do a code review? Only by reading the code changes or do you thing you need to actually run the code, and what is more important, fully understand the modifications? A tale of two code review cultures Let’s compare the two following environments: Slow but safe team Imagine a team were reviews are done by several members. There is a focus on the detail, PRs are slow to be merged as they are improved several times before the final merge. [Read More]

Don't work more than enough

Don’t work more than enough Sometimes we push ourselves to the max. maybe because it is there are some deadlines when we are not going to be able to release the new version, maybe it is because our life outside work is not good enough or maybe because we are excited to be working in such a company/technology/team. However, our mental health is going to be damaged by overworking. The question is not how much, but when we are going to get burned out by overworking. [Read More]

Bike sheding in merge reviews

Bike sheding in merge reviews Focusing on the important things is a crucial matter. When trying to solve a problem, sometimes we subconsciously focus on the easy part, the known part, the part we know we can tackle, and forget about the other parts. The hard parts. Prelude Humans are falible, we know that we are not as rational, impartial and intelligent as we like. We are full of flaws. [Read More]

Git History in PRs

Git History in PRs Suppose you have a big feature, and you are creating a pull-request with all your changes. How do you organize the changes? Only one commit? One per sub-feature or sub-fix? How do you make that division? Or maybe you could organize the commits in a way that is helpful for reviewers… But how? This post try to show different approaches I have found during my years in the workforce. [Read More]

Open Source dependencies in software projects

Open Source dependencies in software projects Most of the foundations of current commercial software projects are open source. But what happens when an open source project becomens unmaintained? Dependencies, dependencies everywhere! Most software projects have a miriad of depedendencies. Why? Because we (as software engineers) are not going to reinvent the wheel. Having your software depend on a well-tested, maintained, and supported is a bliss. It saves you time, and work very easily: you only have to be aware of two things: [Read More]

FOSDEM 2023

FOSDEM 2023 Past week I assisted the FOSSDEM 2023 conference in Brussels. It was two days of talks of different topics like programming languages, containers, security, etc. It was a blast! I am these days watching the videos of the talks I could not see in person My advice for future FOSDEMs Travel Pack light. Do not bring a suitcase, bring a 40L backpack with a couple of change of clothes. [Read More]

Dockerfile stages must have a command

Dockerfile stages must have a command In multi-stage Dockerfile, you have to be careful for what stages you run. Want to avoid having misteriously exit 0 errors in containers? Add a CMD at the end of the Dockerfile stage with some dummy command like CMD ["/bin/bash", "echo", "Command for stage X"]Any stage that has no command will exit without informing the user of what happened. This could cause some mysterious errors if you are getting up all containers and not overwritting the command of the ones that have none. [Read More]
docker