Coder Legion - Recent posts tagged cleancode

My Journey as a Software Engineer: Building Solutions, Solving Problems, and Never Stopping Learning

Mon, 12 Oct 2026 05:42:57 +0000

Software engineering is more than writing code. It is about understanding problems, thinking logically, designing solutions, and building software that makes people's lives easier.

As a software engineer, I enjoy turning ideas into practical applications. Every project brings a new challenge, whether it is fixing a difficult bug, improving application performance, designing a better database structure, or finding a simpler way to solve a complex problem.

For me, the most interesting part of software development is the process of figuring out how things work and discovering better ways to build them.

Coding Is Only One Part of Software Engineering

When people think about software engineers, they often imagine someone sitting in front of a computer and writing code all day. In reality, software development involves much more than that.

Before writing code, we need to understand the problem. We need to ask the right questions, identify requirements, consider different approaches, and choose a solution that fits the situation.

Sometimes, the hardest part of a project is not implementing a feature. It is understanding what the feature should actually do.

A good software engineer does not simply ask, "How can I write this code?" Instead, the more important question is, "What is the best way to solve this problem?"

That difference can have a major impact on the quality of the final product.

Learning to Write Clean and Maintainable Code

Writing code that works is important, but writing code that other developers can understand and maintain is equally valuable.

In the beginning, it can be tempting to focus only on getting the expected result. However, as applications grow, poorly organized code becomes harder to debug, test, and improve.

Clean code helps developers understand the purpose of a function, follow the flow of an application, and make changes without introducing unnecessary problems.

Some practices I consider important in software development include:

Choosing meaningful names for variables, functions, and classes.
Keeping functions focused on specific responsibilities.
Avoiding unnecessary duplication.
Organizing projects into understandable structures.
Handling errors properly instead of ignoring them.
Writing tests for important functionality.
Refactoring code when a better approach becomes clear.

Clean code does not mean making every solution complicated with design patterns or unnecessary abstractions. It means making the code as simple and understandable as the problem allows.

The goal is not just to make code work today. It is to make it easier to work with tomorrow.

Debugging: Where Real Learning Happens

Every developer encounters bugs. Sometimes, an application crashes unexpectedly. Sometimes, a feature works perfectly in one situation but fails in another. Other times, the problem comes from a database query, an API response, or an assumption that turns out to be incorrect.

Debugging can be frustrating, especially when the cause of a problem is not immediately obvious.

However, debugging is also one of the best opportunities to improve as an engineer.

Instead of randomly changing code, I believe in following a structured approach:

Understand the problem. Reproduce the issue and identify what should happen versus what actually happens.

Investigate the cause. Review relevant code, logs, inputs, database records, and API responses.

Test assumptions. Avoid guessing. Check each possible explanation using evidence.

Apply a focused fix. Solve the underlying problem rather than hiding the symptoms.

Verify the result. Test the fix and make sure it does not break existing functionality.

This process helps build a deeper understanding of how applications behave. Over time, each difficult bug becomes an opportunity to develop stronger problem-solving skills.

Choosing the Right Technology for the Problem

The software industry changes quickly. New programming languages, frameworks, libraries, and development tools appear regularly.

It is easy to feel that a developer must learn every new technology to remain relevant. I believe a better approach is to focus on strong fundamentals while exploring technologies that solve real problems.

Understanding data structures, algorithms, databases, networking, APIs, security, and software architecture provides a foundation that remains useful across different technology stacks.

Frameworks may change, but the ability to analyze requirements, design reliable systems, and reason about code continues to matter.

When choosing a technology, I would consider factors such as project requirements, performance, maintainability, security, available expertise, and long-term support.

The newest tool is not always the best tool. The right choice is the one that fits the problem and the people who will maintain the solution.

Building Software That Solves Real Problems

One of the most rewarding parts of software engineering is seeing an idea become something useful.

A well-designed application can automate repetitive work, organize information, improve business processes, reduce errors, or help people make better decisions.

But useful software does not necessarily need to be large or complicated.

A small script that saves someone hours of repetitive work can be just as valuable as a large application. A simple dashboard that makes important information easier to understand can have a meaningful impact on a business.

I believe developers should focus on the value their software provides rather than measuring success only by the number of features, lines of code, or technologies used.

The best solutions often come from understanding users, identifying unnecessary complexity, and solving the actual problem with the simplest effective approach.

The Importance of Testing and Code Quality

A feature that works once is not necessarily a reliable feature.

Software needs to handle different inputs, unexpected situations, invalid data, network failures, and changes in its environment. Without proper testing, even a small update can introduce problems elsewhere in an application.

Testing helps developers identify issues before users experience them. It also provides confidence when modifying existing functionality.

Depending on the project, useful practices can include unit testing, integration testing, API testing, code reviews, and automated deployment checks.

Code quality also involves security, performance, accessibility, and maintainability. These considerations should not be treated as optional improvements that only matter when a project becomes large.

Building good habits early makes it easier to develop software that people can depend on.

Adapting to AI and Modern Development Tools

Artificial intelligence is changing the way developers approach everyday work. AI-powered tools can help explain unfamiliar code, suggest implementations, generate test cases, identify possible bugs, and speed up repetitive tasks.

I see these tools as useful assistants, but not replacements for engineering judgment.

Generated code still needs to be reviewed. Suggested solutions may contain security issues, incorrect assumptions, inefficient logic, or unnecessary complexity.

A developer must understand what the code does, why it works, and whether it satisfies the actual requirements.

The most effective approach is to combine modern tools with fundamental engineering skills. Use automation where it helps, but continue developing the ability to reason independently and evaluate the results.

Technology can make certain tasks faster, but understanding the problem remains essential.

Continuous Learning Is Part of the Job

Software engineering is a field where learning never really ends.

Even experienced developers encounter unfamiliar systems, new requirements, unexpected technical limitations, and technologies they have never used before.

I believe continuous learning works best when it is connected to practical experience. Reading documentation and watching tutorials can provide useful knowledge, but building projects helps turn that knowledge into real skills.

Working on side projects, experimenting with new tools, reading other developers' code, reviewing mistakes, and discussing technical ideas with the community can all contribute to professional growth.

Not every experiment will succeed. Some approaches will need to be redesigned, and some solutions will reveal better alternatives after implementation.

That is part of the process.

The important thing is to remain curious, learn from mistakes, and keep improving.

My Perspective on Becoming a Better Software Engineer

For me, becoming a better software engineer is not about knowing everything. It is about developing the ability to learn, think critically, solve problems, and make thoughtful technical decisions.

I want to keep improving the way I approach problems, write code, structure applications, and evaluate different solutions.

I also believe sharing knowledge is an important part of the developer community. A lesson learned while solving a difficult problem might help another developer avoid the same mistake. A different perspective might reveal a simpler solution that I had not considered.

That is one reason I value connecting with other developers and learning from their experiences.

Every project has something to teach us. Every bug can reveal something about a system. Every new challenge gives us an opportunity to improve.

Final Thoughts

Software engineering is a continuous process of building, testing, learning, and improving.

Writing code is important, but understanding the problem, choosing the right approach, maintaining quality, and considering the people who use the software are equally important.

My goal is to continue growing as a software engineer by building practical solutions, strengthening my technical knowledge, exploring useful technologies, and sharing what I learn along the way.

Good software is not just about making something work. It is about making something useful, reliable, understandable, and easier to improve.

I would love to hear from other developers: What has helped you grow the most as a software engineer building projects, solving difficult bugs, learning new technologies, or collaborating with other developers?

Let's keep learning, building, and sharing our experiences.

Demystifying Dependency Injection: Writing Code That Doesn't Break When Things Change

Fri, 04 Sep 2026 06:30:09 +0000

What is Dependency Injection?

Dependency Injection is a software design pattern where a program component receives the external resources or tools it needs to function from the outside, rather than creating them itself. In simpler terms, instead of a program hardcoding its own helpers internally, those helpers are 'injected' or passed into it when it starts up. This simple shift in responsibility makes your code incredibly flexible, highly reusable, and easy to modify without breaking existing features.

The Hybrid Car Battery Analogy

To understand this concept, imagine you are building a modern hybrid car. If you permanently solder a proprietary brand of battery directly to the car's frame and engine, you have a tightly coupled system. If that battery eventually degrades, or if a cheaper, more efficient battery is manufactured next year, you are in trouble. You would have to dismantle the entire car just to swap out the battery.

Instead, car manufacturers design a standardized battery compartment with a universal plug. The car's engine does not care about the internal chemistry or brand of the battery, as long as it fits the plug and delivers the expected voltage. The battery is 'injected' into the car from the outside. If you need to change the battery, you simply unplug the old one and slide in the new one. The car remains untouched.

Why Dependency Injection Matters Every Day

In professional software engineering, tight coupling is a primary cause of technical debt and broken deployments. Without Dependency Injection, developers cannot easily test their code in isolation. For instance, if a checkout system creates its own connection to a payment provider like Stripe inside its code, you cannot run automated tests on the checkout system without accidentally triggering real API calls and charging real credit cards.

By using Dependency Injection, engineers can swap out the real payment service for a fake 'mock' service during testing. This allows test suites to run in milliseconds without relying on external servers or risking financial errors. Furthermore, when business requirements inevitably pivot—such as switching your payment processor from Stripe to PayPal—you only have to write a new adapter and inject it at startup, rather than rewriting the core checkout logic. This prevents bugs from creeping into unrelated parts of your codebase.

Dependency Injection in Action

Let's look at how this looks in JavaScript code. First, we will examine code that does not use Dependency Injection, followed by the improved version that does.

// WITHOUT DEPENDENCY INJECTION (Tightly Coupled)
class CheckoutProcess {
  constructor() {
    // The checkout process is locked into Stripe; we cannot easily change or mock this
    this.paymentService = new StripeProcessor();
  }

  completeOrder(order) {
    this.paymentService.charge(order.amount);
  }
}

// WITH DEPENDENCY INJECTION (Loosely Coupled)
class DecoupledCheckoutProcess {
  constructor(paymentService) {
    // The payment service is injected from the outside
    this.paymentService = paymentService;
  }

  completeOrder(order) {
    this.paymentService.charge(order.amount);
  }
}

// Usage in production:
const stripe = new StripeProcessor();
const productionCheckout = new DecoupledCheckoutProcess(stripe);

// Usage in automated testing (injecting a fake helper instead):
const fakeMockProcessor = {
  charge: (amount) => console.log('Simulated charge of $' + amount)
};
const testCheckout = new DecoupledCheckoutProcess(fakeMockProcessor);

The Takeaway

Ultimately, Dependency Injection changes how you think about software architecture by turning hardcoded, rigid applications into collections of plug-and-play modules. By separating how a tool is configured from how that tool is actually used, you create a codebase that is inherently stable, highly testable, and ready to adapt to whatever changes your users or business stakeholders demand tomorrow.

Resources

GitHub Repository: react-hook-lab
react-hook-lab: npm package
Connect with me on LinkedIn: Saurav Pandey

Originally published on my blog. You can read the alternative breakdown here.

Your Code Works. But Can Someone Else Understand It?

Mon, 17 Aug 2026 12:17:23 +0000

We often celebrate code that works.

The feature is complete.
The tests pass.
The deployment succeeds.

So we move on.

But there is another question developers should ask:

“Will another developer understand this code six months from now?”

Because code isn't written only for computers.

It's also written for humans.

The hidden cost of confusing code

Consider a function with:

unclear variable names
complicated conditions
deeply nested logic
unnecessary abstractions
comments explaining what the code does instead of why

It may work perfectly today.

But when someone needs to modify it later, they first have to understand it.

That understanding has a cost.

And in a large codebase, that cost becomes expensive.

Readability is a productivity feature

Readable code doesn't mean every line needs a comment.

Often, simple structure is better than more documentation.

Instead of:

x, y, tmp

use names that explain intent.

Instead of one 100-line function, ask whether it can be divided into smaller responsibilities.

Instead of clever code, prefer code that another developer can understand quickly.

The best code is often the code that doesn't require a meeting to explain.

Think about your future self

Here's a simple test:

Open something you wrote 6 months ago.

Ask yourself:

“If I had to modify this today, how long would it take me to understand it?”

If the answer is:

“Why did I write it like this?”

You're not alone.

That's one of the best reminders that maintainability matters.

Before you finish your next feature

Take 10 minutes and ask:

Can I make this easier to read?
Are the names clear?
Is each function doing one understandable thing?
Can I remove unnecessary complexity?
Would a new developer understand the intent?

Those 10 minutes today can save hours later.

Code that works is good.
Code that is easy to understand is valuable.
Code that remains understandable months later is excellent engineering.

What is the first thing you look for when reviewing someone else's code?

Sumita
Web Developer

The Feature Is Done… So Why Is the Project Still Getting Slower?

Tue, 11 Aug 2026 10:15:38 +0000

The Feature Is Done… So Why Is the Project Still Getting Slower?

One of the biggest problems in software development isn't writing bad code.

It's continuously adding "small" features without accounting for their accumulated cost.

A new filter here.

Another API endpoint there.

One more database query.

A new notification system.

A few extra configuration options.

Individually, none of these seem dangerous.

But eventually, the application becomes harder to understand, harder to test, and slower to change.

Every Feature Has a Maintenance Cost

When a feature is requested, teams usually ask:

"How long will it take to build?"

