New Year's resolutions

New Year’s resolutions This new year has just started (well 27 days ago), but I have been thinking about what I would like to learn and change during this 2024. Here are my personal thoughts on the matter. I hope they could inspire you to do a similar list. What I would like to learn Tech Domain Driven Design Code bases I have worked on in my career tend to have some tech debt, and the code structure is very different depending on the developer that created the code. [Read More]

Do what the community does

Do what the community does The other day I had a conversation with a team mate about how to implement different patterns to solve a common issue in a interpreted programming language. He was sugesting using a pattern not used at all by the community that indeed was a cool, interesting, and we could argue that it was a more correct one. I was against that. Humans are gregarious and tend to form communities … even programming language communitites! [Read More]

Corporate empathy

Corporate empathy In this times of diversity based on gender, ethnical background, culture, etc. Is that enough? Do we have to be careful when talking with other coworker if they do not belong to any of the main categories? Can we say what we would like and in the way we would like? No, we need to treat them empthically. Communication in the workplace When in every day job, we need to communicate with our coworkers. [Read More]

Rambos

Rambos A one-person army, alone, in the jungle of software, fighting against the peskiest, complex, and soul-eating bugs. He (or she) can work for hours, with a tenacity of a human-hunter machine coming from the future, and his value is sometimes considered 10 times the standard engineer. Your organization depends on this individual. You cross your fingers and pray to your deity to not make you loss this prolific, highly-valued and know-it-all individal contributor. [Read More]

What is your constraint? Mine is anti-work

What is your constraint? Mine is anti-work We, as engineers, not only are worried about creating new things, we need to be able to detect the cause of future issues. However, we must not limit ourselves to software, but to the entire software development team organization. How it all started: The Phoenix Project I was reading the other day the book “The Phoenix Project”, and while the book is a good read, I was geting bored. [Read More]

Don't touch that

Don’t touch that Have you ever been told “don’t touch that, if you modify that piece of code you are going to break anything”? How did you react to this comment? Did you feel “attacked” or simply ignored that piece of advice? Code jungle Starting a working on a project that has some dark corners is a daunting task but following some guidelines can be useful. Scary code There is always some scary code, I do not mean code that is difficult to understand, but code that has unintended consequences if modified. [Read More]

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]