For this conversation, I sat down with Roberto Capodieci, a technology entrepreneur, blockchain researcher, and one of those people who has seen several generations of computing from the inside.

Our conversation started with something simple: coffee. As an Italian living in Bali, Roberto still begins his mornings with a cappuccino before jumping into work. It quickly became clear that technology has been part of his life for almost as long as he can remember.

He started programming when he was five years old. By the age of nine, he was already making money from software. As a teenager, he founded his first company and built video games for the Commodore systems, working in C and assembly when every kilobyte mattered.

Listening to those early stories was fascinating because they reminded me how different software engineering used to be. There were no online courses, no Stack Overflow, no AI assistants. Learning meant taking machines apart, reading manuals, experimenting, and spending hours on bulletin board systems with other curious people around the world.

We also spoke about the early internet.

Long before cybersecurity became a recognised field, Roberto was already investigating online scams. One case involved malicious dialers that secretly redirected people’s internet connections to expensive premium phone numbers. He tracked down the people behind the scam and shared his findings with the authorities, eventually receiving a letter of thanks from Bill Clinton.

What quite surprise me wasn’t the technical achievement here. It was his motivation!

He believes that when you understand how something dangerous works, you have a responsibility to help others understand it too. Whether it is exposing online scams or explaining how software really behaves, his goal has always been to make technology safer for everyone.

That naturally led us into a discussion about trust.

Modern software gives us switches, buttons, and settings that we simply accept. We click “disable”, “private”, or “do not train on my data”, but very few of us actually know what happens behind the interface. We trust software because the interface tells us to.

It is an interesting perspective, especially today as AI becomes part of our daily lives.

We then moved into blockchain.

Roberto was involved with decentralised systems long before blockchain became popular. In fact, when he first discovered Bitcoin, he did not immediately see its value because his focus was elsewhere. Over time, after working on multiple blockchain projects and protocols, his perspective changed.

One part of his journey stood out to me.

During the pandemic, he spent a significant amount of time and money building a new decentralised platform. The first attempt failed. Instead of walking away, he started again, rewriting the entire project from scratch in C, this time with the help of AI to speed up development.

I think every software engineer can relate to that.

Sometimes the first version teaches you more than success ever could.

Towards the end of our conversation, we discussed AI.

Like many engineers, I often think about the balance between the opportunities AI creates and the concentration of power behind today’s largest models.

Roberto shares that concern.

He believes AI is one of the most powerful tools we have ever built, but he also argues that it should become more decentralised over time. If only a handful of companies control the models, the infrastructure, and the data, they also influence how information reaches billions of people.

At the same time, he is genuinely optimistic about what AI enables.

He gave a simple example that stayed with me. Someone who owns a bakery understands their business far better than any software engineer ever could. Today, with AI, that bakery owner can build the first version of the software they actually need instead of trying to explain every detail to someone else.

That idea extends far beyond bakeries.

People closest to a problem can now participate directly in building the solution.

For me, that is one of the biggest changes happening in software engineering today.

This conversation is not only about blockchain or AI.

It is about curiosity, questioning assumptions, learning continuously, and remembering that technology is only valuable when it genuinely helps people.

Subscribe now

Shipping better products is rarely about working harder or spending more hours. It comes from focus, flow, and knowing what matters next. Clear priorities reduce hesitation and improve decision making, helping engineers ship with confidence. This is about building the right things at the right time without noise or distraction.

Building software is rarely about generating code first. It is about making the right decisions at the right time, with a clear focus on what actually matters.

The strongest engineers are not the ones who know every tool. They are the ones who stay anchored in the problem they are solving and avoid drifting into unnecessary complexity.

Focus keeps everything aligned. When you are in flow, you stop jumping between tools and start asking better questions. What does the user really need? What is the simplest way to deliver that value? What can be removed instead of added?

This mindset changes how architecture decisions are made.

If the system only needs a few endpoints and caching matters, REST often fits better than introducing GraphQL. GraphQL has its strengths, but it is not always the simplest choice.

The same applies to databases and infrastructure. PostgreSQL, ORMs like Prisma or Drizzle, or query builders like Knex all solve different trade-offs. The decision is not about using the most modern tool, but the one that keeps the system understandable and maintainable.

On the infrastructure side, simplicity wins in most early-stage systems. Lightweight CI/CD pipelines often outperform heavier setups early on. ECS can be enough without introducing Kubernetes too early. Terraform is powerful, but not always necessary at the start.

Good engineering is also about knowing when to stop adding layers.

Middleware, authentication checks, schema validation, and error handling are necessary, but only when they reduce real risk or duplication. Every abstraction should earn its place in the system.

Reliability becomes part of this mindset. Observability tools like Datadog or New Relic surface issues such as latency spikes and failure rates. SRE concepts like error budgets help prioritise what matters next. If the system is consuming too much of its error budget, stability takes priority over new features.

Security and maintenance are part of the same loop. Dependency scanning tools like Snyk exist to prevent hidden vulnerabilities, but they introduce trade-offs in cost and complexity. The decision is not about using everything available, but what is appropriate for the current stage of the system.

At the core of all of this is focus.

Focus on the user.
Focus on the smallest useful system.
Focus on shipping, observing, then improving.

Everything else is optional until it is not.

Building software is an ongoing cycle of decisions. The better your focus, the better your system becomes over time.

Avoid distractions to increase quality and productivity outcomes.

Subscribe for free to receive new posts.

I’ve spent the last decade building projects on GitHub. They are available for inspiration and contribution. More content is coming on LinkedIn.

Subscribe now

I’ve spent the last decade building projects on my GitHub.

Check them out for inspiration and contribution. And I’ve got more content coming your way on my LinkedIn!

Share

Subscribe now

I’ve built plenty of projects on my GitHub over the years. Feel free to browse through for inspiration or contribution. I’ve got more exciting content coming your way on my LinkedIn. Make sure to hit that follow button so you don’t miss out!

Subscribe now

I’ve built tons of product-centric projects on my GitHub over the years. Feel free to check them out for inspiration or jump in to contribute! And I’ve got more content coming your way on my LinkedIn! Stay tuned! 🔥

Share

Eenjoy your journey! 🏝️

A strong mindset starts with something simple: doing work you care about and staying close to that feeling over time. There are difficult days, moments where things feel unclear or frustrating, but what matters is how you respond to them. Staying grounded in a positive direction helps you keep moving, even when things are not perfect.

Positivity here is not abstract. It is practical. It comes from surrounding yourself with the right influences, choosing tools that remove friction, and building habits that keep you focused on progress instead of frustration.

From there, the shift toward becoming a product-first engineer starts with one key idea: think like the user. Before writing solutions, understand the problem deeply. Before building features, experience the product as someone who depends on it. This perspective changes how decisions are made and naturally leads to simpler, more useful software.

On top of that, the role of an AI-first engineer is becoming more real in everyday workflows. Modern tools are changing how engineers interact with their environment. Tools like Superset, Conductor, CMUX, and terminal-based AI integrations like Codex or Grok bring intelligence directly into your workflow instead of keeping it separate.

Using MCP integrations with tools like Figma, Linear, Notion, or Webflow also changes how fast ideas can move from design to implementation. Instead of switching contexts constantly, you can stay closer to execution and iteration inside your terminal environment.

Even personal workflow setups evolve around this. Some engineers use multiple terminal sessions, cloned repositories, or workspaces to isolate features, experiments, and debugging tasks. Others rely on Git worktrees. Newer tools like Superset and Conductor simplify this by abstracting complexity and making parallel work more manageable without friction.

The key point is not the tools themselves, but the willingness to adapt. What you used last year is often not enough for what you are building today. The pace of change in software engineering means your workflow must evolve with it.

Improvement comes from exposure, experimentation, and action. When you discover better ways of working, the value only appears when you apply them in your own environment.

The goal is simple: stay positive, stay curious, build with intent, and continuously refine how you work as both a product-first and AI-first engineer.

I’ve spent the last decade building projects on my GitHub. Check them out for inspiration and contribution.

I’m preparing more content coming your way on my LinkedIn!

Subscribe now