A better question is:

"How much complexity will this feature add to the system?"

A feature can introduce:

New database tables
New API contracts
Additional dependencies
More edge cases
More tests
More monitoring
More documentation
More support requests

The implementation might take two days.

The maintenance cost might last for years.

Complexity Compounds

Imagine your application starts with 10 important components.

Then you add:

Authentication
Payments
Notifications
Reporting
Search
Analytics
Integrations
Permissions

Each new feature interacts with existing functionality.

Soon you're not managing 20 independent features.

You're managing the relationships between them.

That's where complexity becomes expensive.

A small change in one area can unexpectedly affect another.

The Hidden Cost of "Flexible" Systems

Developers often try to make systems flexible.

That's usually a good instinct.

But flexibility can become another form of complexity.

For example:

Simple:

createUser(name, email)

Flexible:

createUser({
  name,
  email,
  role,
  permissions,
  organization,
  metadata,
  preferences,
  notificationRules,
  featureFlags,
  customFields
})

The second version looks powerful.

But every additional option creates more combinations that developers need to understand and test.

Flexibility isn't free.

Features Also Create Permanent Decisions

A feature isn't just code.

It creates decisions.

Once an API is released, users may depend on it.

Once a database structure is created, changing it can become difficult.

Once a configuration option exists, someone will eventually use it.

Once a behavior becomes public, removing it can become a breaking change.

That's why some "temporary" solutions live for years.

Before Adding a Feature, Ask Three Questions

1. Who actually needs it?

If only one person requested it, understand the real problem first.

Sometimes the requested feature is just one possible solution.

2. What existing behavior will it affect?

Look beyond the new code.

Check:

APIs
Database
Authentication
Caching
Background jobs
Monitoring
Existing users

3. Can we solve the problem with less code?

The best feature isn't always the biggest implementation.

Sometimes the right solution is:

Remove complexity instead of adding functionality.

The Most Valuable Feature Might Be Removing One

Software teams often measure progress by what they add.

But deleting something can create enormous value.

Removing:

An unused endpoint
An obsolete dependency
An old feature flag
A duplicate service
A complicated configuration
Dead code

can make the entire system easier to maintain.

Less software is often easier software.

Don't Confuse Activity With Progress

A team can ship dozens of features and still make the product worse.

More code doesn't automatically mean more value.

More tickets closed doesn't automatically mean better software.

More configuration doesn't automatically mean more flexibility.

The goal isn't to maximize the amount of software we create.

The goal is to maximize useful outcomes while keeping the system understandable.

Final Thought

Every feature has two costs:

The cost of building it.

And:

The cost of carrying it forever.

Good developers think about both.

Before adding another feature, ask whether you're solving a real problem—or simply making the system more complicated.

Because the hardest code to maintain isn't necessarily bad code.

Sometimes it's perfectly good code that should never have existed in the first place.

Sumita
Web Developer

The Architectural Trap: Accessing CONST Attributes Across a Series of Classes

Sat, 18 Jul 2026 06:19:57 +0000

When building scalable systems, we often need a collection of classes to expose a fixed, read-only configuration value. Whether it is a unique API_ENDPOINT, a DATABASE_TABLE name, or a specific PERMISSIONS_MASK, handling constants across a series of classes looks simple on day one but can quickly turn into an architectural nightmare.

Setting the Foundation: How to Make It

In modern object-oriented programming, the standard way to declare a constant on a class is by leveraging the static readonly modifiers. This ensures the attribute belongs to the class itself, rather than an instance, and cannot be mutated at runtime.

TypeScript
class BillingService {
static readonly SERVICE_TYPE = "BILLING";
}

class InventoryService {
static readonly SERVICE_TYPE = "INVENTORY";
}
This works perfectly when you know exactly which class you are dealing with at compile time. You simply call BillingService.SERVICE_TYPE and move on.

The Architectural Breakdown: What Will Be the Problems

The clean code facade breaks the moment you attempt to handle these classes dynamically. In production environments, you rarely hardcode class names; instead, you process them as an array or a series of registry keys.

Loss of Type Safety: If you pass a series of these classes into a processing function, standard type systems will treat them as generic constructor functions, wiping out access to the static property unless you resort to unsafe type casting.

Polymorphism Failure: Subclasses do not inherently enforce or override static properties cleanly through standard interfaces. You cannot enforce a static readonly property on an interface, meaning a developer could easily forget to define the constant on a new service class, causing silent runtime failures.

Instance vs. Class Metadata Confusion: If your architecture receives an instance of the class rather than the class definition itself, accessing the static attribute requires jumping through hoops like instance.constructor.SERVICE_TYPE, which breaks clean abstraction barriers.

The Modern Solution: Enforcing Metaclasses and Registry Maps
To resolve this elegantly, we must combine strongly typed class constructors with structural interfaces to enforce static attributes at the compiler level.

Define a Constructor Interface: Create a specialized type that explicitly mandates the presence of the static constant on the class constructor itself.

Leverage a Centralized Registry: Pass the series of classes through a strongly typed registry array, ensuring the compiler validates every single class before the application even boots.

TypeScript
// Enforce the static attribute via a Constructor Interface
interface ServiceConstructor {
new (...args: any[]): any;
readonly SERVICE_TYPE: string; // The magic line that enforces the static property
}

// A processing loop that safely extracts the CONST attribute
function initializeServices(services: ServiceConstructor[]) {
services.forEach((ServiceClass) => {

// Perfectly type-safe, auto-completed, and validated
const serviceName = ServiceClass.SERVICE_TYPE;
console.log(`Deploying system module: ${serviceName}`);

});
}

// Registering the series of classes
initializeServices([BillingService, InventoryService]);
By shifting the validation to the type engine, you eliminate runtime tracking bugs entirely and make your codebase highly resilient to future extensions.

Visit our official site: www.nextbigcreative.com

How to Format SQL Queries for Better Readability

Thu, 09 Jul 2026 12:43:06 +0000

You know the feeling. Someone shares a query in Slack, or you open a .sql file left behind by a developer who's long gone, and it's just... one giant wall of text. Lowercase here, uppercase there, no line breaks, five joins crammed into a single sentence. You end up scrolling sideways just to figure out what table a column came from.

That's not a "them" problem. Every SQL developer has written a query like that under deadline pressure. But queries get read far more often than they get written, and a badly formatted one costs everyone — including future you — real time.

This guide walks through practical, no-nonsense SQL formatting best practices you can start using today. Every rule comes with a before-and-after example, so you can see exactly why the "after" version is easier to work with.

Why SQL Readability Matters

SQL isn't a private notebook. It's a shared language between developers, analysts, and database administrators — often people who didn't write the original query and have no context for it.

Readable SQL matters because:

You'll debug faster. When a report breaks at 2 AM, you don't want to spend twenty minutes just figuring out what a query does before you can even start fixing it.
Code reviews go quicker. A reviewer can catch a logic error in seconds when the structure is clear. They can't catch anything in a 400-character single line.
Onboarding is smoother. New team members inherit your queries. Clean formatting is a small kindness that saves them hours.
Mistakes get caught earlier. Misplaced AND/OR logic, missing join conditions, and typo'd column names all hide more easily in dense, unformatted SQL.

Here's a quick taste of what a difference formatting makes, even for a simple SELECT:

Before:

select id,name,email,created_at from users where status='active' and created_at>'2023-01-01' order by created_at desc;

After:

SELECT
    id,
    name,
    email,
    created_at
FROM users
WHERE status = 'active'
    AND created_at > '2023-01-01'
ORDER BY created_at DESC;

Same query, same result set — but the second version tells you what's happening at a glance. Each column has its own line, each clause starts on its own line, and the keywords stand out from the data. That's the whole game.

Why Poorly Formatted SQL Becomes Hard to Maintain

Unformatted SQL doesn't just look messy — it actively works against you over time.

Git diffs turn into noise. If your whole query lives on one line, changing a single condition rewrites the entire line in version control, making it impossible to see what actually changed.
Logic errors hide in plain sight. A missing parenthesis or a misplaced OR is easy to miss when everything blends together.
Nested queries lose their shape. Without indentation, you can't tell which SELECT belongs to which level of nesting.
Every edit gets riskier. When you can't quickly understand a query, you're more likely to introduce a bug while changing it.

Common Mistake: Mixing tabs and spaces in the same file. It looks fine in your editor but turns into a jagged mess in anyone else's, since editors render tab width differently.

The Real Benefits of Consistent SQL Formatting

Consistent formatting compounds over time. A few concrete payoffs:

Faster reviews. Reviewers spend their attention on logic, not on decoding structure.
Predictable structure. Once you know the pattern, you can scan any query on the team and know where to look for the WHERE clause, the joins, or the aggregation.
Cleaner diffs. One clause or column per line means version control shows exactly what changed — nothing more.
Fewer "wait, what does this do?" moments during incident response, when you least want to be puzzling over syntax.

Common SQL Formatting Mistakes Developers Make

Before we get into the fixes, here's what tends to go wrong most often:

Writing the entire query on a single line.
Random, inconsistent indentation from line to line.
Inconsistent capitalization — Select, SELECT, and select all in the same file.
Vague, meaningless aliases like a, b, t1, t2.
No spacing around operators (total>100 instead of total > 100).
Mixing comma-first and comma-last styles in the same codebase.
Deeply nested subqueries with no indentation to show the hierarchy.
Skipping comments on non-obvious business logic.
Lines so long you have to scroll horizontally to read them.
Join conditions that aren't aligned or grouped clearly.

If a few of those look familiar, don't worry — the rest of this guide fixes each one.

Proper Indentation Techniques

Indentation is the backbone of readable SQL. The rule is simple: subordinate clauses and conditions get indented under the keyword they belong to.

Pick either 2 or 4 spaces (never tabs, since they render inconsistently across editors and terminals) and stick with it everywhere.

Before:

select * from orders where (status='pending' or status='processing') and customer_id in (select id from customers where region='west' and active=1);

After:

SELECT *
FROM orders
WHERE (status = 'pending' OR status = 'processing')
    AND customer_id IN (
        SELECT id
        FROM customers
        WHERE region = 'west'
            AND active = 1
    );

Pro Tip: Indent each subquery one level deeper than its parent. That way, nesting depth is something you can see, not something you have to mentally track.

Formatting SELECT Statements

Once you have more than two or three columns, put each one on its own line. It's easier to scan, and it means adding or removing a column later only touches one line in your diff.

You'll see two common styles for commas:

Comma-last (most common, reads like prose):

SELECT
    id,
    name,
    email
FROM users;

Comma-first (makes missing or trailing commas easy to spot):

SELECT
    id
    , name
    , email
FROM users;

Both are valid. What matters is picking one and using it consistently across your team — mixing the two in the same codebase is what actually causes confusion.

Pro Tip: Avoid SELECT * outside of quick, exploratory queries. An explicit column list is easier to read, easier to review, and won't silently break your application if someone adds a column to the table later.

Formatting WHERE Clauses

Every condition gets its own line. Boolean operators (AND, OR) go at the start of the line, indented under WHERE.

Before:

SELECT * FROM orders WHERE status='shipped' AND total>100 AND customer_id IS NOT NULL AND created_at BETWEEN '2024-01-01' AND '2024-12-31' AND region IN ('west','east','central');

After:

SELECT *
FROM orders
WHERE status = 'shipped'
    AND total > 100
    AND customer_id IS NOT NULL
    AND created_at BETWEEN '2024-01-01' AND '2024-12-31'
    AND region IN ('west', 'east', 'central');

Now you can scan down the left edge and read the filter logic like a checklist, instead of parsing one long run-on sentence.

Pro Tip: When you're mixing AND and OR in the same clause, always use parentheses — even when operator precedence would technically get it right without them. It removes any doubt for the next reader.

Formatting JOINs

Always use explicit JOIN ... ON syntax instead of old-style comma joins. Put each join on its own line, with the ON condition right after it.

Before:

select o.id, c.name, p.title, o.total from orders o, customers c, products p, order_items oi where o.customer_id=c.id and oi.order_id=o.id and oi.product_id=p.id and o.status='completed';

After:

SELECT
    o.id,
    c.name,
    p.title,
    o.total
FROM orders o
INNER JOIN customers c ON c.id = o.customer_id
INNER JOIN order_items oi ON oi.order_id = o.id
INNER JOIN products p ON p.id = oi.product_id
WHERE o.status = 'completed';

Explicit joins separate "how tables connect" from "what rows I want," which makes the whole query easier to trace top to bottom. You can also add or remove a join without touching the WHERE clause at all.

Common Mistake: Comma joins put join logic and filter logic in the same place. Forget one join condition, and you've accidentally created a cartesian product — a silent bug that can quietly multiply your row count.

Formatting GROUP BY, ORDER BY, and HAVING

Keep every major clause — SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY — starting at the same indentation level (column zero). This "clause skeleton" lets you see the shape of a query in about two seconds.

Before:

select customer_id, count(*) as order_count, sum(total) as total_spent from orders where status='completed' group by customer_id having sum(total)>500 order by total_spent desc;

After:

SELECT
    customer_id,
    COUNT(*) AS order_count,
    SUM(total) AS total_spent
FROM orders
WHERE status = 'completed'
GROUP BY customer_id
HAVING SUM(total) > 500
ORDER BY total_spent DESC;

