software

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 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 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 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 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 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 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]