Most software becomes more complex over time. More features, more abstractions, more layers. But what about taking the opposite path?

I had the great pleasure of interviewing Herman Martinus, the founder of BearBlog.

He has taken a very deliberate path: simplicity over growth, independence over scale, and a strong refusal to let feature requests dilute the core idea behind his product. That mindset alone makes his approach interesting to follow!

Herman is a former video game developer based in Cape Town, South Africa, where the tech scene is real and active. Meetups happen regularly, and the community is small enough that you keep bumping into the same people, which builds genuine connections over time. And when it’s not cloudy, the majestic Table Mountain is right there outside his window (no need for a virtual background!). Definitely a nice backdrop.

Cape Town also turns out to be a strong base for independent builders. The cost of living is relatively low, the time zone aligns well with Europe, and English is widely spoken. Many developers there work remotely for European companies, earning in pounds or euros while living on South African Rand, which creates a comfortable setup for independent work.

We also go into building products that last, resisting overengineering, and why saying no is one of the most important skills for any founder. A recurring theme is focus: building for a specific kind of user instead of trying to serve everyone.

What also caught my attention is how Herman manages his work rhythm. He does not rely on a rigid schedule. He follows what needs attention, stays mostly in maintenance mode when travelling, and recently spent a month in Japan doing just that: handling support, emails, and small fixes. No deep building, no pressure to ship. When he returned, he felt refreshed and ready to build again. He also noticed that mixing travel and deep work left him underwhelmed on both sides, so he now separates them more intentionally.

We also discussed how he uses AI. It is not part of the product itself, but it plays a specific role in his workflow, mainly for security audits and content moderation. Not as a shortcut for building features, but as a targeted tool with a clear purpose.

From a lockdown side project to a sustainable independent business, Herman shares a grounded perspective on software engineering, product design, and what it means to build something that stays useful long after launch.

A lot is covered in this episode: Why simplicity is a real competitive advantage, the dangers of overengineering, growing without traditional marketing, the special ʕ•ᴥ•ʔ growth hack that drives most of the user acquisition, how constraints often lead to better products, and the philosophy behind Bear Blog’s Manifesto, which helps Herman stay focused on what actually really matters for Bear Blog and its core values.

This episode is definitely a must-listen for all software engineers, indie entrepreneurs, founders, and anyone interested in building meaningful products with intention rather than complexity.

Herman also hosts his own podcast, “The Idea Roastery”, co-hosted with his friend Jason Forte.

Subscribe now

I’ve built plenty of projects on my GitHub over the years. Feel free to browse through for inspiration or contribution. I’ve got more exciting content coming your way on my LinkedIn. Make sure to hit that follow button so you don’t miss out!

Thanks for passing by! 🌱 If you enjoyed this interview, I’ll make more like this.

Share

APIs and web applications can become complex very quickly, and performance issues usually come from multiple small inefficiencies stacked together. Improving load speed is less about one big fix and more about identifying bottlenecks and applying optimisations at the right layer of the system.

In this tech session, we explore practical techniques to make web applications faster and more efficient across the full stack.

We start with image optimisation, since it is often one of the biggest performance drains. This includes serving images at the correct size, compressing them properly, and removing unnecessary metadata. We also look at modern formats like WebP and AVIF, which significantly reduce file size compared to PNG or JPEG. On top of that, lazy loading using the native HTML loading attribute helps defer offscreen images and improves initial page render speed.

Fonts also play a role in performance. Choosing lighter formats like WOFF2 instead of heavier TTF or OTF files can reduce load time noticeably, especially on content-heavy pages.

From there, we move into frontend and network performance. CDNs (Content Delivery Networks) help reduce latency by serving assets from locations closer to users. Preloading critical resources can also improve perceived speed by prioritising what the browser needs first. For client-side applications such as React, avoiding synchronous blocking calls and using proper asynchronous API handling helps keep the UI responsive.

We also look at how hosting location impacts performance. If your users are mostly in one region but your infrastructure is hosted far away, latency increases unnecessarily. Using multi-region deployments or edge-based services helps reduce this gap.

A key part of debugging performance issues is using browser tools effectively. Chrome DevTools provides the Network and Performance tabs to inspect request timing, payload sizes, and rendering behaviour. Lighthouse adds a structured performance score and highlights specific areas for improvement, making it easier to prioritise fixes.

On the backend, database optimisation is critical. Proper indexing in relational databases can drastically reduce query time. Tools like pgAnalyze (for Postgres) help identify slow queries and inefficient patterns. Caching is another major improvement area, using systems like Redis or Memcached to avoid repeated expensive database calls. A well-designed caching strategy can often tolerate 30–60 minute stale data windows depending on the use case.

API design also matters. REST APIs are often easier to optimise with HTTP caching headers, while GraphQL requires more careful cache management due to flexible query structures. In both cases, avoiding unnecessary requests and reducing payload size improves overall performance.

Other important techniques include pagination and limiting data transfer. Instead of loading everything at once, APIs should return only the required chunk of data. This works well alongside frontend lazy loading strategies.

Finally, serverless architectures require attention to database connections. Opening too many connections can create overhead, so proper connection pooling and cleanup is essential.

The goal of this video is to show that performance is not a single optimisation, but a collection of small improvements across images, fonts, frontend behaviour, APIs, caching, and backend systems. When combined, they produce a significantly faster and smoother user experience.

Subscribe now

Subscribe now

I’ve built plenty of projects on my GitHub over the years. Feel free to browse through for inspiration or contribution.

I’ve got more exciting content coming your way on my LinkedIn. Make sure to hit that follow button so you won’t miss out!

Here’s what’s really happening: ego, insecurity, and unclear thinking lead us straight into overengineering territory. You want to prove you’re smart, so you reach for the fancy design pattern. You’re worried the simple solution looks too basic, so you add layers of abstraction “just in case.” Or you haven’t actually clarified the problem, so you build something overly flexible to cover all possible scenarios.

But here’s the truth… The best engineers aren’t the ones writing the most clever code. They’re the ones solving problems with the least amount of complexity necessary. Because simple code is easier to debug, faster to ship, and way more reliable in production.

In this video, I’ll show you how to recognize when you’re overengineering, how to shift your mindset from “what’s the coolest solution?” to “what’s the right solution?”, and how to build cleaner, faster software that actually solves the problem at hand. Let’s talk about fighting the urge to be clever and learning to be effective instead.

Subscribe now

Psst! I’ve built tons of projects on my GitHub over the years. Check them out for inspiration or jump in to contribute! 🤠

I’ve got more content coming your way on my LinkedIn! Hit that follow button so you don’t miss out! 🎯

Subscribe now

I’ve built tons of projects on my GitHub over the years. Check them out for inspiration or contribution. I’ve got more content coming your way on my LinkedIn! Hit that follow button so you don’t miss out! 🔥

In this article, I break down the differences between Server-Side Rendering (SSR), Client-Side Rendering (CSR), and Single-Page Applications (SPA) using practical examples from real-world software engineering.

You will learn how traditional server-rendered applications work, why frameworks such as Symfony, Rails, and Django have relied on SSR through Smarty, Twig, ERB, and Jinja2 for years, why SSR applications are (often) easier and simpler to build than CSR, and how modern frontend frameworks like React changed the way we build applications by moving much of the rendering logic to the browser.

You’ll also learn why client-side rendering creates a clear separation between frontend and backend systems, what performance implications come with that choice, and when a single-page application can provide a smoother user experience for products such as dashboards, internal tools, and SaaS platforms.

Whether you’re preparing for software engineering interviews, learning web architecture, or simply trying to better understand the technologies you use every day, this article provides a straightforward explanation of these core concepts without unnecessary complexity.

By the end, you’ll understand:

• What SSR, CSR, and SPA actually mean
• How data flows in each architecture
• The advantages and disadvantages of every approach
• When to choose one over another
• Why modern applications often combine multiple rendering strategies

These concepts sit at the foundation of modern web development, and understanding them will help you make better architectural decisions for your next project.

Share

I built various projects on my GitHub over the years that might interest you. Feel free to browse them for inspiration or contribution.