If you're grouping or ordering by several columns, break those out too:

GROUP BY
    customer_id,
    region,
    order_year

Formatting Nested Queries and Subqueries

Each level of nesting gets its own indentation level. This is where formatting discipline pays off the most, because nested logic is exactly where bugs like to hide.

Before:

select name from products where id in (select product_id from order_items where order_id in (select id from orders where customer_id=42));

After:

SELECT name
FROM products
WHERE id IN (
    SELECT product_id
    FROM order_items
    WHERE order_id IN (
        SELECT id
        FROM orders
        WHERE customer_id = 42
    )
);

Pro Tip: If you find yourself nesting more than two or three levels deep, that's usually a sign to reach for a CTE instead. It's the same logic, but far easier to read top to bottom.

Formatting Common Table Expressions (CTEs)

CTEs turn nested, hard-to-follow subqueries into named, sequential steps. Here's the same logic from above, rewritten as a CTE:

WITH customer_orders AS (
    SELECT id
    FROM orders
    WHERE customer_id = 42
),
ordered_items AS (
    SELECT product_id
    FROM order_items
    WHERE order_id IN (SELECT id FROM customer_orders)
)
SELECT name
FROM products
WHERE id IN (SELECT product_id FROM ordered_items);

A few formatting habits that make CTEs easier to work with:

Name each CTE for what it represents, not cte1, cte2.
Indent the body of each CTE one level in, and keep the final SELECT unindented so it's obvious that's the main query.
Put a blank line between CTEs when you have more than one — it gives your eyes a place to rest between logical steps.

Aliasing Tables and Columns Clearly

Once you're joining more than one table, aliases stop being optional in practice. Use short, meaningful aliases — o for orders, c for customers — rather than arbitrary letters like a and b that force the reader to scroll back up to the FROM clause to remember what's what.

Also alias every computed or aggregated column with AS, so the result set is self-explanatory:

SELECT
    o.id,
    COUNT(oi.id) AS item_count,
    SUM(oi.price * oi.quantity) AS order_total
FROM orders o
INNER JOIN order_items oi ON oi.order_id = o.id
GROUP BY o.id;

Without AS order_total, that column would show up as some generated, meaningless expression in your output.

Consistent Capitalization Strategies

The most common convention: uppercase for SQL keywords, lowercase or snake_case for identifiers.

SELECT customer_id, order_date
FROM orders
WHERE status = 'completed';

Some teams — particularly in the modern data/analytics engineering world — prefer everything lowercase, including keywords:

select customer_id, order_date
from orders
where status = 'completed';

Both are legitimate SQL style guide choices. What actually matters is picking one for your team and applying it everywhere, so readers don't have to context-switch between styles from file to file.

Spacing Conventions

Small, consistent spacing habits go a long way:

Space around comparison and arithmetic operators: total > 100, not total>100.
Space after every comma: id, name, email.
No space between a function name and its parenthesis: COUNT(*), not COUNT (*).
One space before and after AS.

-- Avoid
SELECT id,name,COUNT (*) AS cnt FROM orders WHERE total>=100;

-- Prefer
SELECT id, name, COUNT(*) AS cnt
FROM orders
WHERE total >= 100;

Line Breaks

Use a new line for:

Every major clause (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING).
Every column, once you have more than two or three.
Every JOIN.
Each CTE, with a blank line separating them for visual breathing room.

The goal isn't "more line breaks are always better" — it's giving each logical piece of the query its own visual space so your eyes can jump straight to the part you need.

Formatting CASE Statements

CASE expressions get unreadable fast when crammed onto one line. Break each WHEN onto its own line, indented under CASE, with END aligned back at the CASE level.

Before:

select id, case when total>1000 then 'high' when total>500 then 'medium' else 'low' end as tier from orders;

After:

SELECT
    id,
    CASE
        WHEN total > 1000 THEN 'high'
        WHEN total > 500 THEN 'medium'
        ELSE 'low'
    END AS tier
FROM orders;

This layout makes it trivial to scan the conditions in order and confirm the logic is doing what you expect — especially useful when there are five or six WHEN branches instead of two.

Formatting Window Functions (Briefly)

Window functions can get long fast once you add PARTITION BY and ORDER BY inside the OVER() clause. Break those onto their own indented lines so the window definition doesn't blend into the rest of the SELECT list:

SELECT
    customer_id,
    order_date,
    total,
    SUM(total) OVER (
        PARTITION BY customer_id
        ORDER BY order_date
    ) AS running_total
FROM orders;

This keeps the "what am I calculating" (SUM(total)) visually separate from the "how is it grouped and ordered" (the OVER() clause) — two different ideas that shouldn't be squeezed into one dense line.

Commenting SQL Code Effectively

Good comments explain why, not what. The SQL itself already tells the reader what's happening; your comments should fill in context that isn't obvious from the syntax alone.

-- Excludes test accounts flagged by the fraud team in March 2024
SELECT *
FROM users
WHERE is_test_account = 0
    AND created_at > '2024-03-01';

Use -- for short, single-line notes and /* ... */ for longer explanations above a complex section of logic.

Common Mistake: Leaving a strange-looking filter or condition uncommented. Six months from now, nobody — including you — will remember why region != 'archived' needed to be there, and someone will waste an hour rediscovering it (or worse, delete it and break something).

Team Coding Standards and SQL Style Guides

Formatting debates burn a surprising amount of time in code review — "tabs vs. spaces," "comma-first vs. comma-last," "uppercase vs. lowercase." A short, documented SQL style guide settles these once, instead of relitigating them in every pull request.

A useful team style guide covers:

Capitalization rules for keywords and identifiers.
Indentation size (2 or 4 spaces).
Comma placement.
Alias naming conventions.
Table and column naming conventions (snake_case is the most common default).
How and when to use CTEs versus subqueries.

Keep it short — a single STYLE.md file in your repository is often enough. The goal isn't a rulebook; it's a shared reference so reviewers can say "see the style guide" instead of relitigating formatting from scratch every time.

When Automatic Formatting Is Useful

Manually reformatting a long legacy query, or something a teammate pasted in from a spreadsheet export, is tedious — and it's easy to introduce a typo while you're at it.

That's where automatic formatting tools earn their keep. An online SQL Formatter can take a dense, single-line query and instantly restructure the indentation, casing, and spacing for you. It's especially handy for:

Cleaning up inherited or legacy scripts you didn't write.
Standardizing formatting across a team without manual nitpicking in every review.
Quickly making sense of a query someone pasted into a chat message.

Automatic formatting is a great starting point, but it's still worth understanding the underlying rules yourself. That way you can fine-tune the output, format queries on the fly at the terminal, and actually catch logic issues instead of just relying on a tool to make things look tidy.

Common Formatting Conventions Followed by Professional Developers

If you want a quick checklist to build habits around, most professional SQL style guides agree on:

Uppercase keywords, lowercase snake_case identifiers.
2 or 4 space indentation — never tabs.
One clause per line.
One column per line once you're past two or three columns.
Explicit JOIN syntax, never comma joins.
Meaningful, consistent table aliases.
AS for every derived or aggregated column.
Parentheses around mixed AND/OR logic, even when not strictly required.
Trailing semicolons on every statement.
Comments that explain business context, not syntax.

Frequently Asked Questions

Does SQL formatting affect query performance?
No. Whitespace, line breaks, and capitalization don't change how the database engine parses or executes a query. Formatting is entirely for the benefit of the humans reading the code.

Should SQL keywords always be uppercase?
It's not required, but it's a widely used convention because it visually separates syntax (SELECT, WHERE, JOIN) from your actual data — table and column names. Pick uppercase or lowercase and apply it consistently.

What's the difference between comma-first and comma-last formatting?
Comma-last (the comma at the end of a line) reads more like natural prose. Comma-first (the comma at the start of the next line) makes it easier to spot a missing or accidental trailing comma at a glance. Both are valid — consistency across your team matters more than which one you choose.

How many spaces should I use for indentation in SQL?
Two or four spaces are both common choices. Four spaces makes nested subqueries more visually distinct; two spaces keeps deeply nested queries from drifting too far to the right. Avoid tabs, since they render at different widths across editors.

Should I always alias tables, even in single-table queries?
It's not necessary for a single-table query, but it becomes important as soon as you join a second table, since it removes any ambiguity about which table a column belongs to.

*Is it okay to use SELECT in formatted SQL?**
It works fine for quick, exploratory queries, but it's generally discouraged in production code or reports. An explicit column list is easier to review and won't silently change if someone adds a column to the underlying table later.

How do I format SQL in a way that's friendly to version control?
Keep each clause and each column on its own line. That way, a small change — like adding one more column — shows up as a single-line diff instead of rewriting an entire block, which makes reviews much faster.

Can I mix tabs and spaces in the same SQL file?
No. Mixed tabs and spaces render inconsistently across different editors and terminals, and it's one of the most common causes of formatting drift on a team. Pick one and configure your editor to enforce it.

Do CTEs perform better than subqueries?
Not inherently — performance depends on the specific database engine and how it optimizes the query plan. CTEs are primarily a readability tool that lets you break complex logic into named, sequential, easy-to-follow steps.

What's the best way to enforce consistent formatting across a team?
Write down your conventions in a short style guide, use an automatic formatter as a shared starting point, and check formatting during code review (or with a pre-commit hook) so it doesn't slip through.

Wrapping Up

SQL formatting isn't about being precious over style — it's a maintenance investment that pays off every time someone (including you) has to read, debug, or extend a query later.

A few habits carry most of the value:

One clause per line, one column per line.
Consistent capitalization and indentation.
Explicit joins with clear, meaningful aliases.
Comments that explain the "why," not the "what."
Parentheses whenever AND and OR mix.

Build these into your daily workflow and your queries — and your team's — get easier to review, debug, and hand off over time. And when you're short on time or inheriting a messy legacy query, running it through an online SQL Formatter first gives you a clean, consistent starting point you can fine-tune by hand from there.

Why "Your Code Is LLM" Became the Go-To Insult in Tech

Sat, 13 Jun 2026 11:11:23 +0000

And why tests, comments, and sensible function names aren't proof of AI—they're proof of a professional.

Hey.

I want to break down, surgically and in detail, why calling someone's code "LLM-written" has become a way to devalue programmer's work. And how I've dealt with it myself.

I'm alexvoste. Yeah, that dev. Instead of explaining my credentials in every post, just swing by my CoderLegion profile and see who I am. It's all there.

The Real Problem

Lately, everyone's started calling other people's code "AI-written." And it sucks. Seriously.

You write code. You polish it until it gleams. Everything works. Tests pass:

go test ./... -cover
go test -race ./...
go test -v ./...
golangci-lint run ./...

Seems fine, right? You run the tests—all green. The code does exactly what you wanted.

Then someone drops: "This looks like an LLM wrote it."

On what grounds? Because the functions have readable names. Because there are comments. Because tests exist.

When did readable code become a red flag for AI?

Naming Functions: Why Clear is Good, Not "AI"

Back in the day, things were simpler. You don't just write code for yourself—you write it for others to understand. Logically, some time passes, and you come back thinking: "What the hell did I even write here?"

That's wasted time. Wasted on code review. On comprehension.

Without proper comments and decent function names, a programmer stops being a creator or engineer. You become an archaeologist. You're sitting there with a toothbrush, digging through petrified logic and log fragments, trying to figure out what the original author meant. Often, that's you from six months ago.

My philosophy: functions should be named after what they do.

Bad:

int printmsg(char *s);

Good:

int printMessageOnVGA(char *message);

In Go:

// Bad
func printMsg(s string) string {}

// Good
func PrintMessageOnVGA(message string) string {}

It's a basic ask: make it possible to understand what a function does without a migraine.

When did writing clear, readable code become the exclusive domain of neural networks?

Comments: A Separate Art Form

Know who usually says "comments are proof of LLM"? People who write using AI. Or people who've never maintained legacy code.

Here's an example of code without comments:

package main

import (
    "fmt"
    "unsafe"
)

func main() {
    b := []byte{0x23, 0x5D, 0x11, 0x08, 0x46, 0x61, 0x20, 0x0A}
    v := *(*uint64)(unsafe.Pointer(&b[0]))
    r := (v >> 16) | (v << 48)
    m := r ^ 0x2A2B2C2D2E2F3031
    res := []byte{byte((m >> 24) & 0xFF), byte(m & 0xFF)}
    fmt.Printf("%s\n", res)
}

At first glance—incomprehensible. Yeah, you can analyze it, figure it out. But imagine: you're working on a long-term project, digging through legacy code, you dive into a function—and you burn hours trying to understand. Trust me, this example is still pretty small. It gets way messier.

In situations like this, a comment matters. It explains the logic. It saves hours of suffering.

But there's a flip side. Too many unnecessary comments are bad:

// Here we print message on VGA.
func PrintMessageOnVGA(message string) {
    fmt.Println(message)
}

Why this comment? We already got it from the function name. That looks unprofessional. Extra comments suck. But no comments in complex places? Even worse.

And now everyone's convinced: comments = AI.

So a developer writes nontrivial, complex code—and for being honest about explaining it, gets slapped with the "LLM" label.

Hopefully someday devs will see how absurd this is and stop jumping to these conclusions.

Let's Get Real: Who Are These People?

Who are these folks who think "comments and tests = proof of AI"?

