Post-it Code

Another daily muse. It’s not surprising that our technical team continues to discover unused functions within a particular feature library. Although the names of these functions may sound promising, the logic inside is often outdated, as they haven’t been refactored to align with the current context of the feature. Some of these functions were written ages ago. This is where I need to borrow a concept from my university days, when my mates and I often applied Extreme Programming (XP) principles in our software projects. The core idea: Don’t add functionality until it’s actually needed. This is essentially the You Aren't Gonna Need It (YAGNI) philosophy. To quote Ron Jeffries, a co-founder of XP, as taken from Wikipedia: "Always implement things when you actually need them, never when you just foresee that you [will] need them."

Today, I stumbled upon a simple read on Reddit that serves as a reminder for both new and seasoned programmers about the importance of Domain-Driven Development (DDD). The post shared this article by Google: Write Change-Resilient Code with Domain-Driven Design . While it just touches on DDD, it's good enough to raise awareness. In case DDD is new to you, here’s a brief description from Wikipedia: Domain-Driven Development is a major software design approach that focuses on modeling software to match a domain based on input from that domain’s experts. DDD opposes the idea of having a single, unified model. Instead, it divides a large system into bounded contexts, each with its own model. For a more in-depth exploration of DDD, here are some useful articles: DDD 101: The 5-Minute Tour Domain-Driven Design (DDD) From my perspective, the DDD concept allows for simpler collaboration between technical teams and domain experts through the use of a consistent language. It also reduces th...

"Chaos Engineering" is a rather cool IT discipline, but I haven't had the privilege of implementing it—perhaps because the systems I work with are never complex enough to require such a high degree of redundancy. Essentially, chaos engineering involves testing a system by introducing controlled faults or failures to identify its weaknesses and ensure it can handle unexpected disruptions. Examples of Chaos Engineering : Killing servers or nodes in a High Availability configuration to see if the service continues to run as expected. Introducing latency between servers/nodes (in a microservices environment) to observe how the system handles slow communication. Why It’s Important : Proactive Resilience : It helps you uncover weaknesses before they escalate into actual incidents, enabling teams to build more resilient systems. Improved Incident Response : By simulating real-world failures, teams gain valuable experience in handling outages, making them better equipped to resp...

Thanks to the advent of accessible LLMs like ChatGPT, translating a language pack for an application is now easy and quick. There was a time when we relied on Google Sheets with the translate function for this task—not only was it difficult to maintain, but it was also less accurate. With tools like ChatGPT, translations can be customised for an application’s context, and most importantly, the format of the language pack is easily retained. You can simply copy the translated pack as a ready-to-use file without needing any further processing. Cost effective and efficient! Try this step-by-step : Load your language pack (e.g., JSON, XML). Paste it into ChatGPT, specifying context, desired tone, and any important instructions. Copy the translated output and use it directly in your app. This is a simple example (I think the instructions could be written better, pardon me).

I recently overheard some users asking about limiting support to TLS 1.3 because it’s a better standard for security. No doubt it is, but in my opinion, if your websites or web services are targeting a global audience, continuing to support TLS 1.2 is a fair and pragmatic choice. TLS 1.3-only policies are safe when the audience is highly targeted and known—such as employees within an organization. Older devices and browsers may still rely on TLS 1.2, and by supporting it, you ensure wider compatibility without sacrificing security. TLS 1.2 remains secure as long as it uses modern ciphers like AES or GCM. By deprecating weak ciphers and enforcing strong configurations, you can still avoid vulnerabilities. Of course, when providing support for TLS 1.2, it’s important to follow a strict security policy: TLS 1.3 must be supported in the security configuration. TLS 1.0 and TLS 1.1 should not be supported, as they are considered insecure. A DevOps friend of mine pointed out that major servic...

In any technical product or service environment, failures are inevitable. From bugs to cyberattacks, no matter how cautious you are, issues will arise in any organization or team. When problems occur, it can be easy to point fingers and lay blame on an individual. As leaders, finger-pointing might seem like a convenient way to handle things, but is it really the right approach? In my view, it doesn’t truly address the issue at hand, and in some cases, the problem might even stem from the leader themselves. By blaming individuals, we miss the opportunity to uncover the higher-level causes, leaving the door open for the issue to arise again. Enter Blameless Postmortem , a process that might already be part of your team’s culture without even realising it, especially if you’re fortunate enough to have strong leadership in place. What is it? A blameless postmortem is a structured review process after an incident, where the focus is on understanding what happened and why—without blaming in...