And I’ve got more exciting content coming your way on my LinkedIn. Make sure to hit the follow button so you won’t miss anything.

Subscribe now

The way you start your day shapes everything that follows. In this video, I share the simple morning habits that help me show up sharper, think clearer, and code better. These aren’t complicated rituals or time-consuming routines. They’re small, deliberate actions that set the tone for deep work and consistent performance. Try them and see the difference yourself.

Subscribe now

You might be interested by this! Indeed, I’ve built many projects on my GitHub over the years that you can check out for inspiration or contribution!

I’ve got plenty more content coming your way on my LinkedIn! Hit that follow button so you don’t miss out!

Share

I have listed some of the most essential rules every software engineer should know. These principles are taken from The Pragmatic Programmer by Andy Hunt and Dave Thomas.

Algorithm speed 🚀

Although this is nothing new for any experienced engineer, you should always be careful when dealing with multiple loops.

The complexity of a simple loop is O(n). Now, if we introduce a function or method inside it that also loops over something, the complexity will immediately become O(m × n). Always consider the side effects of any change in your code to ensure there is no impact on the scalability of your application in the long term.

Best isn’t always best 💡

Be aware that premature optimisation is not always the appropriate decision at the start of any project or proof of concept (POC). At that stage, it is impossible to know the traffic or the eventual iterations and direction of your application. Instead, it is usually wiser to keep things simple and small.

Be pragmatic. Not a coincidental “Code Monkey” 💥

Coding is not a mechanical job. As a pragmatic programmer, you need to make the right decisions. You need to think critically about all code and the impact it could have, as well as how your code and software architecture will scale in the future.

On the other hand, a coincidence programmer will write code without planning or looking at the big picture. They tend to add mechanical code in an inefficient manner.

Automation 🤖

Automating things is an important concept in the lifecycle of an application. However, like optimisation, if you automate too early things that might not be repetitive, it will only add unnecessary extra hours of work.

Learn what you need 📝

Learning the right tools well (such as Jenkins, Docker, a framework, shortcuts, your favourite IDE, or a benchmarking tool) will be one of your greatest strengths in your career.

Don’t write Dodo-Code 🦤

Writing dodo code implies that your code will not adapt well over time. The dodo did not adapt to the presence of humans. They were once abundant on the island of Mauritius before going extinct. Do not give the same future to your code. Keep your codebase agile and well maintained, using good design patterns that make new changes and feature implementations easy.

Testing before production 🍳

Although this can seem obvious, too often I see last-minute “important” changes that need to be shipped to production as soon as possible. And since the software engineers do not have the time or necessary resources, they proceed with shipping the changes right away to please their manager or C-level stakeholders.

This can end up quite badly. It is always easy to underestimate what can go wrong until you wake up one morning and the entire online service is down because of a missing assignment operator or a missing semicolon or comma causing incorrect behaviour. No matter how much you trust the release, you are never 100% sure of the consequences of each change in your code. Integration and acceptance tests can be very useful here.

A good practice is also the use of the “chaos monkey” technique in your application to make sure there are no obvious issues with it.

The boy-scout rule 🧹

The Boy Scout rule says: “Always leave the campground cleaner than you found it.”

It means you should clean up even when others leave things messy, no matter the excuses. It does not matter whether you created the mess or not. The rule aims to make the codebase incrementally better, step by step, every time you touch a legacy or outdated part of the code.

So, every time you need to add or change something in an existing function or class, identify a small improvement you can also make. A tiny improvement will not introduce new problems or make the code review harder, but those small improvements, applied consistently, will make the entire codebase much cleaner over time.

Debugging mindset 🧠

Before debugging, it is important to adopt the right mindset. Debugging can be tricky and time-consuming.

Here are some rules of thumb that make this “mental digging” more pleasant 🤠:

1. Immediately think about which tier or layer of your code the problem could come from.

2. Failing early will tell you more directly where something is not working. Always fail early instead of quietly moving to the next function when something is not supposed to happen.

3. Use breakpoints and exception tracing.

4. Speaking to your rubber duck, an AI chat, or a colleague will help you see the bigger picture of what you are working on. Very often, you will have an “aha” moment when you explain what is not working, what has changed, and where you looked in the code.

5. Step back and consider the overall architecture and infrastructure to locate the problem more easily.

Rubber Duck debugging technique 🐥

Happy Debugging Day! 🤠 Enjoy solving and tackling your technical challenges! 🎯

Subscribe now

I’ve built plenty of projects on my GitHub over the years. Feel free to browse through for inspiration or contribution.

I’ve got more exciting content coming your way on my LinkedIn. So, make sure to hit that follow button so you don’t miss out!

Share

Look, this might sound controversial, but hear me out. The actual act of writing code? That’s becoming less and less of the differentiator. AI can handle everything now. What it can’t do (at least not yet) is understand the whybehind what you’re building.

The engineers who are genuinely valuable are definitely no longer the ones who can write the most maintainable lines of code in a day. They’re the ones who can look at a feature request and ask: “Wait, does this actually solve the user’s problem? Is this the right approach? What are we missing here?”

Product-oriented thinking means you’re not just executing tasks. You’re questioning requirements. You’re thinking about edge cases before you write a single function. You’re considering the long-term maintenance burden of your decisions. You’re thinking like someone who owns the outcome, not just the implementation.

And here’s the thing: this requires clear thinking. Not clever thinking. Clear thinking. The ability to break down a complex problem into simple parts, spot what actually matters, and communicate your reasoning to others. That’s the skill that separates strong engineers from everyone else.

In this video (which is quite long because I’m walking and thinking out loud), I’ll break down what this actually looks like in practice. How to shift from “just tell me what to build” to “let me understand the problem first.” How to evaluate trade-offs. How to think through second and third-order effects of your decisions. And why this mindset matters more than any specific technology you know.

Share

I’ve been building several projects on my GitHub over the years that might interest you. Feel free to check them out for inspiration or jump in with contributions!

There are so much more to come on my LinkedIn! Don’t forget to follow and stay tuned! 🔥

This video breaks down the skills and mindset that separate the two. We’re talking about the fundamentals that don’t expire when a new framework drops. Things like thinking critically about trade-offs, knowing when to optimise (and when not to), writing code that adapts over time instead of becoming legacy debt, and understanding the “why” behind what you’re building, not just the “how.”

These aren’t trendy tips or hacks. They’re the timeless principles that make you someone people actually want on their team. The kind of engineer who doesn’t just ship features but ships solutions that last.

Whether you’re just starting out or you’ve been coding for years, revisiting these core concepts will make your work sharper, cleaner, and way more effective. Let’s dive in.

I’ve developed numerous projects on my GitHub over the years. Feel free to browse them for inspiration or to contribute!

Share

In this tutorial, I explain why these apps work, what they get right compared to complex task managers, and how I use them to stay consistent without burning out. If you want fewer tools and better focus, this is a practical place to start.

Subscribe now

The Best Focus & Note-Taking Apps I Actually Use

Let me share the apps I’ve been using and that I genuinely recommend depending on your setup.

Focus Apps

Three solid options here depending on your OS and what you’re looking for.

Forest is my top pick if you’re on iOS. You pay once, that’s it. No subscription, no freemium trap. The downside is it’s iOS only, so keep that in mind.

Flora used to be fully free. Now it’s gone freemium, so you get the basics for free and pay for more features. Still decent.

FocusDog is the one worth highlighting if you’re on Android or iOS and want something with more gamification. Donuts, rewards, that kind of thing. It’s built and maintained by a single developer who also has a full-time job, and he’s kept the app alive and updated for over two years. That says a lot. It’s also the only one available on both iOS and Android, so if you’re not on iOS, this is your go-to.

For background music while working, Brain.fm does the trick very well.

Note-Taking & Bookmarking Apps

This is where it gets interesting.

Raindrop.io over Pocket, no question. Pocket is painful to search through. Raindrop makes it genuinely easy to find anything you’ve saved. Also maintained by essentially one engineer doing it full time, which is impressive.

For actual note-taking, you have a few good options:

Obsidian is probably the most powerful one out there. It’s mostly free, with a paid commercial plan. The concept is simple: your notes are linked like nodes in a graph, so finding connections between ideas becomes much easier over time. It’s not the simplest app to get started with, but once you’re in, it’s hard to go back.

Roam Research is also excellent and very powerful, accessible from the web too. The catch is the price. It’s $165 per year, or $500 for five years, so roughly $100 per year if you commit long term. Expensive, but people who use it swear by it.

Dendron is worth a mention too. It’s 100% open source, which is a big plus if that matters to you.

The Bigger Picture

The reason any of this matters is simple. You need a second brain. You are constantly consuming information, and if you don’t have a place to store and organize it, it just disappears. Note-taking apps are that external brain.

And beyond storing, the real value is teaching back what you learn. Writing it down, reorganizing it, explaining it forces your brain to actually retain it. That daily habit of learning and then reinforcing what you learned is what compounds over time 😊

I’ve built tons of product-centric projects on my GitHub over the years.

Feel free to check them out for inspiration or jump in to contribute! I’ve got more content coming your way on my LinkedIn.

Subscribe now

Every day, I review hundreds of lines of code. Brand new micro-services, new features, refactoring, hotfixes, and so on. I’ve seen so many different coding flavors, good and bad coding habits, etc. Below is everything I’ve learned for over 12 years in the industry as a software engineer.

Subscribe now

Don’t comment on what it does. Write meaningfully what it does instead

It’s crucial to name your functions and variables in simple and explicit words so that they say what they do (just by reading their names).

Self-descriptive code is very important. Your code should simply self-document itself.

If the code requires too many comments to be understood, it means the code needs to be refactored. The code has to be understood by reading it, not by reading the comments. And the same applies when you write tests. Having to justify what the code does is usually a bad sign of a code smell.

Your code has to be clear enough to document itself as well. As developers, we tend to be lazy and we don’t read (carefully) the comments. However, the code, we always do.

Icing on the cake, it’s always more rewarding and requires less time to write self-descriptive code rather than commenting it.

❌ Bad practice

let validName = false;
// We check if name is valid by checking its length
if (name.length >= 3 && name.length <= 20) {
  validName = true;
  // Now we know that the name is valid
  // …
}

const sr = 8.79; // Saving Rate

✅ Good example

const isValidName = (name) => {
  return (
    name.length >= config.name.minimum && name.length <= config.name.maximum
  );
};
// …

if (isValidName('Peter')) {
  // Valid ✅
}

const savingRate = 8.79;

Remember, your job is to write efficient and meaningful code, not endless comments.

The “One Thing” principle 1️⃣

When writing a function, remind yourself that it should (ideally) do only one (simple) thing. Think about what you have already learned concerning comments. The code should say everything. No comments should be needed. Splitting the code into small, readable functions and reusable portions of code will drastically improve your code’s readability and eliminate the need to copy/paste the same piece of code just because it hasn’t been properly moved into reusable functions or classes.

Just as individual LEGO blocks can be combined to create larger structures, your functions should be small, focused units that can be composed together to accomplish more complex tasks.

❌ Non-readable function

function retrieveName(user) {
  if (user.name && user.name !=== 'admin' && user.name.length >= 5) {
    return user.name;
  }
  // ...
}

✅ One Thing. Neat & Clean

const isRegularUser = (name) => {
  return name !=== config.ADMIN_USERNAME;
}

const isValidNameLength = (name, minimumLength = 5) => {
  return name.length >= minimumLength;
}

const isEligibleName(name) {
  return isRegularUser(name) && isValidNameLength(name);
}

// …

function retrieveName(user) {
  const name = user?.name;

  if (isEligibleName(name)) {
    return user.name;
  }
}

Uncle Bob explains this concept as “Extract Till You Drop,” where you continuously extract your code into smaller and more manageable components.

Boat anchor (AKA Tree Shaking 🌳)

Never keep unused code or commented code, “just in case” for history reasons.

Sadly, it’s still very common to find commented code in pull requests we review.

Nowadays, everybody uses a version control system like git, so there is always a history where you can look and go backward if needed.

❌ Downsides of keeping unused code

1. We think we will come back to removing it when it’s time. Very likely, we will get busy with something else and we will forget to remove it.

2. The unused code will add more complexity for a later refactoring.

3. Even if unused, it will still show up when searching in the codebase (which adds more complexity too).

4. For new developers joining the project, they don’t know if they can remove it or not.

✅ Action to take

Add a Bitbucket/GitHub pipeline or a git hook on your project level for rejecting any unused, dead, and commented code.

Minimalist code

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

— Bill Gates

Coding in a minimalist way is the best pattern you can follow! Simplicity over complexity always wins! 🏆

Each time you need to create a new feature or add something to a project, see how you can reduce the amount of code.

There are so many ways to achieve a solution. And there is always a shorter and cleaner version which should always be the chosen one.

Think twice before starting to write your code. Ask yourself “what would be the simplest and most elegant solution I can write“, so that the written code can be well-maintained over time and very easily understood by other developers who don’t have the context/acceptance criteria in mind.

Brainstorm about it. Later, you will save much more time while writing your code.

You Aren’t Gonna Need It (YAGNI)

❌ Don’t code things “just in case“ you might need it later.

Don’t spend time and resources on what you might not need.

✅ You need to solve today’s problem today, and tomorrow’s problem tomorrow.

Reuse your code across your different projects by packing them into small NPM libraries

❌ Wrong approach

My project is small (well, it always starts small).
I don’t want to spend time splitting functionalities into separated packages. Later on, somehow, my project grow bigger and bigger indeed. However, since I haven’t spent time splitting my code into packages at the beginning. Now, I think it will take even longer to refactor my code into reusable packages.
In short, I’m in a trap. My architecture is just not scalable.

✅ Right approach

Always think about reusibility. No matter how small or big is your project.

Splitting your code into small reusable external packages will always speed you up in the long run. For instance, there will be times where you will need a very similar functionality to be used in another project for another client’s application.

Whether you are building a new project from scratch or implementing new features into it, always think about splitting your code early into small reusable internal NPM packages, so other potential products will be able to benefit from them and won’t have to reinvent the wheel.
Moreover, your code will gain in consistency thanks to reusing the same packages.

Finally, if there is an improvement or bug fix needed, you will have to change only one single place (the package) and not every impacted project.

Icing on the cake, you can make public some of your packages by open source them on GitHub and other online code repositories to get some free marketing coverage and potentially some good users of your library and contributors as well 💪

🏁 Tests come first. Never last

Never wait until the last moment to add some unit tests of the recent changes you have added.

Too many developers underestimate their tests during the development stage.

Don’t create a pull request without unit tests. The other developers reviewing your PR are not only reviewing your changes but also your tests.

Moreover, without unit tests, you have no idea if you introduce a new bug. Your new changes may not work as expected.
Lastly, there will be chances you won’t get time or rush up writing your tests if you push them for later.

❌ Stop doing

Stop neglecting the importance of unit tests. Tests are there to help you developing faster in the long run.

✅ Start doing

Create your tests even before changing your code. Create or update the current tests to expect the new behavior you will introduce in the codebase. Your test will then fail. Then, update the src of the project with the desired changes.
Finally, run your unit tests. If the changes are correct and your tests are correctly written, your test should now pass 👍 Well done! You are now following the TDD development approach 💪

Remember, unit tests are there to save your day 🎉

Import only what you need

Have the good practice of importing only the functions/variables you need. This will prevent against function/variable conflicts, but also optimizing your code/improving readability by only expose the needed functions.

❌ Importing everything

import _ from 'lodash';

// …

if (_.isEmpty(something)) {
  _.upperFirst(something);
}

✅ Import only the needed ones

import { isEmpty as _isEmpty, upperFirst as _upperFirst } from 'lodash';

// …

if (_isEmpty(something)) {
  _upperFirst(something);
}

Filtering empty values from arrays the clean way

❌ Less readable way to filter out null/undefined values

names.filter((value) => value !== null && value !== undefined && value !== '');

// Note: Loose equality (!=) removes null and undefined, but keeps empty strings