Usually guys whose own code looks like a plate of spaghetti. Variable names are single letters: a, b, c1, temp_foo. Functions stretch for 800 lines. The only "tests" in the project are running it by hand and saying a prayer.

For them, quality work became so alien they genuinely believe humans can't write clean code. It's not that my code is "AI-level," it's that their standards tanked below the baseboards.

Tech adopted a weird "special snowflake syndrome." Some people think their messy, convoluted, only-they-understand code is proof of their "human soul" and genius. Like, "I see it this way, it's art!"

Nah, buddy. In systems programming, in production, where millions in transactions run or hardware gets managed—your "art" is a potential money pit and sleepless nights for your team. Clean code isn't soulless. It's respect for your colleagues. And for yourself, first and foremost.

Quick Fact Check: The Linux Kernel Code

Are those comments also written by an LLM? Weird how nobody screams "AI-generated" about that.

Linux kernel code is readable. It has comments. Function names make sense. Nobody loses their mind yelling it's LLM. Because it's engineering work, not "art for art's sake."

Plus, when that guy accusing everyone of using AI hits a real legacy project, what's he gonna do? Start stabbing at devs screaming their code is LLM-written? Or finally say thanks that the code is clean and understandable?

Rhetorical question.

Tests: Why I Write Them (And Yeah, I Actually Write Them)

Do you write tests? I do.

Why do I do it with such heavy coverage? Simple answer:

Code should have test coverage—at least moderate. 60+ percent? Already solid.

Tests exist so your platform, app, software, or tool behaves correctly in different scenarios. How else will you spot a leak or security hole? Spend hours debugging yourself? Yeah, didn't think so.

But a new folk wisdom appeared: "Only LLMs write tests."

Since when?

If everyone in tech complains that writing tests is tedious—that doesn't mean nobody does it. It means good engineers power through the laziness and do their job right.

My Take (No BS)

I'm not defending myself. I'm not gonna say "guys, I don't use AI, you're wrong." Nah. Opposite.

I'll admit it straight: I use AI. But only where it's actually useful:

Translation to another language
Article drafts
Basic tests (which then get shredded in code review)

Heavy, thorough code review? You can see it from a mile away. But here's the thing—that's not the point.

Tests cover the code? Task done.
No leaks? No holes? Perfect.

The Takeaway

If someone tells you your code looks like LLM output—don't apologize. It's not shameful. AI's a tool.

But don't let them silence you.

Your code is yours. Your style, your tests, your comments, your function names—that's your professional fingerprint.

And if someone calls it "LLM output"? That's their perception problem, not your work problem.

Write code. Cover it with tests. Name functions clearly. Comment the hard stuff. Don't let anyone devalue what you do.

And if you run into the next "expert" pointing fingers at LLM? Just drop them a link to this post.

One More Thing

You're a programmer. You do stuff the people criticizing you probably can't. Know why?

Because it's easier to point at AI than to say:

"That's solid code. You did good."

Yeah, LLMs exist. They're not perfect. But ask yourself—

Are you really willing to spend hours Googling a question and scrolling through forums forever when you could write:

"Hey, knock up some tests for me real quick, will ya"?

You get tests. You tweak them to fit. You polish them by your project's standards. Boom—done.

I've Been in Tech Since Before LLMs Were a Thing

And you know what? We always had comments. Always had sensible function names. You didn't waste time decoding—the devs who wrote the code looked out for you.

Isn't that the best kind of care?

"They're Writing So Much Text—Must Be LLM"

That's a song of its own.

Do any of you know 10+ languages fluently? Ready to write professional posts in all of them? Doubt it. If you are—respect.

An LLM has knowledge of tons of languages packed in. Idioms, constructs, cultural codes. It spits out text easily.

But here's the thing—you wrote it. The LLM was just a smart translator. A tool. Not the author.

I Didn't Want to Hurt Anyone's Feelings

But I wanted to push back against these new folk standards that rolled in with the AI era. And if even one person reads this and thinks twice before pointing at someone's code screaming "LLM"—I consider the mission accomplished.

Thanks for reading.

Hope this helps anyone dealing with the same garbage.

Drop a comment. Let's talk about this circus we call IT. 👇

A recipe for the Perfect Use Case

Sun, 17 May 2026 04:47:50 +0000

Today we’re cooking the perfect Use Case — and CQRS will be our recipe.

Ingredients

Action — fire and forget (logout, clear cache)
Query — read data (list products)
Command — write data (update profile)
Exchange — transform data (login)

All four types extend a sealed interface:

sealed interface UseCase<Input, Output> {
    interface Action : UseCase<Unit, Unit>
    interface Query<Output> : UseCase<Unit, Output>
    interface Command<Input> : UseCase<Input, Unit>
    interface Exchange<Input, Output> : UseCase<Input, Output>
}

Three Ways to Season It

Arrow (Typed Errors) — the chef’s choice:

class GenerateSeed(
    private val seedService: SeedService
) : UseCase.Action {
    override suspend fun Raise<Throwable>.action() =
        seedService.generateSeed().bind()
}

Result (Standard Wrapper) — zero dependencies:

class GenerateSeed(private val service: SeedService) : UseCase.Action {
    override suspend fun action() = service.generateSeed().getOrThrow()
}

Raw (Direct Execution) — zero overhead:

class GenerateSeed(private val service: SeedService) : UseCase.Action {
    override suspend fun action() = service.generateSeed()
}

Why This Recipe Works

No more UseCase<Unit, Unit> noise
Every use case follows the same structure
Query or Command makes intent obvious

Full implementation in the GitHub repository.

Error Handling in NestJS: Best Practices and Examples

Thu, 14 May 2026 16:33:59 +0000

In any real-world backend application, proper error handling is essential. It ensures that your system doesn't crash unexpectedly, responds clearly to clients, and makes debugging easier for developers. Luckily, NestJS provides powerful tools to do this cleanly and professionally.

Let’s explore how to handle errors effectively in NestJS using built-in exceptions, global filters, and custom strategies.

Why is Error Handling Important?

Errors happen: invalid input, missing resources, database failures, unreachable services… A backend that doesn't handle these gracefully will:

Crash or hang
Leak sensitive data
Return unclear or inconsistent responses

NestJS allows us to build resilient APIs that fail smart, not hard.

✅ Level 1: HTTP Exceptions (Built-in)

NestJS offers ready-to-use exception classes like BadRequestException, NotFoundException, UnauthorizedException, etc.

Example:

@Get(':id')
async findOne(@Param('id') id: string) {
  const user = await this.userService.findById(id);
  if (!user) {
    throw new NotFoundException(`User with ID ${id} not found`);
  }
  return user;
}

Nest will automatically respond with a 404 and a structured JSON response.

Level 2: Global Exception Filter

For centralized error handling, you can create a custom exception filter to catch and format all uncaught exceptions globally.

Example:


import {
  ExceptionFilter,
  Catch,
  ArgumentsHost,
  HttpException,
  Logger,
} from '@nestjs/common';

@Catch()
export class AllExceptionsFilter implements ExceptionFilter {
  private readonly logger = new Logger(AllExceptionsFilter.name);

  catch(exception: unknown, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse();

    const status = exception instanceof HttpException
      ? exception.getStatus()
      : 500;

    const message = exception instanceof HttpException
      ? exception.getResponse()
      : 'Internal server error';

    this.logger.error('Exception caught', exception instanceof Error ? exception.stack : '');

    response.status(status).json({
      statusCode: status,
      message,
      timestamp: new Date().toISOString(),
    });
  }
}

Enable it globally:


import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { AllExceptionsFilter } from './common/filters/all-exceptions.filter';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalFilters(new AllExceptionsFilter());
  await app.listen(3000);
}
bootstrap();

Now all unhandled errors are caught and returned with a unified format.

Level 3: Custom Exceptions

You can define your own domain-specific exceptions for business logic clarity.


import { BadRequestException } from '@nestjs/common';

export class DuplicatedEmailException extends BadRequestException {
  constructor(email: string) {
    super(`The email ${email} is already registered`);
  }
}

Use it like:


if (userExists) {
  throw new DuplicatedEmailException(email);
}

Level 4: Automatic Validation Errors with class-validator

When using DTOs with class-validator and ValidationPipe, NestJS handles validation errors out of the box.


@IsEmail()
email: string;

@MinLength(6)
password: string;

Enable it globally in main.ts:

app.useGlobalPipes(new ValidationPipe());

This will respond with 400 Bad Request if the input doesn't meet the defined constraints.

Bonus: Error Handling in Microservices

If you're using NestJS with Kafka, RabbitMQ, or other transport layers, use RpcException inside your message handlers:


@MessagePattern('create-user')
async createUser(data: CreateUserDto) {
  try {
    return await this.userService.create(data);
  } catch (error) {
    throw new RpcException('Error creating user');
  }
}

This prevents crashes and enables proper retry or dead-letter strategies in your messaging system.

Final Thoughts

Error handling in NestJS is not just about catching bugs—it's about building services that:

Are user-friendly (clear responses)
Are developer-friendly (structured logs and debugging)
Follow clean architecture and domain logic boundaries

By combining exception filters, DTO validation, and custom errors, you’ll write APIs that are robust, scalable, and production-ready.

Corporate Amnesia: What Happens When Your Team Forgets How Its Own Code Works

Thu, 14 May 2026 13:02:28 +0000

A few months ago, we had to change a small piece of logic.

It sounded simple.
A minor tweak.
“Shouldn’t take more than a couple of hours.”

Then someone asked:

“Do we know how this actually works?”

Silence.

No one on the team had written that part.
The last person who touched it had left.
There was no documentation.
Tests were… optimistic.

What should have been a small change turned into a half-day investigation.

Not because the problem was hard.

Because the knowledge was gone.

TL;DR

Teams don’t just lose code quality over time, they lose understanding.
Documentation alone doesn’t solve it, readable and maintainable code does.
Preventing knowledge loss is a business problem, not just a technical one.

What Is Corporate Amnesia
How Knowledge Actually Gets Lost
The Real Cost (It’s Not Just Time)
Why Documentation Alone Doesn’t Save You
Code as the Single Source of Truth
A Real Example: “It Works, Don’t Touch It”
How to Build a Memory-Resilient Codebase
Knowledge Handover Checklist
Final Thoughts

What Is Corporate Amnesia

Corporate amnesia happens when a team loses the knowledge needed to confidently work on its own system.

It doesn’t happen all at once.

It’s gradual.

A developer leaves.
Another switches teams.
A feature is built quickly and never revisited.

Over time, fewer and fewer people understand how things actually work.

Eventually, you end up with a codebase that:

technically works
but no one fully understands

And that’s where things start slowing down.

How Knowledge Actually Gets Lost

It’s easy to blame turnover.

But that’s only part of the story.

Knowledge gets lost when:

decisions are not documented
code is hard to read or follow
logic is duplicated instead of centralized
context lives in people’s heads, not in the system

And most importantly:

when teams optimize for delivery, but not for clarity

Shipping fast is important.

But if clarity doesn’t follow, knowledge decays.

The Real Cost (It’s Not Just Time)

At first, the cost looks like time.

tasks take longer
debugging becomes slower
onboarding is harder

But the real cost is deeper.

You start seeing:

hesitation to change existing code
over-engineering “just to be safe”
duplicated features instead of modifying existing ones

And eventually:

the team stops trusting the codebase

That’s when velocity drops.

Not because developers are slower.

But because the system is harder to work with.

Why Documentation Alone Doesn’t Save You

The instinctive solution is:

“We need better documentation.”

And yes, documentation helps.

But it has a problem.

It gets outdated.

Fast.

Code evolves.
Docs don’t always keep up.

And after a while, you’re not sure which one to trust.

Code as the Single Source of Truth

Good teams treat code as documentation.

Not by writing comments everywhere.

But by writing code that explains itself.

For example:

function calculateFinalPrice(price, discount, tax) {
  return price - discount + tax
}

function calculateFinalPrice(price, discount, tax) {
  const discountedPrice = applyDiscount(price, discount)
  const finalPrice = applyTax(discountedPrice, tax)

  return finalPrice
}

Both work.

Only one communicates intent.

Readable code does a few important things:

reduces the need for external documentation
makes onboarding faster
preserves knowledge inside the system

Because the goal isn’t to explain the code somewhere else.

It’s to make the code explain itself.

A Real Example: “It Works, Don’t Touch It”

Every codebase has one.

A file or module that everyone avoids.

You open it and see something like this:

if (type === "A") {
  // complex logic
} else if (type === "B") {
  // slightly different logic
} else if (type === "C") {
  // copied and modified logic
}

No clear structure.
No clear intent.
No clear ownership.

And someone eventually says:

“It works. Let’s not touch it.”

That’s not stability.

That’s fear.

And fear is one of the clearest signals of lost knowledge.

How to Build a Memory-Resilient Codebase

You can’t prevent people from leaving.

But you can prevent knowledge from leaving with them.

A few practices make a big difference:

Make decisions visible

Not everything belongs in code.

But key decisions should be easy to find.

why something was built a certain way
trade-offs that were made
known limitations

Even lightweight notes help.

Optimize for readability

Readable code is not a luxury.

It’s a form of knowledge preservation.

clear naming
small functions
explicit logic

These are not style choices.

They’re long-term investments.

Prefer structure over cleverness

Clever code is hard to remember.

Simple, structured code is easier to rebuild mentally.

And that’s what you want.

If only one person understands a part of the system, that’s a risk.

Code reviews, pair programming, and rotations help distribute knowledge.

Refactor before it’s too late

The longer you wait, the more knowledge you lose.

Refactoring is not just about code quality.

It’s about keeping understanding alive.

Knowledge Handover Checklist

Most teams don’t lose knowledge suddenly.

They lose it during transitions.

Someone leaves.
Someone changes role.
Someone moves to another project.

And the handover?

Often rushed.
Sometimes skipped.

If you want to avoid that, you don’t need a long process.

You need a simple, repeatable checklist.

Before someone leaves (or switches context)

Make sure these things are covered:

1. Critical areas are identified

What parts of the system does this person know best?
Which components would be risky without them?

If you don’t know this, that’s already a signal.

2. Key flows are explained, not just code

How does the system behave end-to-end?
What are the important business rules?

Code shows how.
You also need why.

3. Known pitfalls are documented

edge cases
fragile areas
“this breaks if you change X”

These are things you rarely find in code, but always matter.

4. Decisions and trade-offs are captured

why this approach was chosen
what alternatives were considered
what constraints existed

Without this, future changes become guesswork.

5. Ownership is reassigned clearly

who is responsible for this part now?
who reviews changes?

Ambiguity here leads to neglect.

6. A real walkthrough happens

Not just docs.
Not just links.

A real session:

open the code
walk through real scenarios
answer questions live

This is where most knowledge transfer actually happens.

Small rule that makes a big difference

Don’t treat handover as a one-time event.

Treat it as a continuous habit:

share context during development
explain decisions in PRs
avoid knowledge silos early

Because the best handover is the one you barely need.

Final Thoughts

Corporate amnesia doesn’t happen because teams are careless.

It happens because knowledge isn’t treated as something that needs to be preserved.

Codebases don’t just store logic.

They store decisions, context, and understanding.

And when that disappears, everything becomes harder.

The goal isn’t to remember everything.

It’s to make sure the system remembers for you.

If this resonated with you:

Leave a ❤️ reaction
Share a part of your codebase that nobody wants to touch

And if you enjoy this kind of content, follow me here on CoderLegion for more.

Keep Code Left: The Art of Readable Logic

Sat, 02 May 2026 01:46:53 +0000

In 2015, while working at Software Andina, I had the privilege of attending a session that changed the way I look at a source file. At the time, we were frequently visited by developers from the United States who shared their expertise to help us sharpen our craft.

One of those visitors was Mick Andrew, a seasoned developer and Director of Development at Sage. He was a close friend of my boss at the time, John Rutherfurd, and he brought with him a presentation titled "Keep Code Left" (KCL).

The title was deceptively simple, but the philosophy behind it was profound. As developers, we often focus on making code work, but we frequently forget that code is read far more often than it is written. Mick taught us that by following a few "cookbook" rules, we could transform convoluted, deeply nested logic into something clean, linear, and remarkably easy to maintain.
What is Keep Code Left?

At its core, Keep Code Left is a coding style designed to maximize readability. The name refers to the visual structure of the code: the more your logic is indented (pushed to the right), the harder it becomes for a human brain to track the "state" and the flow of the program.

The goals of KCL are straightforward:

Simplify Logic: Create code that flows linearly rather than branching out.

Enhance Readability: Allow developers to "see the flow" and grasp the goal of a method at a glance.

Reduce Maintenance Bugs: Simple code is harder to break during future updates.

Streamline Reviews: It provides a standard that can be verified during code reviews without needing deep domain knowledge.

Since that day in 2015, I have applied these rules to nearly every project I’ve touched. In this post, I’ll break down exactly how to "Keep Code Left" and why your future self (and your team) will thank you for it.

Why “Keep Code Left” Matters
When code becomes deeply nested, several problems appear:

Harder to read line-by-line
Logic becomes difficult to follow
Increased risk of bugs
Slower code reviews

KCL aims to:

Simplify logic
Reduce indentation
Make flow visible at a glance
Enable faster and more reliable reviews

The Core Principle

Avoid unnecessary nesting. Prefer early exits and linear flow.

Instead of wrapping logic inside multiple if blocks, you handle edge cases early and return immediately.

Example 1: Nested Code (Bad)

public void ProcessOrder(Order order)
{
    if (order != null)
    {
        if (order.IsValid())
        {
            if (order.Items.Count > 0)
            {
                // Process order
                Save(order);
            }
        }
    }
}

Problems:

3 levels of nesting
Hard to scan quickly
Main logic is buried

Example 1: Keep Code Left (Better)

public void ProcessOrder(Order order)
{
    if (order == null) return;
    if (!order.IsValid()) return;
    if (order.Items.Count == 0) return;

    // Process order
    Save(order);
}

Benefits:

Flat structure
Easy to read top-to-bottom
Main logic is immediately visible

Example 2: Conditional Complexity
Bad Approach

if (user) {
    if (user.isActive) {
        if (!user.isBlocked) {
            sendEmail(user);
        }
    }
}

KCL Approach

if (!user) return;
if (!user.isActive) return;
if (user.isBlocked) return;

sendEmail(user);

**Key Techniques of Keep Code Left

Early Returns
**
Handle invalid cases first:

def process(data):
    if data is None:
        return

2. Guard Clauses

Protect your logic from bad inputs:

if (user == null) return;
if (!user.hasPermission()) return;

3. Reduce Indentation

Every level of indentation increases cognitive load.

Bad:

if (a)
{
    if (b)
    {
        if (c)
        {
            DoSomething();
        }
    }
}

Better:

if (!a || !b || !c) return;

DoSomething();

4. Focus on the “Happy Path”

The main logic should be:

Straightforward
Easy to locate
Not buried inside conditions

Impact on Code Reviews

KCL is extremely effective in reviews because:

Patterns are easy to detect
Less domain knowledge is required
Reviewers can quickly spot:
Missing checks
Logical errors
Anti-patterns

Mental Model
When writing code, ask:

Can I exit earlier?
Can I reduce one level of indentation?
Is the main logic immediately visible?

Real-World Benefit

Over time, applying KCL leads to:

Fewer bugs
Faster onboarding of new developers
Cleaner diffs in pull requests
More maintainable systems

Keep Code Left (KCL) Guidelines for AI
Applying Keep Code Left (KCL) principles when working with AI assistants is important because, by default, they tend to generate code that is correct but unnecessarily nested. This makes the code harder to read, review, and maintain over time. By explicitly enforcing simple rules like early returns and minimal indentation, you guide the AI to produce cleaner, more linear code that aligns better with how humans understand logic. This reduces cognitive load, speeds up code reviews, and improves long-term maintainability.

Claude.MD Example:

Example: Claude `.md`

md
## KCL Rules
- Use early returns
- Avoid nested if statements
- Keep code flat and readable

### Example

Bad:
if (user) {
    if (user.isActive) {
        process(user);
    }
}

Good:
if (!user) return;
if (!user.isActive) return;

process(user);

Software Engineering Great Quotes

Tue, 31 Mar 2026 17:29:28 +0000

A short thought can bring amazing ideas

TL;DR: There are some great quotes I've been collecting.

I use them as inspiration or a motto for some articles.

Here we go:

First make the change easy (warning: this might be hard), then make the easy change.

Kent Beck

Good judgement comes from experience, and experience comes from bad judgement.

Frederick P. Brooks

Object thinking focuses our attention on the problem space rather than the solution space. Object thinkers take the advice of Plato, Parnas, Fred Brooks, Christopher Alexander, and many others by letting the problem define its own solution

David West

Voluminous documentation is part of the problem, not part of the solution.

Tom DeMarco

Before you use a method in a legacy system, check to see if there are tests for it. If there aren't, write them. When you do this consistently, you use tests as a medium of communication.

Michael Feathers

The biggest issue on software teams is making sure everyone understands what everyone else is doing.

Martin Fowler

Object thinking focuses our attention on the problem space rather than the solution space.

David West

Programming isn't about what you know; it's about what you can figure out.

Chris Pine

The best way to start fixing a bug is to make it reproducible. After all, if you can't reproduce it, how will you know if it is ever fixed?

Andrew Hunt

The danger from computers is not that they will eventually get as smart as men, but that we will meanwhile agree to meet them halfway.

Bernard Avishai

The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards.

Gene Spafford

I've finally learned what 'upward compatible' means. It means we get to keep all our old mistakes.

Dennie van Tassel

If it doesn't work, it doesn't matter how fast it doesn't work.

Mich Ravera

If you lie to the compiler, it will get its revenge.

Henry Spencer

Final source code is the real software design.

Jack Reeves

Make it correct, make it clear, make it concise, make it fast. In that order.

Wes Dyer

If someone claims to have the perfect programming language, he is either a fool or a salesman or both.

Bjarne Stroustrup

If you can get today's work done today, but you do it in such a way that you can't possibly get tomorrow's work done tomorrow, then you lose.

Martin Fowler

There's nothing more permanent than a temporary hack.

Kyle Simpson

The purpose of computing is insight, not numbers.

Richard Hamming

Software and cathedrals are much the same. First we build them, then we pray.

Sam Redwine

Discovery consists of seeing what everyone else has seen and thinking what no one else has thought.

Albert Szent-Gyorgi

Eighty percent of all input forms ask questions they have no business asking.

Mike Garey

A primary cause of complexity is that software vendors uncritically adopt almost any feature that users want.

Niklaus Wirth

Programs, like people, get old. We can't prevent aging, but we can understand its causes, limit its effects and reverse some of the damage.

Mario Fusco

Bugs lurk in corners and congregate at boundaries.

Boris Beizer

Simple systems are not feasible because they require infinite testing.

Norman Ralph Augustine

C is quirky, flawed, and an enormous success.

Dennis M. Ritchie

Conceptual integrity is the most important consideration in system design.

Frederick P. Brooks

I can't be as confident about computer science as I can about biology. Biology easily has 500 years of exciting problems to work on. It's at that level.

Donald Knuth

Don't worry about design, if you listen to your code a good design will appear...Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things.

Martin Fowler

It is far easier to design a class to be thread-safe than to retrofit it for thread safety later.

Brian Goetz

Defect-free software doesn't exist.

Wietse Venema

Just because something is easy to measure doesn't mean it's important.

David Heinemeier Hansson