✅ Clean way to filter out null and undefined values

names.filter(Boolean); // Gives only the defined names. Removes ALL falsy values

Refactoring conditions into clear functions

❌ Non-readable condition

const { active, feature, setting } = qrCodeData;

if (active && feature === 'visitor' && setting.name.length > 0) {
  // …
}

The condition isn’t easy to read, long, not reusable, and would very likely need to be documented as well (making the whole coding experience tedious).

✅ Clear boolean function

const canQrCode = ({ active, feature, setting }, featureName) => {
  return active && feature === 'visitor' && setting.name.length > 0;
};

// …

if (canQrCode(qrCodeData, 'visitor')) {
  // …
}

Here, the code doesn’t need to be commented. The boolean conditional function name says exactly what it does, producing a readable and clean code 🚀

🍰 Cherry on the cake, the code is scalable. Indeed, the function canQrCode can be placed in a service or helper, increasing the reusability and decreasing the chance of duplicating code.

Readable Name: Variables

Mentioning clear good and explicit names for your variables is critical to prevent confusion. Sometimes, we spend more time understanding what a variable is supposed to contain rather than achieving the given task.

❌ Bad Variable Name

// `nbPages` naming doesn’t mean much ❌
const nbPages = postService.getAllItems();

let res = '';
for (let i = 1; i <= nbPages; i++) {
  res += '<a href="?page=' + i + '">' + i + '</a>';
  }
}

Giving i for the name of the increment variable is a terrible idea. Although, this is the standard for showing examples with the for loop, you should never do the same with your production application (sadly, plenty of developers just repeat what they’ve learned. Of course, we can’t blame them, but it’s now time to change!).

Every time you declare a new variable, look at the best and short words you can use to describe what it stores.

✅ Good example, with a clear variable name

// `totalItems` is a much better name ✅
const totalItems = postService.getAllItems();
// …

let htmlPaginationLink = '';
for (let currentPage = 1; currentPage <= totalItems; currentPage++) {
  htmlPaginationLink +=
    '<a href="?page=' + currentPage + '">' + currentPage + '</a>';
}

Readable Name: Functions

❌ Complicated (vague/unclear) function name

function cleaning(url) {
  const specialCharacters = /[^A-Za-z0-9]/g;
  // …
  return url.replace(specialCharacters, '');
}

✅ Explicit descriptive name

function removeSpecialCharactersInUrl(url) {
  const specialCharacters = /[^A-Za-z0-9]/g;
  // …
  return url.replace(specialCharacters, '');
}

Function names are like subheadings in an article - they simply tell you what the function does.

Also, each word of a function name should be capitalized except the first letter of the function. This is known as lowerCamelCase, like isNameValid().

Readable Name: Classes

❌ Generic/Vague name

class Helper { // 'Helper' doesn't mean anything

  stripUrl(url) {
    // ...
    return url.replace('&', '');
  }

  // ...
}

The class name is vague and doesn’t clearly communicate what it does. By reading the name, we don’t have a clear idea of what Helper contains and how to use it.

✅ Clear/Explicit name

class Sanitizer { // <- Name is already more explicit

  constructor(value) {
    this.value = value;
  }

  url() {
    this.value.replace('&amp;', '');
    // ...
  }
}

In this case, the class name clearly says what it does. It’s the opposite of a black box. By saying what it does, it should also follow the single responsibility principle of achieving only one single purpose.
Class names should be a (singular) noun that starts with a capital letter. The class can also contain more than one noun. If so, each word has to be capitalized (this is called UpperCamel case).

Fail Fast principle

When applying the fail-fast principle in your code, you will throw an error or triggeran exception as soon as something goes wrong, rather than trying to proceed in an unstable state. In addition, when a function instruction fails early, you will let the other layers/tiers of your application’s architecture know about an error that needs to be treated first before proceeding to the higher-level components of your software.

Guard Clauses approach

Derived from the fail-fast principle seen earlier, the guard clauses technique is the way of leaving a function earlier by removing the redundant else {} blocks after a return statement.

Let’s see a snippet that doesn’t follow the guard clause pattern and a clean and readable example that does.

The two samples represent the body of a function. Inside the function, we have the following 👇

❌ The “not-readable” way

if (payment.bonus) {
  // … some logics
  if (payment.bonus.voucher) {
    return true; // eligible to a discount
  } else if (payment.confirmed) {
    if (payment.bonus.referral === 'friend') {
      return true;
    } else {
      return false;
    }
  }
  return false;
}

✅ Clean readable way

if (!payment.bonus) {
  return false;
}

if (payment.bonus.voucher) {
  return true;
}

if (payment.bonus.referral === 'friend') {
  return true;
}

return false;

On this example, we can notice how we could remove the complicated nested conditionals thanks to exiting the function as early as possible with the returnstatement.

.gitignore and .gitattributes to every project

When you are about to distribute your library, you should always create a .gitignoreand .gitattributes in your project to prevent undesirable files to be presented in there.

✅ .gitignore

As soon as you commit files, your project needs a .gitignore file. It guarantees to exclude specific files from being committed in your codebase.

✅ .gitattributes

When you publish your package to be used by a dependency manager, it’s crucial to exclude the developing files (such as the tests folders, .github configuration folder, CONTRIBUTING.md, SECURITY.me, .gitignore, .gitattributes itself, and so on…).
Indeed, when you install a new package through your favorite package manager (npm, yarn, …), you only want to download the required source files, that’s allwithout including the test files, pipeline configuration files, etc, not needed for production.

Demeter Law

The Demeter law, AKA the principle of least knowledge states that each unit of code should only have very limited knowledge about other units of code. They should only talk to their close friends, not to their strangers 🙃 It shouldn’t have any knowledge on the inner details of the objects it manipulates.

❌ Chaining methods

object.doA()?.doB()?.doC(); // violated deleter’s law

Here, doB and doC might receive side-effects from their sub-chaining functions.

✅ Non-chaining version

object.doA();
object.doB();
object.doC();

Each method doesn’t rely on each other. They are independent and safe from eventual refactoring.

Debugging efficiently

When debugging with arrays or objects, it’s always a good practice to use console.table()

❌ console.log(array)

console.log makes the result harder to read. You should always aim for the most efficient option.

const favoriteFruits = ['apple', 'bananas', 'pears'];
console.log(favoriteFruits);

✅ console.table(array)

Using console.table saves you time as the result is shown in a clear table, improving readability of the log when debugging an array or object.

Mozilla gives us a clear example to see how console.table can help you.

const favoriteFruits = ['apple', 'bananas', 'pears'];
console.table(favoriteFruits);

Fewer arguments is more efficient

If your functions have more than 3 arguments, it means you could have written a much better and cleaner code. In short, the purpose of your function does too much and violates the single responsibility principle, leading to debugging and reusability hells.

In short, the fewer arguments your function has, the more efficient it will become as you will prevent complexity in your code.

❌ Unclean code

function readItem(
  id: number,
  userModel: UserModel,
  siteInfoModel: SiteModel,
  security: SecurityCheck
) {}

✅ Clean code

user = new User(id);
// …
function readItem(user: User) {}

With this version, because it has only relevant arguments, reusing the function elsewhere will be possible as the function doesn’t rely or depend on unnecessary arguments/objects.

Stub/mock only what you need

When you stub an object in your tests (with Sinon for instance), it’s a good and clean practice to decide only what functions you need to stub out, instead of stubbing out the entier object. Doing so, you also prevent overriding internal implementations of functions which cause all sorts of inconsistencies in your business logic.

❌ Everything is stubbed

sinon.stub(myObject);

✅ Only the function you need is stubbed

sinon.stub(myObject, 'myNeededFunction');

Here, we only stub out the individual function we need.

Remove the redundant things

When we code, we often tend to write “unnecessary” things, which don’t increase the readability of the code either.

For instance, in a switch-statement, having a default clause that isn’t used.

❌ Redundant version