Behavior is the most important thing about software. It is what users depend on. Users like it when we add behavior (provided it is what they really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us.

Michael Feathers

Code should be remarkably expressive to avoid most of the comments. There'll be a few exceptions, but we should see comments as an 'failure of expression' until proven wrong.

Robert Martin

Builder pattern is more verbose than the telescoping constructor pattern, so it should be used only if there are enough parameters, say, four or more.

Joshua Bloch

Complexity is a sign of technical immaturity. Simplicity of use is the real sign of a well design product whether it is an ATM or a Patriot missile.

Daniel T. Ling

We are constantly interfacing with other people's code that might not live up to our high standards and dealing with inputs that may or may not be valid. So we are taught to code defensively. We use assertions to detect bad data and check for consistency.

Andrew Hunt

Don't use humans for jobs computers can do better - this is a waste of human energy and creativity, the only real resource on this planet, and demeans the human spirit.

J. Paul Morrison

On two occasions, I have been asked [by members of Parliament], "if you put into the machine wrong figures, will the right answers come out?"...I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

Charles Babbage

Forget this world and all its troubles and if possible its multitudinous Charlatans - everything in short but the Enchantress of Numbers.

Ada Lovelace

While it is a known fact that programmers never make mistakes, it is still a good idea to humor the users by checking for errors at critical points in your program.

Robert D. Schneider

First, solve the problem. Then, write the code.

John Johnson

The main activity of programming is not the origination of new independent programs, but in the integration, modification, and explanation of existing ones.

Terry Winograd

This 'users are idiots, and are confused by functionality' mentality of Gnome is a disease. If you think your users are idiots, only idiots will use it.

Linus Torvalds

The best programmers write only easy programs.

Michael A. Jackson

If Mc Donalds were run like a software company, one out of every hundred Big Macs would give you food poisoning — and the response would be, "We're sorry, here's a coupon for two more".

Mark Minasi

Tell me and I forget. Teach me and I remember. Involve me and I learn.

Benjamin Franklin

Programmers are often angry because they're often scared.

Paul Ford

Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet.

Michael A. Jackson

If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology.

Bruce Schneier

This fascination with computer models is something I understand very well. Richard Feynman called it a disease. I fear he is right.

Michael Crichton

Criticism isn't just disliking things. Arts schools teach the skill & the respect for the work. Computer science schools don't.

Kent Beck

The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

Brian W. Kernighan

Feedback is essential to our ability to learn. Without fast, effective feedback, we are guessing. Both the speed and the quality of feedback matter. If feedback is too late, it is useless. If it is misleading or wrong, the decisions that we make will be wrong, too

Dave Farley

Defects are not free. Somebody makes them, and gets paid for making them.

Edwards Deming

The heart of software is its ability to solve domain-related problems for its user. All other features, vital though they may be, support this basic purpose.

Eric Evans

Errors have occurred. We won't tell you where or why. Lazy programmers.

Charlie Gibbs

Any man can make mistakes, but only an idiot persists in his error.

Marcus Cicero

If you have to spend effort to decipher code, you should rewrite it.

Martin Golding

More good code has been written in languages denounced as "bad" than in languages proclaimed "wonderful" — much more.

Bjarne Stroustrup

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.

C. A. R. Hoare

When I first got into technology I didn't really understand what open source was. Once I started writing software, I realized how important this would be.

Matt Mullenweg

The problem is, in software design, often the consequences of your decisions don't become apparent for years.

Kent Beck

Being forced to write comments actually improves code, because it is easier to fix a crock than to explain it.

G. Steele

We crave for new sensations but soon become indifferent to them. Wonders of yesterday are today common occurrences.

Nikola Tesla

Tests should be even more readable then the code they cover

Shaun Wessel

A function name should be a verb or a verb phrase, and it needs to be meaningful

Robert C. Martin

Pair programmers: Keep each other on task. Brainstorm refinements to the system. Clarify ideas. Take initiative when their partner is stuck, thus lowering frustration. Hold each other accountable to the team's practices.

Kent Beck

Obsolete comments tend to migrate away from the code they once described. They become floating islands of irrelevance and misdirection in the code.

Bob Martin

If you are choosing a JavaScript library purely based on popularity, I think you deserve what you get.

Tom Dale

Today, most software exists, not to solve a problem, but to interface with other software.

I Angell

On almost anything someone does in the computer business, you can go back in the literature and prove someone had done it earlier.

Ken Olsen

Computers are good at following instructions, but not at reading your mind.

Donald Knuth

The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.

Edsger W. Dijkstra

A bad system will beat a good person every time.

Edwards Deming

The fantastic element that explain the appeal of dungeon games to many programmers is neither the fire-breathing monsters nor the milkyskinned, semi-clad sirens; it is the experience of carrying out a task from start to finish without user requirements changing.

Thomas Holaday

Computer science is a restless infant and its progress depends as much on shifts in point of view as on the orderly development of our current concepts.

Alan Perlis

Sun Microsystems had the right people to make Java into a first-class language, and I believe it was the Sun marketing people who rushed the thing out before it should have gotten out.

Alan Kay

Code is design

Ward Cunningham

A well installed microcode bug will be almost impossible to detect.

Ken Thompson

Science is what we understand well enough to explain to a computer, Art is all the rest

Donald Knuth

The cardinal rule of writing unmaintainable code is to specify each fact in as many places as possible and in as many ways as possible.

Roedy Green

Programs must be written for people to read, and only incidentally for machines to execute.

Harold Abelson

Feedback is the breakfast of champions.

Ken Blanchard

If you make a general statement, a programmer says, 'Yes, but...' while a designer says, 'Yes, and...'

André Bensoussan

Every Time you Encounter a Testability Problem, there's an Underlying Design Problem

Michael Feathers

Memory is like an orgasm. It's a lot better if you don't have to fake it.

Seymour Cray

Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration

Don Knuth

A bug is never just a mistake. It represents something bigger.

Sergey Zefirov

You can't communicate complexity, only an awareness of it.

Alan Perlis

A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.

Leslie Lamport

The greatest obstacle to discovery is not ignorance, but the illusion of knowledge.

Daniel Boorstin

Programmers are as emotional and irrational as normal people.

Douglas Crockford

There is nothing so useless as doing efficiently that which should not be done at all.

Peter Drucker

Computer science research is different from these more traditional disciplines. It differs from the physical sciences because it seeks not to discover, explain, or exploit the natural world, but instead to study the properties of machines of human creation

Dennis Ritchie

You can mass-produce hardware; you can't mass-produce software; you can't mass-produce the human mind.

Michio Kaku

Coding is about writing code while programming is coding and thinking

Leslie Lamport

Testing leads to failure, and failure leads to understanding.

Burt Rutan

The lesson is: Even if you know exactly what is going on in your system, measure performance, don't speculate. You'll learn something, and nine times out of ten, it won't be that you were right!

Ron Jeffries

Software engineering is not the same thing as computer science, though we often confuse the two. We need both software engineers and computer scientists.

Dave Farley

Languages that try to disallow idiocy become themselves idiotic.

Rob Pike

Watch the little things; a small leak will sink a great ship.

Benjamin Franklin

No one hates software more than software developers.

Jeff Atwood

Come to think of it, there are already a million monkeys on a million typewriters, and Usenet is nothing like Shakespeare.

Blair Houghton

A good enough first version will take longer to produce with $170K than it would have with $0K.

Jason Fried

The objective of cleaning is not just to clean, but to feel happiness living within that environment.

Marie Kondo

When I write software, I know that it will fail, either due to my own mistake, or due to some other cause.

Wietse Venema

Objects are there for the picking.

Bertrand Meyer

Spaghetti code is a program with its logic tangled like spaghetti. Avoid the tangles, and you simplify your life.

Martin Fowler

Instead of working on a feature until it is "finished", CI and its big brother CD demand of us to make changes in small steps and have something ready for use after every small step. This changes how we think about the design of our system in some important ways.

Dave Farley

Don't Live with Broken Windows

Andy Hunt

Programmers don't burn out on hard work, they burn out on change-with-the-wind directives and not 'shipping'.

Mark Berry

It is hard to write even the smallest piece of code correctly.

Joshua Bloch

If you have three pet dogs, give them names. If you have 10,000 head of cattle, don't bother. Nowadays, the idea of giving a name to every file on your computer is ridiculous.

David Gelernter

The computer programmer is a creator of universes for which he alone is the lawgiver. No playwright, no stage director, no emperor, however powerful, has exercised such absolute authority to arrange a stage or field of battle.

Joseph Weizenbaum

It would be nice if products and programming languages were designed to have only good parts.

Douglas Crockford

A good programmer is someone who always looks both ways before crossing a one-way street.

Doug Linder

Alzheimer's Law of Programming: Looking at code you wrote more than two weeks ago is like looking at code you are seeing for the first time.

Dan Hurvitz

The amateur software engineer is always in search of magic.

Grady Booch

Truth can only be found in one place: the code.

Robert C. Martin

So much complexity in software comes from trying to make one thing do two things.

Ryan Singer

Just as it is a good practice to make all fields private unless they need greater visibility, it is a good practice to make all fields final unless they need to be mutable.

Brian Goetz

Any code of your own that you haven't looked at for six or more months might as well have been written by someone else.

Eagleson's Law

One day my daughter came in, looked over my shoulder at some Perl 4 code, and said, "What is that, swearing?"

Larry Wall

I think it's very important to get more women into computing. My slogan is: Computing is too important to be left to men.

Karen Spärck Jones

Code is like humor. When you have to explain it, it's bad.

Cory House

Code should be written to be read by humans first, and machines second.

Don Laabs

Smart data structures and dumb code works a lot better than the other way around.

Eric Raymond

Legacy code is code without tests.

Michael Feathers

Simplicity is hard to build, easy to use, and hard to charge for. Complexity is easy to build, hard to use, and easy to charge for.

Chris Sacca

I try to think mostly in terms of preconditions, and checking things in the constructor and the beginning of a function.

Brad Fitzpatrick

Developer testing is an important step towards accountability. It gives developers a way to demonstrate the quality of the software they produce.

Kent Beck

We argue that design practices which take a data-driven approach fail to maximize encapsulation because they focus too quickly on the implementation of objects. We propose an alternative object-oriented design method which takes a responsibility-driven approach.

Rebecca Wirfs-Brock

There are two ways to write error-free programs; only the third one works.

Alan J. Perlis

A true professional doesn't waste the time and money of other people by handing over software that is not reasonably free of obvious bugs; that has not undergone minimal unit testing; that doesn't meet the specifications and requirements; that is gold-plated with unnecessary features; or that looks like junk.

Daniel Read

Part of the objective of this series of articles is to generate spaces for debate and discussion on software design.

We look forward to comments and suggestions on this article.

React Components vs Spaghetti: 5 Signs Your UI Is Becoming Unmaintainable

Tue, 24 Mar 2026 09:52:34 +0000

Last week I opened a React component… and immediately closed it.

Not because it was complex.

But because it felt hostile.

You know that feeling: the file keeps scrolling, props are flying around, and every small change feels like it might break something completely unrelated.

That’s not complexity.

That’s entropy.

And if you’ve been building UIs for a while, you’ve probably seen it happen slowly, almost invisibly.

Let’s talk about the signals before things get out of hand.

TL;DR

If your React components start feeling hard to read, fragile, or unpredictable, your UI is likely becoming unmaintainable.

The most common signals are oversized components, props drilling, unclear responsibilities, duplication, and messy conditionals.

You don’t need a rewrite, just small, consistent refactoring habits.

The Problem with “It Still Works”
1. The God Component (Too Big to Understand)
2. Props Drilling Everywhere
3. Confusing Responsibilities
4. UI Logic Duplication
5. Conditional Rendering Hell
Bonus Signs You Shouldn’t Ignore
Mini Refactoring: From Spaghetti to Clean
Practical Refactoring Rituals
Final Thoughts

The Problem with “It Still Works”

Most messy UIs don’t start messy.

They start small, clear, even elegant.

Then a feature gets added.

Then another one.

Then a quick fix before a deadline.

Nothing dramatic, just small decisions that make sense in the moment.

Until one day you open a file and realize you don’t really understand it anymore.

That’s the moment where “it still works” becomes dangerous.

Because now every change carries risk.

And the cost of touching the code becomes higher than leaving it alone.

1. The God Component (Too Big to Understand)

There’s usually one file in every project that everyone avoids.

It’s big. Really big.

It handles data, UI, state, events, and probably a few side effects too.

Something like this:

export default function Dashboard({ user, posts }: Props) {
  // fetching logic
  // filtering logic
  // UI rendering
  // event handlers
  // conditionals everywhere

  return (
    <div>
      <h1>{user.name}</h1>
      {/* hundreds of lines */}
    </div>
  )
}

The issue isn’t just the size.

It’s the lack of boundaries.

When everything lives in the same place, nothing is clearly defined.

You don’t know what’s safe to change and what might break something else.

A useful rule I rely on is simple:

If you can’t describe a component in one sentence, it’s doing too much.

Breaking it down doesn’t mean over-engineering.

It means restoring clarity.

export function Dashboard() {
  return (
    <div>
      <UserHeader/>
      <PostList/>
    </div>
  )
}

Now each piece has a purpose.

And more importantly, a limit.

2. Props Drilling Everywhere

Props drilling usually starts innocently.

You pass user from a parent to a child, then to another child, then another.

Until you end up here:

<Dashboard user={user}>
  <Sidebar user={user}>
    <UserAvatar user={user}/>
  </Sidebar>
</Dashboard>

At this point, some components are just acting as pipelines.

They don’t use the data, they just pass it along.

That creates a subtle kind of friction.

Every layer becomes aware of something it doesn’t actually care about.

And any change to that data ripples through the entire tree.

The obvious solution is often:

“Let’s use Context.”

And that’s valid… but only to a point.

Context is not a silver bullet.

Overusing it can make your app harder to reason about:

data becomes less explicit
re-renders become harder to control
tracing where values come from gets tricky

A better approach is to use it intentionally, when it actually solves a real problem:

truly global data (auth, theme, user)
deeply shared state
repeated props drilling across many levels

Combined with a custom hook, it stays clean:

function useUser() {
  return useContext(UserContext)
}

function UserAvatar() {
  const user = useUser()
  return <img src={user.avatar} />
}

Now the dependency lives exactly where it’s needed.

3. Confusing Responsibilities

Sometimes the problem isn’t visible at a glance.

It’s not about how much code there is, but about what kind of work is happening in the same place.

A single component handling:

data fetching
state management
transformation
rendering

…is doing too many different jobs.

The result is cognitive overload.

You open the file and constantly switch context:

“Am I reading UI? Or logic? Or data?”

That friction slows everything down.

Separating responsibilities makes the code easier to navigate and easier to trust.

A simple split already helps a lot:

function usePosts() {
  // fetch + transform
}

function PostList() {
  const posts = usePosts()
  return (...)
}

Now the component reads like a story again, not a puzzle.

4. UI Logic Duplication

Duplication doesn’t always look like copy-paste.

Sometimes it shows up as repeated patterns:

if (isLoading) return <Spinner />
if (error) return <Error />

You write it once.

Then again.

At some point, changing that behavior means updating multiple places.

That’s when it becomes expensive.

Extracting shared logic is less about abstraction and more about centralizing decisions.

function DataState({ loading, error, children }: Props) {
  if (loading) return <Spinner />
  if (error) return <Error />
  return children
}

Now the behavior lives in one place.

And your UI becomes more consistent by default.

5. Conditional Rendering Hell

Conditional rendering is fine.

Until it isn’t.

We’ve all written something like this:

return isAdmin
  ? isActive
    ? <AdminPanel />
    : <InactiveAdmin />
  : <UserPanel />

It works.

But it’s not easy to read.

The problem isn’t React.

It’s that too much logic is living inside JSX.

A first step is to move that logic out:

function renderContent() {
  if (isAdmin && isActive) return <AdminPanel />
  if (isAdmin) return <InactiveAdmin />
  return <UserPanel />
}

return renderContent()

Already much better.

Using Guard Clauses

Guard clauses can make this even clearer, when used carefully.

if (!isAdmin) {
  return <UserPanel />
}

if (!isActive) {
  return <InactiveAdmin />
}

return <AdminPanel />

This removes nesting and keeps the flow linear.

The key is balance.

use guard clauses when they simplify the flow
avoid stacking too many negative conditions
keep the logic readable from top to bottom

The goal isn’t fewer lines.

It’s clarity.

Bonus Signs You Shouldn’t Ignore

Sometimes the signals are less technical and more instinctive.

You hesitate before opening a file
You’re afraid to change something
Fixing a bug feels risky
You’ve said “let’s not touch this” more than once

These are all valid warnings.

And they usually show up before bigger problems.

Mini Refactoring: From Spaghetti to Clean

A while ago I ran into a component like this.

It wasn’t broken.

It wasn’t even that complex.

But it had that feeling:

“There’s just a bit too much going on here.”

❌ Before

export default function Dashboard({ user, posts }: Props) {
  const [filter, setFilter] = useState("all")

  const filteredPosts = posts.filter(p =>
    filter === "all" ? true : p.type === filter
  )

  return (
    <div>
      <h1>{user.name}</h1>

      <select onChange={e => setFilter(e.target.value)}>
        <option value="all">All</option>
        <option value="tech">Tech</option>
      </select>

      {filteredPosts.length === 0 ? (
        <p>No posts</p>
      ) : (
        filteredPosts.map(p => <div key={p.id}>{p.title}</div>)
      )}
    </div>
  )
}

Nothing wrong, technically.

But everything is mixed together:

state
logic
UI

So I started small.

Step 1: isolate the logic

function useFilteredPosts(posts: Post[]) {
  const [filter, setFilter] = useState("all")

  const filtered = posts.filter(post =>
    filter === "all" ? true : post.type === filter
  )

  return { filter, setFilter, filtered }
}

Now the component doesn’t care how filtering works.

Step 2: extract reusable UI

function PostFilter({ value, onChange }: Props) {
  return (
    <select value={value} onChange={e => onChange(e.target.value)}>
      <option value="all">All</option>
      <option value="tech">Tech</option>
    </select>
  )
}

Step 3: compose everything

export default function Dashboard({ user, posts }: Props) {
  const { filter, setFilter, filtered } = useFilteredPosts(posts)

  return (
    <div>
      <h1>{user.name}</h1>

      <PostFilter value={filter} onChange={setFilter} />

      {filtered.length === 0 ? (
        <p>No posts</p>
      ) : (
        filtered.map(p => <div key={p.id}>{p.title}</div>)
      )}
    </div>
  )
}

Same feature.

Completely different feeling.

That’s the real goal of refactoring.

Practical Refactoring Rituals

You don’t need a full rewrite to fix spaghetti code.

You need habits.

Refactoring works best when it’s part of your workflow, not something you postpone.

A few simple ones:

extract things early, when they start feeling “off”
keep components focused on one responsibility
move growing logic into hooks
spend time naming things clearly

None of these are revolutionary.

But together, they make your codebase easier to work with.

Final Thoughts

Spaghetti UI isn’t a failure.

It’s what happens when real features meet real constraints.

But if you ignore it, it slowly turns your codebase into something you avoid instead of something you trust.

The good news is, you don’t need perfection.

Just small improvements, applied consistently.

If this article resonated with you:

Leave a ❤️ reaction
Drop a like
Share the worst component you’ve ever written (or seen) in the comments

And if you enjoy this kind of content, follow me here for more.

Code doesn’t quit, but people do: Clean Code, Technical Debt, and the Bus Factor

Mon, 16 Mar 2026 13:06:53 +0000

TL;DR

Technical debt isn’t just a developer inconvenience, it’s a business risk with compound interest. When developers leave, they often take the “why” behind the code with them.

Clean Code isn’t about perfection: it’s about preserving knowledge inside the system, instead of inside someone’s head.

Not long ago I finished my MBA and, looking at my work from a more business-oriented perspective, I came to an interesting realization: developers and stakeholders are actually afraid of the exact same thing, they just describe it using different words.

Welcome to the Bus Factor.

This article explores how Clean Code, technical debt, and knowledge transfer affect real business risks like developer turnover, onboarding speed, and team scalability.

A small MBA realization

I recently closed my MBA, and among all the talk of spreadsheets and market positioning, I had a "Eureka" moment.

I realized that developers and business stakeholders often speak completely different languages.

We (the devs) talk about:

Refactoring and patterns
Technical debt
Code quality

Meanwhile, the business side talks about:

Risk mitigation
Turnover and ROI
Scalability and productivity

Different slides, different meetings, different coffee. But the kicker: we are actually afraid of the exact same thing.

The Bus Factor

The Bus Factor answers a slightly dark question:

How many people can leave before the project becomes a serious risk?

If the answer is one, I have bad news for you. Your project has a Bus Factor of 1, and your company is basically running a software hostage situation.

This happens more often than we'd like to admit.

One developer knows:

How the authentication flow actually works
Why the billing logic requires three retries and a silent prayer
What that "temporary hack" from 2019 is still doing there

And suddenly that developer leaves.

New job.
New city.
Maybe a goat farm in New Zealand.

And just like that…

the company loses part of its brain.

Corporate Amnesia

Corporate Amnesia happens when developers leave, taking with them institutional knowledge:

Context: Why this technology or design was chosen
Constraints: Hidden pitfalls and fragile areas of the code
Trade-offs: Decisions and compromises made over time

Even the best documentation can become outdated if not constantly maintained.

If the codebase looks like a museum of experimental spaghetti, all that knowledge is diluted or lost. The product exists, but nobody fully understands how it works anymore.

That is not just a technical problem, that's a serious financial risk.

The Ghost of Developers Past

Every developer has experienced this:

You open a file.
You scroll.
And scroll again.

Then you find it: A 500-line useEffect(), with no comments and variables like temp, data2, and finalFinalVersion.

Git history? The author left the company two years ago. Possibly raising goats in New Zealand.

You’re staring at a haunted codehouse: too risky to delete, impossible to touch safely.
This is the Ghost of Developers Past, silently costing thousands in lost productivity every day.

Clean Code as Knowledge Transfer

This is where Clean Code changes perspective.

Clean Code is not aesthetic, it’s strategic communication.

When code is clean, knowledge stays in the system even when people leave. Every future developer understands:

What the code does
Why it exists
How it interacts with the system

without scheduling a meeting with archaeology experts.

Let's take this example:

❌ The Cryptic Way

function processData(d){
  let t = d.filter(x => x.a)
  let r = []
  for(let i=0; i<t.length; i++){
    if(t[i].b > 10){
      r.push(t[i])
    }
  }
  return r
}

✅ The Clean Way

function getActiveUsersWithHighScore(users) {
  const ACTIVE_THRESHOLD = 10;
  
  return users
    .filter(user => user.isActive)
    .filter(user => user.score > ACTIVE_THRESHOLD);
}

The logic is the same, but the second version communicates the intent. Knowledge is preserved inside the code, not just in a developer’s head.

Refactoring as Insurance

There's a common argument in many companies:

"We don't have time for refactoring"

But from a business perspective, the real question should be different:

"How expensive will it be when nobody understands this code anymore?"

Every hour spent turning a Frankenstein function into something readable is not wasted time.

It's an investment in:

Onboarding Speed: New hires become productive in days instead of months
Team Autonomy: Anyone can safely modify any part of the system
Resilience: When developers leave, the project survives

In other words: refactoring is literally an insurance against corporate amnesia.

Code is Documentation

Code is the best documentation when written well. Clear naming, small focused functions, and understandable architecture preserve knowledge.

Unlike static docs, clean code doesn’t get outdated by neglectit evolves with the system.

Clean Code in the age of AI

Today we are entering a new phase of software development.

AI tools, like code assistants, can generate functions, components, and even entire modules in seconds.

This changes productivity, but it also raises the stakes for code quality.

If AI generates code on top of a messy architecture, it simply accelerates chaos, but when the codebase is clean and well structured, AI becomes incredibly powerful:

it understands the architecture faster
it generates better suggestions
it reduces development time without increasing complexity

In other words, Clean Code becomes the foundation for effective AI-assisted development.

Bad code slows humans and bad code slows AI too.

Mini takeaway

If there's one takeaway:

>Clean Code isn’t about elegance, it’s about organizational memory.

The longer your project exists, the more valuable this becomes.

Final thought

After my MBA, one thing became clear: Clean Code is a business strategy. It protects against knowledge loss, reduces onboarding friction, and makes teams resilient to change.

Since developers change jobs more often than code changes repositories, clean code is one of the best investments a company can make.

One question for you

How much of your system lives:

Inside the codebase
Inside someone's head

Share your thoughts in the comments!

Stop Writing Messy States: Why I Swapped useEffect for React Router Loaders

Wed, 25 Feb 2026 13:47:56 +0000

We have all been there... You create a new component, and the first thing you do is set up the trinity of data fetching state:

loading
error
data

Then, you write the inevitable useEffect hook. It usually looks something like this:

const [user, setUser] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);

useEffect(() => {
  const fetchData = async () => {
    try {
      const response = await fetch(url);
      if (!response.ok) throw new Error('Network response was not ok');
      const result = await response.json();
      setUser(result);
    } catch (err) {
      setError(err);
    } finally {
      setLoading(false);
    }
  };
  fetchData();
}, [url]);

if (loading) return <Spinner />;
if (error) return <ErrorMessage />

The Problem:

Boilerplate: We just wrote 20 lines of code just to get data from A to B.

Render-then-Fetch: The component has to mount (render) first before the effect kicks in to start fetching. This causes a waterfall effect and slower perceived performance.

State Management Hell: You are manually managing loading and error states in every single component that needs data.

The Solution: React Router Loaders introduced in v6

React Router v6.4+ introduced a paradigm shift: Loaders

Loaders are a part of the Data APIs which lets you handle data fetching, actions/mutations and error handling directly in your route definitions

The idea is simple: Fetch-then-Render.

Instead of the component asking for data after it mounts, the Router fetches the data before it renders the component. If the data isn't ready, the component doesn't load. If there is an error, the Router handles it elsewhere.

Here is how to clean up your code in 3 steps:

It's assumed you're working on a react application with react-router installed

Step 1: Setup Router that supports Data APIs

This will involve reconfiguring the router setup see Picking a Router

//App.jsx

// From this
import {BrowserRouter, Routes, Route} from "react-router"
import UserProfile from "./user"

function App() {
  return (
   <BrowserRouter>
      <Routes>
        <Route path="/" element={<UserProfile />} />
      </Routes>
    </BrowserRouter>
  )
}

//To this
import {RouterProvider, createBrowserRouter} from "react-router"
import UserProfile from "/user"

const router = createBrowserRouter([
  {
    path: '/user',
    element: <UserProfile />
  }
])

function App() {
  return (
    <RouterProvider router={router} />
  )
}

Step 2: Write a loader function

You define a function that fetches your data.

// utils.js
export const userLoader = async () => {
  const res = await fetch('https://api.example.com/user');

  if (!res.ok) {
    throw Error("Could not fetch user details");
  }

  return res.json();
}

Step 3: Connect it to the Route

In your Router configuration (using createBrowserRouter), you plug the loader directly into the route.

// App.jsx
import { createBrowserRouter, RouterProvider } from 'react-router-dom';
import { userLoader } from './utils';
import UserProfile from './user';
import ErrorPage from './errorPage';

const router = createBrowserRouter([
  {
    path: '/user',
    element: <UserProfile />,
    loader: userLoader,       // <--- The magic happens here
    errorElement: <ErrorPage /> // <--- Handles errors automatically!
  }
]);

function App() {
  return <RouterProvider router={router} />;
}

Step 3: Consume the Data

Now, look at how clean your component becomes. No useEffect, No useState for loading or errors. Just one hook: useLoaderData

// user.jsx
import { useLoaderData } from 'react-router';

export default function UserProfile() {
  const user = useLoaderData(); // Data is already here!

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
    </div>
  );
}

>In the ErrorPage, you can get error message and handle error by grabbing the useRouteError hook from "react-router", implementation is similar to useLoaderData

Why this is Clean Code?

Separation of Concerns: Your UI component is responsible for UI, not fetching logic. The fetching logic lives in the loader.
Automatic Error Handling: If the API fails, React Router catches the error and renders the errorElement defined in the route. Hence, your component doesn't need to check if (error).
Performance: The browser starts fetching the data as soon as the user clicks the link, in parallel with loading the code for the new page.

Conclusion

useEffect is a powerful tool but using it for data fetching in 2025 is often unnecessary complexity. By switching to Loaders, you delete code, prevent bugs, and make your application feel snappier.

Give your useEffect a break and let the Router do the heavy lifting.

Debugging Bash Scripts Like a Pro

Wed, 28 Jan 2026 09:13:31 +0000

Bash scripting is one of those skills every developer uses, but very few truly master. We write quick scripts to automate tasks, glue systems together, or run background jobs and then one day, something breaks. The script silently fails, produces the wrong output, or behaves differently in production than it did locally.

That’s where proper debugging comes in.

Debugging Bash scripts doesn’t have to feel like guesswork or endless echo statements. With the right techniques, you can understand what your script is doing, why it’s failing, and how to fix it efficiently without losing your sanity.

This guide walks through practical, professional Bash debugging techniques that still matter in 2026.

Why Bash Scripts Are Hard to Debug

Before diving into tools, it helps to understand why Bash can be tricky:

Bash fails silently by default
Errors don’t always stop execution
Variables can expand unexpectedly
Whitespace and quoting matter more than you think