const PRINT_ACTION = 'print';
const RETURN_ACTION = 'return';
const EVENT_ACTION = 'event';
// …
switch (action) {
  case PRINT_ACTION:
    console.log(message);
    break;

  case RETURN_ACTION:
    return message;
    break; // ❌ Redundant as we already exit the `switch` with `return`

  case EVENT_ACTION:
    throw new NotImplemented("Not implemented yet");
    break; // ❌ Redundant as the code won't be reached after error is thrown

  default: // ❌ This clause is redundant as no default instruction was used
    break;
}

✅ Neat version

const PRINT_ACTION = 'print';
const RETURN_ACTION = 'return';
// …
switch (action) {
  case PRINT_ACTION:
    console.log(message);
    break;
  case RETURN_ACTION:
    return message;

  default:
    throw new Error(`Invalid ${action}`);
}

Here, we keep the default clause, but we take benefit of it by throwing an exception.

Ego is your enemy ✋

Too often I see developers taking the comments on their pull requests personally because they see what they have done as their own creation. When you receive a change request, don’t feel judged! This is actually an improvement reward for yourself 🏆

If you want to be a good developer, leave your ego in your closet. Never bring it to work. This will just slow your progression down and could even pollute your brain space and the company culture.

❌ Taking what others say as personally

✅ See every feedback as a learning experience

When you write code, it’s not your code, it’s everybody’s else code. Don’t take what you write personally. It’s just a little part of the whole vessel.

Don’t use abbreviations 😐

Abbreviations are hard to understand. For new joiners who aren’t familiar with the company’s terms. And even with common English abbreviations, they can be quite difficult to be understood by non-native English speakers who might be hired in the future or when outsourcing developers from overseas.

Having as a golden rule to never use abbreviations in your codebase (so at least, you’ll never have to take any further decisions on this topic) is critical for preventing confusion later on.

❌ Difficult to read. Hard to remember over time

if (type === Type.PPL_CTRL) {
  // We are on People Controller
  // Logic comes here
}

if (type === Type.PPL_ACT) {
  // We are on People Action
  // …
}

if (type === Type.MSG_DMN_EVT) {
  // We are on Messaging Domain Event
  // …
}

// ...

const IndexFn = () => {
  // index function
}

✅ Clear names (without comments needed 👌)

if (type === Type.PEOPLE_CONTROLLER) {
  // Logic comes here
}

if (type === Type.PEOPLE_ACTION) {
  // Logic here
}

if (type === Type.MESSAGING_DOMAIN) {
  // Logic here
}

// ...

const index = () => {
  // No need to have `Fn` or ˋFunction` as suffix in the name
  // Having ˋfunction` or ˋmethod` for an actual function is redundant and generally bad practice
  // ...
}

🇺🇸 American English spelling: The default choice when coding

I always recommend using only US English in your code. If you mix both British and American spellings, it will introduce some sort of confusion later and might lead to complications for new developers joining the development of your software.

Most of the 3rd-party libraries and JavaScript’s reserved words are written in American English. As we use them in our codebase, we should prioritize US English as well in our code.
I’ve seen codebases with words such as “licence“ and “license“, “colour“ and “color“, or “organisation“ and “organization“.
When you need to search for terms / refactor some code, and you find both spellings, it requires more time and consumes further brain space, which could have been avoided in the first place by following consistent spellings.

Finally, I’ve noticed that it’s easier to misspell words with the British spelling like typing colur instead of colour.

Destructuring array elements. Make it readable

When you need to destructure an array with JavaScript (ES6 and newer), and you want to pick up only a specific element, there is a much cleaner way than using , to skip the previous indices.

❌ Bad Way

const meals = [
  'Breakfast',
  'Lunch',
  'Apéro',
  'Dinner'
];

const [, , , favoriteMeal] = meals;
console.log(favoriteMeal); // Dinner

✅ Recommended readable way

const meals = [
  'Breakfast', // index 0
  'Lunch',     // index 1
  'Apéro',     // index 2
  'Dinner'     // index 3
];

const { 3: favoriteMeal } = meals; // Get the 4th element, at index 3
console.log(favoriteMeal); // Dinner

Here, we destructure the array as an object using its index number and give an alias name favoriteMeal to it.

Readable numbers

With JavaScript, you can use numeric separators and exponential notations to make numbers easier to read. The execution of the code remains exactly the same, but it’s definitely easier to read.

❌ Without numeric separators

const largeNumbers = 1000000000;

✅ Clear/readable numbers

const largeNumbers = 1_000_000_000;

Note: numeric separators works also with other languages than JavaScript such as Python, Kotlin, …

Avoid “else-statement”

Similar to what I mentioned concerning the importance of writing portions of code that only do “One Thing”, you should also avoid using the if-else statement.

Too many times, we see code such as below with unnecessary and pointless elseblocks.

❌ Conditions with unnecessary else {}

const getUrl = () => {
  if (options.includes('url')) {
    return options.url;
  } else {
    return DEFAULT_URL;
  }
}

This code could easily be replaced by a clearer version.

✅ Option 1. Use default values

const getUrl = () => {
  let url = DEFAULT_URL;

  if (options.includes('url')) {
    url = options.url;
  }
  return url;
}

By having a default value declared in an upper variable, we remove the need of a else {} block.

✅ Option 2. Use Guard Clauses approach

const getUrl = () => {
  if (options.includes('url')) {
    return options.url; // if true, we return `options.url` and leave the function
  }
  return DEFAULT_URL;
}

With this approach, we leave the function early, preventing complicated and unreadable nested conditions in the future.

Prioritize async/await over Promises

❌ With promises