Most issues come from assumptions: assuming a command succeeded, assuming a variable exists, or assuming the environment behaves the same everywhere.

Good debugging habits eliminate those assumptions.

1. Start With Strict Mode

One of the best things you can do for any Bash script is enable strict mode at the top:

set -euo pipefail

Here’s what each part does:

-e: Exit immediately if a command fails
-u: Treat unset variables as errors
-o pipefail: Catch failures inside pipelines

This turns silent failures into visible ones and saves hours of confusion later.

2. Use `set -x` to Trace Execution

When things get weird, tracing is your best friend.

set -x

This tells Bash to print each command after variable expansion but before execution. You’ll see exactly what Bash is running.

To limit noise, enable it only where needed:

set -x
# suspicious section
set +x

This is especially useful when debugging loops, conditionals, or dynamic commands.

3. Log Intentionally (Not Randomly)

Sprinkling echo "here" everywhere works… until it doesn’t.

Instead:

Log meaningful state
Include variable values
Be explicit about what the script is doing

Example:

echo "Starting backup for user=$USER at $(date)"

For long-running scripts, consider logging to a file:

exec >> /var/log/myscript.log 2>&1

Now stdout and stderr are captured for later inspection.

4. Check Exit Codes Explicitly

Not every failure throws an error.

Instead of assuming success:

command
if [ $? -ne 0 ]; then
  echo "Command failed"
  exit 1
fi

Or more idiomatically:

command || {
  echo "Command failed"
  exit 1
}

This makes failure paths obvious and predictable.

5. Quote Everything (Yes, Everything)

Unquoted variables are one of the most common sources of bugs.

Bad:

rm $FILE

Good:

rm "$FILE"

Without quotes, Bash performs word splitting and glob expansion—leading to broken logic or destructive behavior.

If a script behaves inconsistently, always check your quoting first.

6. Debug Conditionals and Tests Carefully

Bash conditionals are powerful but subtle.

Prefer [[ ... ]] over [ ... ]:

if [[ "$value" == "yes" ]]; then
  ...
fi

Use -z and -n for string checks:

[[ -z "$VAR" ]] && echo "VAR is empty"

When conditionals fail unexpectedly, echo the evaluated values to confirm assumptions.

7. Validate Inputs Early

Many bugs come from unexpected input.

Always validate arguments:

if [[ $# -lt 1 ]]; then
  echo "Usage: $0 <filename>"
  exit 1
fi

Fail fast. It’s much easier to debug a script that refuses to run than one that runs incorrectly.

8. Use ShellCheck (Seriously)

If you only adopt one habit from this article, make it this.

ShellCheck is a static analysis tool that catches:

Quoting mistakes
Undefined variables
Logical errors
Common Bash pitfalls

Run it locally or in CI:

shellcheck myscript.sh

It’s like having a Bash expert review your script every time.

9. Test in a Clean Environment

Scripts often work locally and fail elsewhere because:

Environment variables differ
Paths aren’t the same
Permissions change

Test scripts with:

env -i bash myscript.sh

This strips the environment and reveals hidden dependencies you didn’t realize your script had.

10. Know When Bash Isn’t the Right Tool

Debugging isn’t just about fixing bugs it’s also about recognizing limits.

If your script:

Grows beyond a few hundred lines
Needs complex state or data structures
Requires extensive error handling

That’s not a Bash failure it’s a signal. Moving to Python, Go, or another language may reduce complexity and debugging time.

Final Thoughts

Professional Bash debugging isn’t about memorizing tricks it’s about mindset.

Assume things will fail
Make failures visible
Log intentionally
Validate aggressively

Bash remains incredibly relevant in 2026, especially for automation, servers, and glue code. When you know how to debug it properly, it stops being fragile and starts becoming powerful.

If this helped you level up your Bash skills, share it with another developer and keep scripting smarter.

Code Utopia in 2026: The Four Pillars of Production-Ready Code

Sun, 18 Jan 2026 12:08:22 +0000

As we kick off 2026, the pace of software development has never been faster—or more demanding. AI-assisted coding tools are ubiquitous, cloud-native architectures dominate, and users expect applications that are instant, intuitive, and unbreakable. Yet many codebases still feel chaotic: technical debt piles up, outages surprise us, and security vulnerabilities lurk in the shadows.
True production-ready code—the kind that powers reliable, scalable products people depend on—requires intentional discipline. In my experience building full-stack AI systems and shipping them to production, four pillars consistently separate maintainable, high-impact code from the rest:
Structure • Function • Performance • Security
Master these, and you approach what I call codebase utopia: a system that’s clean, predictable, fast, and resilient—even as it evolves over years.

1. Structure: The Foundation Everything Rests On
Well-structured code is readable, modular, and extensible. Without it, even the most brilliant features become unmaintainable.

Follow established principles like SOLID and separation of concerns.
Use consistent architecture patterns (e.g., clean/hexagonal architecture, feature-sliced design in frontend).
Enforce naming conventions, directory layout, and code formatting automatically (Prettier, Black, Ruff, or ESLint).

In 2026, AI tools like Claude code, Google Antigravity, Cursor or GitHub Copilot make refactoring easier than ever, but they still need a solid structure to suggest meaningful improvements. A poorly structured codebase confuses both humans and AI.

2. Function: Does It Do What It Should—Correctly and Completely?
Functional correctness is non-negotiable. The code must deliver the intended behavior under all expected (and many unexpected) conditions.

Write comprehensive tests: unit, integration, and end-to-end.
Adopt test-driven development (TDD) or at least property-based testing for critical paths.
Validate inputs rigorously and handle edge cases explicitly.

Modern frameworks (FastAPI, Next.js) and tools (Pydantic, Zod) make runtime validation almost effortless. In production systems—especially those using LLMs or RAG pipelines—functional correctness also means guarding against hallucination or malformed outputs.

3. Performance: Fast Today, Scalable Tomorrow
Users abandon slow apps, and inefficient code burns money in the cloud.

Profile early and often (PyInstrument, React DevTools, Google Cloud Profiler).
Optimize hot paths: choose the right data structures, cache aggressively, and leverage vectorized operations (Pandas → Polars is a common 2026 win).
Design for horizontal scaling from the start—stateless services, efficient database queries, and async where appropriate.

With AI workloads exploding, efficient token usage and smart batching in LLM calls have become a new performance frontier.

4. Security: Build Trust by Default
Security is no longer an afterthought—it’s baked in.

Apply secure-by-design principles: least privilege, defense in depth.
Use vetted libraries, keep dependencies updated (dependabot, renovate).
Implement authentication/authorization properly (OAuth2, JWT with short expiry), sanitize inputs, and protect against common vectors (OWASP Top 10).

In the age of autonomous agents and RAG systems pulling external data, security also means validating retrieved context and preventing prompt injection.

The Often-Missing Fifth Pillar: Observability
While the four pillars above are essential, one element is frequently overlooked yet critical in 2026 production systems: observability.
Logs, metrics, traces, and alerts (OpenTelemetry, Prometheus, Grafana) let you understand what’s happening inside your running system. Without observability, even perfectly structured, functional, performant, and secure code can fail silently in production. It’s the feedback loop that turns good code into great, long-lived code.

Toward Utopia
Code utopia isn’t a mythical perfect codebase—it’s one that consistently delivers value with minimal surprise. By prioritizing structure, function, performance, security, and adding strong observability, we can build systems that scale with our ambitions.
What’s your biggest challenge on the road to production-ready code in 2026? Drop a comment—I’d love to hear your thoughts.

Upgrade your debugging skills and code like a PRO

Thu, 04 Dec 2025 10:41:46 +0000

Wrapping your head around some mysterious bugs can sometimes be very tricky. However, be it 99 or 127 little bugs, systematic debugging can patch them all!

This is the first part of our small series of tips for junior developers focused on having a systematic routine while debugging the code.

As we’ve seen with many junior developers - and have gone through it by ourselves as well - when we end up with an error, we panic and start doing random quick changes in our code to see if anything would make the error message go away. However, this approach does not fix any bugs, but unfortunately brings even more of them into the code. This is because we are trying to quickly cover the obvious symptoms rather than spend time to understand the root cause. Consequently, the problem is solved only partially and our quick fix can lead to other issues. The whole process then becomes a never-ending circle where fixing one thing crashes another one.

Instead, it’s much better to calm down, take a deep breath, and start with a systematic approach.

The first step to successful debugging is reading the error message. We know, it's obvious. However, properly reading the message can tell you what file the error is coming from. Specifically, it can tell you what line the error is coming from. This provides you with a great starting point to examine and ultimately fix the problem. This is the first and most important step with which you should start every debugging as it will save you a lot of time as well as your mental health.

If you are not finding the error by reading the error message, the next thing you should do is to systematically eliminate possible sources of the error. This means, start at the beginning, take a small part of your code and make sure it behaves correctly. Once confirmed, start adding other smaller parts to it and check again that it works as you would expect. Unit testing can greatly help you with this process of elimination. By systematically sorting the good parts of the code from the bad ones guarantees that you will find the cause of the problem and make the debugging much quicker.

It’s also important to be fresh and not to get stuck with the small part of the code forever. We know it can be frustrating to be stuck on one problem and not seeing the solution but really don’t waste your time on thinking: “It’s impossible”! Sometimes it’s just better to ask google or your colleagues. :)

Once the code is working it’s a good idea to look at it as part of a bigger picture and make sure that code metrics such as Cyclomatic Complexity, Coupling Between Objects, etc. are at a reasonable level. By doing so you are making the code more readable and maintainable which helps to prevent many bugs or makes finding and fixing them faster.

Codeac helps you guard all the important metrics and many others to give you actionable feedback and insight about the current state of your codebase. This will help you keep track of your code quality and will help you to be an even better developer!

Outstanding developers make the process mentioned above as part of their routine. This means every time a bug occurs, they stay calm, and know exactly what has to be done thanks to the step by step approach. So remember, read the error message thoroughly to locate the issue, if it doesn't help start working with a small functional part of the code and add more to it while making sure the code still works. And finally, don’t hesitate to ask your colleagues when you get stuck. After all, we all want the same thing - working code that’s clean and without any bugs.

Current software design problems addressed in a minimalist way.

Mon, 06 Oct 2025 00:52:48 +0000

What is (wrong with) software?

Software is eating the world. If you work, live, and love software, you usually do not stop to think about its meaning

TL;DR: Current software design problems addressed in a minimalist way.

In university and industry, you often find the following definition of software:

Software is a set of instructions that with certain input data generates output data.

This is the definition of a computer program according to Wikipedia:

A computer program is a collection of instructions that can be executed by a computer to perform a specific task.

Many decades ago, computer scientists understood that software is much more than a program.

They still lack clear definitions of what is software.

Again, according to Wikipedia:

Computer software, or simply software, is a collection of data or computer instructions that tell the computer how to work. This is in contrast to physical hardware, from which the system is built and performs the work.

This definition works by contrast (everything that is not hardware) or by omission (everything you cannot kick but can only curse).

Yet, the only purpose of building software is:

To mimic something that happens in a possible reality.

This was essential during the origins of modern programming languages like Simula.

Simula was the first object-oriented programming language to include classification.

In the language, it was clear from the name that the goal of software construction was to build a simulator.

This is the case for most computer software applications today.

Returning to the origins you can define the software as the construction of a:

(M)odel: (A)bstract (P)artial and (P)rogrammable (E)xplaining (R)eality.

Why is it a (M)odel?

The model is the outcome of observing a certain aspect of reality.

Built under a certain lens, perspective, and paradigm.

It is not the revealed truth.

It is the best possible conception at a given moment with the available knowledge.

Since Plato’s time, human beings have tried to build good models of reality.

Why is it a (A)bstract?

You can only understand and observe it with instruments such as a black box based on its behavior in the face of your stimuli.

Like Schrödinger’s cat.

You cannot know what state it is in without disturbing it with our measuring instruments.

The use case technique is an excellent tool to describe a model in a declarative way.

If you are not a declarative programmer, you might lose your job very soon.

Why is it (P)rogrammable?

It has to run in some type of simulator that reproduces the desired conditions.

It can be a Turing model (current commercial computers), a quantum computer, or any type of simulator capable of evolving with the model.

Why is it (P)artial?

You need to make a partial cut of the reality for the problem you are modeling.

This is common to scientific models.

You take simplifications on aspects that are not relevant to isolate the problem.

A 1:1 scale map of the earth would not make sense.

Why is it (E)xplanatory?

The model must be declarative enough to let you observe its evolution.

It allows you to reason about and predict behaviors in the reality you are modeling.

Why is it about (R)eality?

Because it has to reproduce conditions that occur in an observable environment.

The ultimate goal is to forecast the real world, like any simulation.

Once you define the software, you can begin to infer good modeling and design practices.

Starting Point

You have the axiomatic definition presented in this article.

From it, you will infer principles, heuristics, and rules to build excellent software models.

%[https://maximilianocontieri.com/the-one-and-only-software-design-principle]

Acknowledgements

These concepts are based on the thoughts of David West, Máximo Prieto and Hernán Wilkinson.

Part of the goal of this series of articles is to generate spaces for debate and discussion on software design.

%[https://maximilianocontieri.com/object-design-checklist]

I look forward to comments and suggestions on this article.

Spanish version: ¿Qué es(tá mal en) el software?