const isProfileNameAllowed = (id) => {
  return profileModel.get(id).then((profile) => {
    return Ban.name(profile.name);
  }).then((ban) => ({
    return ban.value
  }).catch((err) => {
    logger.error({ message: err.message });
  });
}

Promises make your code harder to read and tend to increase code cyclomatic complexity.

✅ With async/await

const isProfileNameAllowed = async (id) => {
  try {
    const profile await profileModel.get(id);
    const {value: result } = await Ban.name(profile.name);
    return result;
  } catch (err) {
    logger.error({ message: err.message });
  }
}

By using async/await, you avoid callback hell, which happens with promises chaining when data are passed through a set of functions and leads to unmanageable code due to its nested fallbacks.

No magic numbers 🔢

Avoid as much as you can to hardcode changeable values which could change over time, such as the number of total posts to display, timeout delay, and other similar information.

❌ Code containing magic numbers

setTimeout(() => {
  window, (location.href = '/');
}, 3000);

getLatestBlogPost(0, 20);

✅ No hardcoded numbers

setTimeout(() => {
  window, (location.href = '/');
}, config.REFRESH_DELAY_IN_MS);

const POSTS_PER_PAGE = 20;

getLatestBlogPost(0, POSTS_PER_PAGE);

No magic strings 🧶

Similarly to magic numbers, “magic strings” are hardcoded strings that make the codebase harder to understand, more prone to typos, less flexible when the strings need to be changed, create duplication, and harder to maintain in general.

❌ Code containing magic strings

const getProviderName = () => {
  switch (this.selectedProvider) {
    case 'openai':
      return 'OpenAI';
    case 'gemini':
    default:
      return 'Gemini';
  }
}

✅ No hardcoded strings

const getProviderName = () => PROVIDER_NAMES[this.selectedProvider]
    ?? PROVIDER_NAMES[AI_PROVIDERS.GEMINI];

Another common example is storing end-user application messages in constants. This allows you to change the value of each constant key without digging into the application and changing string messages one by one.

Always use assert.strictEqual

With your test assertion library (e.g. chai), always consider using the strict equal assertion method.

❌ Don’t just use assert.equal

assert.equal('+63464632781', phoneNumber);
assert.equal(validNumber, true);

✅ Use appropriate strict functions from your assertion library

assert.strictEqual('+63464632781', phoneNumber);
assert.isTrue(validNumber);

Updating an object - The right way

❌ Avoid Object.assign as it’s verbose and longer to read

const user = Object.assign(data, {
  name: 'foo',
  email: 'foo@bar.co',
  company: 'foo bar inc',
});

✅ Use destructing assignment, spread syntax

const user = {
  ...data,
  name: 'foo',
  email: 'foo@bar.co',
  company: 'foo bar inc',
};

Stop using Date() when doing benchmarks

JavaScript is offering a much nicer alternative when you need to measure the performance of a page during a benchmark.

❌ Stop doing

const start = new Date();
// your code ...
const end = new Date();

const executionTime = start.getTime() - end.getTime();

✅ With performance.now()

const start = performance.now();
// your code ...
const end = performade.now();

const executionTime = start - end;

Lock down your object 🔐

It’s always a good idea to const lock the properties when creating an object. That way, the values of your properties object will only be read-only.

❌ Without locking an object

const canBeChanged = { name: 'Pierre' }:

canBeChanged.name = 'Henry'; // `name` is now "Henry"

✅ With as const to lock an object

const cannotBeChanged = { name: 'Pierre' } as const;

cannotBeChanged = 'Henry'; // Won't be possible. JS will throw an error as `name` is now readonly

Consider aliases when destructing an object

❌ Without aliases

const { data } = getUser(profileId);
const profileName = data.name;
// ...

✅ With clear alias name

const { data: profile } = getUser(profileId);
// then, use `profile` as the new var name 🙂
const profileName = profile.name;
// ...

Always use the strict type comparison

When doing some kind of comparison, always use the === strict comparison.

❌ Don’t use loose comparisons

if ('abc' == true) {
} // this gives true ❌

if (props.address != details.address) {
} // result might not be what you expect

✅ Use strict comparisons

if ('abc' === true) {
} // This is false ✅

if (props.address !== details.address) {
} // Correct expectation

Avoid using default exports as much as you can

The main reason you should avoid using export default is that it makes refactoring more complex when you need to rename a class or component.
You will have to update every name of your imports to match the new name of the default-exported class, function, or component.

In large-scale projects, this not only takes more time, but also increases the risk of forgetting to rename an import (or introducing a typo).

Using named exports instead allows your IDE’s IntelliSense to detect and auto-import correctly during refactoring, which doesn’t happen as easily with a renamed default export.

At the end of the day, however, being consistent within your project and team regarding coding style and conventions is also an important factor to consider.

Always write pure functions

If a tree falls in the woods, does it make a sound?
If a pure function mutates some local data in order to produce an immutable return value, is this okay?

— Rich Hickey. Creator of the Clojure

Given a specific input (argument) to a function, a pure function always returns the same output as the pure function doesn’t modify their input values.

A pure function will never produce side effects, meaning that it doesn’t change any external states from another function. The pure function only depends on its input arguments and on the function’s scope itself. With them, you can focus your attention in only one place, which makes a huge difference when reading and debugging your code.

// A pure function
function addition(x, y) {
    return x + y;
}

A trickier scenario can occur when you are passing an object.
Imagine you are passing a “user” object to another function. If you modify the object “user” in the function, it will modify the actual user object because the object passed in as a parameter is actually a reference of the object, which is the opposite of a distinct new cloned object.

To prevent this downside, you will have to deep-clone the object first (you can use the Lodash cloneDeep function) and then Object.freeze(copyUser) when returning it. This will guarantee the “copyUser” to be immutabled.

For instance:

import { cloneDeep as _cloneDeep } from 'lodash';

function changeUser(user) {
  // copyUser = { …user };
  const copyUser = _cloneDeep(user);
  copyUser.name = 'Edward Ford';

  return Object.freeze(copyUser);
}

Here, by writing pure functions, you will make the code maintainable and easy to understand. You only need to focus your attention on the function itself without having to look at the surrounding environments, states, and properties outside the function’s scope, preventing you from spending hours debugging.

Don’t overcomplicate things

Sometimes, it’s tempting to make our code prettier for no reason. Keep it simple unless it affects the readability or scalability of our code.

For instance, let’s imagine a function that generates lorem ipsum text for us. Currently, we have one option to be formatted as markdown.

const generateText = (options = {}) => {
  // ...
};

// Generate some lorem ipsum sentences
generateText();

We could be tempted to destructure the options variable like below:

const generateText = ({ markdownFormat = false } = {}) => {
  // ...
};

However, you can already notice that our function’s signature has gotten bigger. Similar to the above function, to keep the function’s arguments optional in JavaScript, we need to assign our destructured object with a default empty object as = {} to ensure that the destructuring doesn’t fail if no argument is passed to the function. Then, we need to initialize the markdownFormat property with a default value (e.g. false). All of this noise adds complexity to our code. Later on, let’s imagine we need to support other output formats such as AsciiDoc and reStructuredText.

Our function becomes the following:

const generateText = ({
  markdownFormat = false,
  reStructuredTextFormat = false,
  asciiDocFormat = false
} = {}) => {
  // ...
};

Instead, keeping the first function’s signature, const generateText = (options = {}) => { /* ... */ }, where it handles the options inside the function body, is a wiser choice as it provides more flexibility and scalability when we need to add additional output formats:

const generateText = (options = {}) => {
  if (options.markdownFormat) {
    // ...
    const output = loremIpsum.toMarkdown();
    return output;
  }

  if (options.reStructuredTextFormat) {
    // ...
    const output = loremIpsum.toReST();
    return output;
  }

  if (options.asciiDocFormat) {
    // ...
    const output = loremIpsum.toAsciiDoc();
    return output;
  }

  // ...
};

Use the TODO and FIXME prefix in your comments (when really need to comment)

If you have to come back and change something later, you might need to comment in your code, but then you must use the TODO or FIXME prefix, so that your code will be highlighted in the majority of IDEs.

Finally, I would also suggest you the VS Code extension TODO Tree that cretes a nice todo list.

✅ Example 👇

// TODO <JIRA-TICKET-ID> Change the logic to reflect to the release of productB
function somethingMeaningful() {}

Linters and Formatters

Indentation is also very important. Having consistent code that follows the same coding conventions across your products will help to ship clean and readable code.

For doing so, it’s crucial to use ESLint and Prettier on your code editor (e.g., VS Code) as well as set up some git hooks (on pre-commit or pre-push hook) which will run ESLint as a pre-check for when you git commit/push your code.

Finally, you can very easily set up a GitHub workflow action for your project.

Conclusion

Writing clean and readable code that scales is crucial for tomorrow’s development and maintenance. When we write code for a job, it is not our code; it is everybody else’s code. Writing code that does not require unnecessary cognitive effort helps prevent misunderstandings and errors that could have been easily avoided by making the code easy to understand, where it clearly shows what it does right away.

Subscribe now

The engineers who thrive in the next five years won’t be the ones clinging to old playbooks. They are the ones who understand how to work alongside AI, architect complex systems, and solve problems that require human judgment and creativity. This video breaks down what’s changing, what’s staying, and how you can position yourself ahead of the curve.

I’ve been building several projects on my GitHub over the years that might interest you. Feel free to check them out for inspiration or jump in with contributions! There are so much more to come on my LinkedIn as well! Don’t forget to follow and stay tuned! 🔥

Share

Subscribe now

Understanding Zero-Downtime Deployment

Zero-downtime deployment means deploying new application versions to production without any service interruption. Users continue using your application normally while updates roll out in the background.

The core principle is maintaining service availability throughout the entire deployment process. This approach represents the best possible deployment scenario since teams can introduce new features and fix bugs without causing outages.

Blue-Green Deployment

Blue-Green deployment is one of the most straightforward approaches to zero-downtime deployment. The concept is simple despite its colorful name.

How Blue-Green Deployment Works

The strategy involves running two identical production environments simultaneously:

• Blue Environment: Currently serves live traffic with the existing version

• Green Environment: Receives the new version deployment and testing

The deployment process follows these steps:

1. Preparation: Your blue environment serves production traffic

2. Deployment: Create an identical green environment and deploy the new version

3. Testing: Run comprehensive smoke tests and sanity checks on the green environment

4. Traffic Switching: Redirect traffic from blue to green once confident in the new version

5. Monitoring: Keep both environments running temporarily for quick rollback if needed

6. Cleanup: Decommission the blue environment after confirming stability

Traffic Migration Strategies

When transitioning from blue to green, you have two primary approaches:

Immediate Switch: Redirect all traffic at once to the new environment. This approach is faster but carries higher risk if issues arise.

Gradual Migration: Start by routing a small percentage of traffic to the green environment, gradually increasing the load as confidence grows. This method provides better risk mitigation and allows for real-world testing under production conditions.

Blue-Green Deployment Checklist

For successful blue-green deployments, maintain this checklist:

• [ ] Both environments are operational and properly configured

• [ ] Comprehensive testing completed on the new environment

• [ ] Traffic routing mechanism is ready and tested

• [ ] Monitoring and alerting systems are in place

• [ ] Rollback procedures are documented and tested

• [ ] Database migrations are compatible with both versions

• [ ] Load balancer configuration is updated appropriately to adjust the traffic accordingly

Canary Releases: Risk-Controlled Deployment

Canary releases offer a more sophisticated approach to risk management during deployments than blue-green deployment alone.

The Canary Release Philosophy

Named after canaries used in coal mines to detect dangerous gases, canary releases expose new software versions to a small, controlled subset of users before full deployment. This strategy identifies potential issues early while minimizing the impact of any problems.

Implementing Canary Releases

The canary release process follows these stages:

1. Initial Deployment: Deploy the new version alongside the existing one, but route no user traffic to it

2. Selective Exposure: Begin routing a small percentage of users to the new version

3. Monitoring and Analysis: Carefully monitor both business metrics and operational indicators

4. Gradual Expansion: Progressively increase the user base exposed to the new version

5. Full Rollout: Migrate all users to the new version once confidence is established

6. Cleanup: Remove the old version after confirming stability

User Selection Strategies

Choosing which users see the new version is crucial for effective canary releases:

Random Sampling: Select users randomly, providing an unbiased sample of your user base.

Internal Users First: Deploy to employees and internal stakeholders before external users, allowing for thorough testing in a controlled environment.

Demographic-Based Selection: Choose users based on specific characteristics, geographic location, or usage patterns that align with your testing objectives.

Geographic Rollout: In distributed systems, deploy to specific regions or data centers before global rollout.

Advanced Canary Strategies

Large-scale organizations often employ sophisticated canary approaches:

Multi-Stage Canaries: Companies like Facebook use multiple canary stages, starting with internal employees who have feature flags enabled to detect issues early.

Partition-Based Deployment: Instead of user-based routing, deploy to specific service instances, geographic regions, or business units.

Capacity Testing: Use canary releases to validate performance characteristics under real production load without risking the entire user base.

Canary Releases vs. A/B Testing

While canary releases and A/B testing share similar technical implementations, they serve different purposes:

Canary Releases focus on risk mitigation and detecting regressions or operational issues with new software versions.

A/B Testing aims to validate hypotheses about user behavior and business metrics using different feature variants.

Mixing these concerns can interfere with results and create confusion. A/B tests typically require days or weeks to achieve statistical significance, while canary rollouts should complete within hours.

Managing Complexity and Challenges

Version Management

Both blue-green and canary deployments require managing multiple software versions simultaneously. While this increases operational complexity, the benefits typically outweigh the costs. Best practices include:

• Minimizing the number of concurrent versions in production

• Implementing robust version tracking and monitoring

• Automating deployment and rollback procedures

• Maintaining clear documentation for each version

Database Considerations

Database schema changes present unique challenges in zero-downtime deployments. The Parallel Change pattern offers an effective solution:

1. Expand: Modify the database to support both old and new application versions

2. Migrate: Deploy the new application version while maintaining backward compatibility

3. Contract: Remove support for the old version once migration is complete

This approach ensures database compatibility throughout the deployment process.

Client-Side Applications

Deploying client-side applications (mobile apps, desktop software) presents additional challenges since update timing is beyond your control. Strategies include:

• Using feature flags to control functionality rollout

• Maintaining backward compatibility for extended periods

• Implementing graceful degradation for unsupported client versions

• Monitoring client version distribution to inform deprecation decisions

Implementation Considerations

Infrastructure Requirements

Successful zero-downtime deployments require:

Load Balancing: Required for traffic routing between environments. Solutions include cloud-based load balancers, nginx, HAProxy, or service mesh technologies.

Monitoring and Observability: Comprehensive monitoring of both business and operational metrics is crucial for detecting issues early.

Automation: Manual processes are error-prone and slow. Invest in automation for deployments, testing, and rollbacks.

Infrastructure as Code: Ensure environments can be reliably reproduced and configured consistently.

Cloud vs. On-Premises

Cloud platforms offer managed services that simplify zero-downtime deployments:

AWS: Route 53 for DNS routing, Application Load Balancer for traffic distribution, and services like CodeDeploy for automated deployments.

Other Cloud Providers: Similar services are available across major cloud platforms.

On-Premises: Requires more manual setup but remains achievable with proper tooling and processes.

Best Practices and Recommendations

Planning and Preparation

• Design applications with zero-downtime deployment in mind from the beginning

• Implement comprehensive testing strategies including unit, integration, and end-to-end tests

• Practice deployment procedures regularly in non-production environments

• Maintain detailed runbooks for both deployment and rollback procedures

Monitoring and Metrics

• Define clear success criteria for deployments

• Monitor both technical metrics (error rates, response times) and business metrics (conversion rates, user engagement)

• Set up automated alerting for anomalies

• Establish baseline metrics before deployments for comparison

Risk Management

• Start with smaller, less critical applications to build expertise

• Always have a tested rollback plan

• Communicate deployment schedules with stakeholders

• Consider the timing of deployments to minimize business impact

Conclusion

Zero-downtime deployment strategies like blue-green deployment and canary releases have become standard practices for modern software delivery. These approaches enable organizations to ship features rapidly while preserving service reliability.

Blue-green deployment provides a solid foundation with its straightforward approach to maintaining two production environments. Canary releases build upon this concept by adding sophisticated risk management through gradual user exposure and comprehensive monitoring.

The choice between these strategies—or a combination of both—depends on your specific requirements, risk tolerance, and operational capabilities. Regardless of the chosen approach, investing in zero-downtime deployment practices improves user satisfaction, reduces business risk, and increases deployment confidence.

As software delivery continues to accelerate, mastering these deployment strategies becomes increasingly important for DevOps and FullStack engineers seeking to balance innovation speed with operational stability. Start with solid fundamentals, invest in proper tooling and automation, and more importantly, continuously refine your processes based on real-world experience.

Subscribe now

Hopefully this helps! I wish you a wonderful happy deploying day!

You can check out my open-source projects I’m working on at GitHub.com/pH-7

🏁 Follow my Software Engineering Journey on PierreHenry.Dev

Share

In this video, I share how I decide what to build, what to ignore, and how AI fits into that decision process without creating noise or wasted effort.

Subscribe now

Subscribe now

I’ve built tons of product-centric projects on my GitHub over the years. Feel free to check them out for inspiration or contribution.

I’ve also got exclusive content coming soon on my LinkedIn. Don’t forget to follow so you won’t miss out! 🔥

Subscribe now

Subscribe now

Key Lessons

1. Slow down before you touch anything

Most people rush. Strong problem solvers pause, read the error, inspect the context, and understand what is actually failing. This gives clarity before any action.

2. Break the problem into tiny parts

Take a messy issue and split it into small checks.

What works? What does not? Where does the behaviour change?

This lets you isolate the real cause instead of guessing.

3. Always reproduce the issue first

If you can trigger the bug on demand, you are already halfway to a fix. Engineers who skip this step stay stuck longer.

4. Write down everything you test

Keep a short log while debugging. It prevents going in circles, and it helps you reason like an investigator.

5. Learn one tool at a time, deeply

Debuggers, profilers, logs, CLI tools. Being able to inspect a system properly is more valuable than memorising syntax.

6. Stay calm even when things look bad

Good engineers do not panic when a system fails. They follow a method. Calm thinking is a competitive edge.

I’ve been building several projects on my GitHub over the years that might interest you. Feel free to check them out for inspiration or jump in with contributions!

There are so much more to come on my LinkedIn as well! Don’t forget to follow and stay tuned! 🔥

Share