Senior 7 min · March 29, 2026

Copy-Paste Code Bugs — Why One Function Beats Ten Copies

A rounding bug fixed in checkout but missed in 10 other copies cost $40K.

N
Naren · Founder
Plain-English first. Then code. Then the interview question.
About
 ● Production Incident 🔎 Debug Guide
Quick Answer
  • Core coding concepts: variables, functions, loops, conditionals, data structures — the building blocks of every program
  • Variables store data with a type; use integer cents for money, never floats
  • Functions encapsulate reusable logic; one job per function prevents copy-paste bugs
  • Loops repeat code; prefer for-each over index-based for safety
  • Conditionals branch execution; keep conditions simple or extract into named booleans
  • Data structures determine performance; HashMap for O(1) key lookup, Set for membership, List for ordered sequences
  • Production insight: wrong data structure at scale causes latency spikes; duplicated logic creates silent diverging bugs
Plain-English First

Think of a program like a restaurant kitchen. Variables are the containers on the shelf — a bowl for flour, a pot for stock. Functions are the recipes: a fixed set of steps that turn raw ingredients into a dish, and you can run that recipe as many times as you want without rewriting it. Loops are the line cook cracking 200 eggs one at a time until the batch is done. Conditionals are the head chef's rule: if the steak is under 55°C, it goes back on the grill — otherwise, it goes to the pass. The whole kitchen runs on these four ideas, and so does every piece of software ever written.

A startup I consulted for lost $40,000 in a single weekend because a developer copy-pasted the same 30-line pricing calculation in eleven different places, tweaked one copy to fix a rounding bug, and forgot the other ten. Every concept covered here exists specifically to prevent that kind of disaster.

These aren't beginner topics you graduate from. They're the atomic units that everything else — microservices, machine learning pipelines, distributed databases — is built from. Get them fuzzy in your head and you'll spend your career fighting symptoms instead of understanding causes. Get them sharp and you'll read unfamiliar codebases like a native speaker reads a newspaper.

By the end of this you'll be able to: write a function that does exactly one thing and does it predictably, use loops without accidentally running them forever, make your program take different paths based on real conditions, and pick the right data structure so you're not searching a 10,000-item list one-by-one when you don't have to. Concrete skills. Not vocabulary.

Variables and Data Types: Why Naming Things Correctly Saves Your 3am

Before variables existed in a structured way, early programmers worked with raw memory addresses — literal hexadecimal locations like 0x00A4. Change anything about your program and those addresses shift. You've now broken everything and the compiler won't help you find it. Variables are the abstraction that saves you from that nightmare. You give a meaningful name to a storage location and let the machine worry about where it actually lives.

Every variable has two properties that matter: its name and its type. The name is for humans. The type tells the computer how many bytes to reserve and what operations are legal. You can multiply two integers. You can't multiply two words. This sounds obvious until you're debugging a Node.js service at 2am where JavaScript silently coerced the string '42' into the number 42 mid-calculation and your invoice totals are now subtly wrong across 6,000 orders.

Name your variables after what they contain, not how they're used. orderTotalInCents is a variable. x is a crime. The person debugging your code at midnight might be you, and future-you will not remember what x meant. Every variable name is a comment you don't have to maintain separately.

Data types are the contract the variable makes with the rest of your code. An integer promises it's a whole number. A boolean promises it's either true or false — never null, never 'yes', never 1. Break the contract and your program either crashes loudly (good) or silently does the wrong thing (catastrophic). Always prefer explicit types over letting the language guess. The three minutes you save by not typing the type will cost you three hours when the guess is wrong.

OrderPricingService.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
package io.thecodeforge.cs;

public class OrderPricingService {

    public static void main(String[] args) {

        // Store the price in CENTS (integer), never floating-point dollars.
        // Floats cannot represent 0.10 exactly — this has caused real billing bugs.
        int unitPriceInCents = 1099;   // $10.99 per item
        int quantityOrdered  = 3;      // How many the customer wants

        // A boolean that controls downstream logic — shipping rules, tax rules, etc.
        // Name it as a statement that is either true or false, never 'flag' or 'status'.
        boolean isEligibleForFreeShipping = false;

        // String for human-readable display only — never do arithmetic on this.
        String productName = "Wireless Keyboard";

        // Calculate total: integer multiplication — no floating-point rounding errors.
        int orderTotalInCents = unitPriceInCents * quantityOrdered;

        // Apply free shipping threshold: orders over $50 (5000 cents) qualify.
        // We check BEFORE formatting, so the logic lives here — not scattered in the UI.
        if (orderTotalInCents >= 5000) {
            isEligibleForFreeShipping = true;
        }

        // Format for display ONLY at the very end — never store dollars as a double.
        double orderTotalInDollars = orderTotalInCents / 100.0;

        System.out.println("Product       : " + productName);
        System.out.println("Unit price    : $" + String.format("%.2f", unitPriceInCents / 100.0));
        System.out.println("Quantity      : " + quantityOrdered);
        System.out.println("Order total   : $" + String.format("%.2f", orderTotalInDollars));
        System.out.println("Free shipping : " + isEligibleForFreeShipping);
    }
}
Output
Product : Wireless Keyboard
Unit price : $10.99
Quantity : 3
Order total : $32.97
Free shipping : false
Production Trap: Never Store Money as a Float
double price = 0.10 + 0.20 gives you 0.30000000000000004 in Java, JavaScript, Python — every language. That four-trillionths of a cent becomes a rounding error that accumulates across millions of transactions. Store all monetary values as integer cents (or use BigDecimal if you must use decimal). This exact bug has triggered financial audits at companies I've worked with.
Production Insight
Type coercion in dynamically-typed languages is the #1 source of silent variable bugs.
In production, a string concatenation that looks like addition can corrupt thousands of records before anyone notices.
Rule: Use explicit type annotations and never mix types in arithmetic operations.
Key Takeaway
Name variables by what they contain, not how they're used.
Store money as integer cents — never use floats for currency.
Explicit types > implicit guessing — the compiler catches what you miss.

Functions: The One Rule That Prevents the Copy-Paste Death Spiral

The startup I mentioned in the intro? Their root cause was a violation of the most important rule in software: write a piece of logic once, name it, and call it. That's a function. Every time you copy-paste code instead of extracting a function, you create a new place where bugs can hide independently of each other.

A function takes inputs (called parameters), does something predictable with them, and returns an output. That's the whole deal. The power isn't the syntax — it's the contract. When calculateDiscountedPrice is called 500 times across your codebase and you fix a bug in it, you've fixed it in all 500 places simultaneously. Copy-paste gives you 500 separate bugs waiting to diverge.

The rule that separates functions that age well from functions that become nightmares: one function, one job. If you find yourself writing processOrderAndSendEmailAndUpdateInventory, stop. That's three functions being smuggled inside one name. Functions that do one thing are trivially testable, trivially debuggable, and trivially reusable. Functions that do three things in a trench coat are none of those things.

Parameters are the inputs your function needs to do its job. Return values are the output it promises to produce. Keep both small. A function that needs 8 parameters to work is a sign that either you need a data object to group them, or the function is doing too much. I've seen functions at FAANG-adjacent companies with 14 parameters. Every single one was a maintenance timebomb waiting on a deadline.

DiscountCalculator.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
package io.thecodeforge.cs;

public class DiscountCalculator {

    /**
     * Calculates the discounted price in cents.
     * Single responsibility: take a price and a discount rate, return the result.
     * No side effects — doesn't print, doesn't update a database, doesn't log.
     * That makes it testable in isolation without mocking anything.
     *
     * @param originalPriceInCents  The pre-discount price (must be >= 0)
     * @param discountPercentage    Discount as a whole number 0-100 (e.g. 20 means 20% off)
     * @return                      The price after discount, in cents
     */
    public static int calculateDiscountedPrice(int originalPriceInCents, int discountPercentage) {

        // Guard clause: reject bad input immediately rather than silently computing garbage.
        // Failing fast here beats returning a wrong price that reaches the payment processor.
        if (originalPriceInCents < 0) {
            throw new IllegalArgumentException("Price cannot be negative: " + originalPriceInCents);
        }
        if (discountPercentage < 0 || discountPercentage > 100) {
            throw new IllegalArgumentException("Discount must be 0-100, got: " + discountPercentage);
        }

        // Calculate discount amount first, then subtract — avoids floating-point math.
        int discountAmountInCents = (originalPriceInCents * discountPercentage) / 100;
        return originalPriceInCents - discountAmountInCents;
    }

    /**
     * Formats a cent value into a human-readable dollar string.
     * Separate function because formatting is a different job from calculating.
     * Now you can change your currency display format in one place.
     */
    public static String formatAsDollars(int amountInCents) {
        return String.format("$%.2f", amountInCents / 100.0);
    }

    public static void main(String[] args) {

        int originalPrice = 4999;  // $49.99
        int discountRate  = 20;    // 20% off

        // Call the function — same logic works for every product without copy-pasting.
        int discountedPrice = calculateDiscountedPrice(originalPrice, discountRate);

        System.out.println("Original price  : " + formatAsDollars(originalPrice));
        System.out.println("Discount        : " + discountRate + "%");
        System.out.println("Discounted price: " + formatAsDollars(discountedPrice));
        System.out.println("You save        : " + formatAsDollars(originalPrice - discountedPrice));
    }
}
Output
Original price : $49.99
Discount : 20%
Discounted price: $39.99
You save : $10.00
Senior Shortcut: Guard Clauses First, Logic Second
Always validate your inputs at the top of the function and return/throw immediately if they're wrong. This is called a guard clause. It keeps the happy path un-nested and readable, and it means your function's core logic never runs on garbage data. The alternative — wrapping everything in a giant if-else — is how you get 8-level indentation that nobody wants to touch.
Production Insight
Copy-pasted logic is the leading cause of production inconsistency bugs.
I've seen a pricing error in a checkout flow that didn't affect reports because the report module had its own copy.
Rule: When you fix a bug, search your entire codebase for duplicate logic before marking it resolved.
Key Takeaway
Extract the first duplicate into a function — don't wait for three copies.
One function, one job — if the name contains 'and', split it.
Guard clauses protect your function from garbage inputs.

Loops and Conditionals: Controlling What Runs, How Many Times, and When

These two concepts are where programs stop being calculators and start being intelligent. A calculator computes one fixed thing. A program decides what to do based on conditions and can repeat work without you spelling out every step.

A conditional (if/else) is a fork in the road. Your program evaluates a statement that is either true or false, then takes the appropriate path. The condition must be binary — it can't be 'sort of true'. This is why booleans exist. When you see developers stuffing complex logic into a condition — five AND operators, two OR operators, a function call, and a negation — that's a sign the logic needs a named function. if (isOrderEligibleForExpressShipping(order)) is readable. if (!order.weight > 5 && order.destination != null && (order.tier == 'GOLD' || order.totalInCents > 10000) && !order.isFlaggedForReview) is a bug you haven't found yet.

A loop repeats a block of code until a condition is no longer true. The most dangerous thing a loop can do is run forever — an infinite loop that never exits will freeze your program and, in server environments, consume 100% of a CPU core until the process is killed. I've seen this happen in production when a while-loop's exit condition was accidentally set inside an if-block that never triggered, and the thread sat spinning for 40 minutes before monitoring caught it.

The most common loops you'll use: for when you know exactly how many times to repeat, while when you repeat until a condition changes, and for-each when you're walking every item in a collection. Don't use a while where a for is clearer. The right loop for the job makes the intent obvious without reading the body.

ShoppingCartProcessor.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
package io.thecodeforge.cs;

import java.util.Arrays;
import java.util.List;

public class ShoppingCartProcessor {

    // Represents a single item in a shopping cart.
    // Using a record-style structure so the data is obvious at a glance.
    static class CartItem {
        String  productName;
        int     priceInCents;
        int     quantity;
        boolean isPerishable;  // Perishables need cold-chain shipping — different logic applies.

        CartItem(String productName, int priceInCents, int quantity, boolean isPerishable) {
            this.productName  = productName;
            this.priceInCents = priceInCents;
            this.quantity     = quantity;
            this.isPerishable = isPerishable;
        }
    }

    public static void main(String[] args) {

        // A realistic cart — three different products, one perishable.
        List<CartItem> cart = Arrays.asList(
            new CartItem("Wireless Keyboard",  4999, 1, false),
            new CartItem("USB-C Hub",          2999, 2, false),
            new CartItem("Organic Greek Yoghurt", 349, 4, true)
        );

        int cartTotalInCents    = 0;
        boolean requiresColdChain = false;  // Flipped to true if ANY item is perishable.

        // for-each loop: we don't need an index, we just need every item.
        // This is clearer than a traditional for-loop when index doesn't matter.
        for (CartItem item : cart) {

            // Calculate line total for this item.
            int lineTotalInCents = item.priceInCents * item.quantity;
            cartTotalInCents += lineTotalInCents;  // Accumulate into the cart total.

            // Conditional: check if this item forces cold-chain shipping.
            // Once true, it stays true — one perishable item affects the whole order.
            if (item.isPerishable) {
                requiresColdChain = true;
            }

            System.out.printf("  %-25s x%d  = $%.2f%n",
                item.productName,
                item.quantity,
                lineTotalInCents / 100.0);
        }

        System.out.println("  ─────────────────────────────────────────");
        System.out.printf("  Cart total: $%.2f%n", cartTotalInCents / 100.0);

        // Conditional with else: only one path runs — not both.
        if (requiresColdChain) {
            System.out.println("  Shipping: Cold-chain required (+$12.99 surcharge)");
        } else {
            System.out.println("  Shipping: Standard");
        }
    }
}
Output
Wireless Keyboard x1 = $49.99
USB-C Hub x2 = $59.98
Organic Greek Yoghurt x4 = $13.96
─────────────────────────────────────────
Cart total: $123.93
Shipping: Cold-chain required (+$12.99 surcharge)
The Classic Bug: Off-By-One in Loop Bounds
The most common loop bug is iterating one step too far or stopping one step too early — called an off-by-one error. Classic symptom: ArrayIndexOutOfBoundsException in Java, or silently skipping the last item. If your loop touches array indices directly, double-check: does it start at 0 or 1? Does it use < length or <= length? A for-each loop eliminates this entire class of bug — use it whenever you don't need the index.
Production Insight
Infinite loops in production aren't caught by tests — they manifest as CPU spikes and timeout alerts.
The worst case: a loop that only runs forever with specific data, making it impossible to reproduce locally.
Rule: Every production while-loop needs a maximum iteration counter and a fallback.
Key Takeaway
Prefer for-each over index-based loops to eliminate off-by-one errors.
Extract complex conditionals into named boolean functions.
Always add a safety counter to while-loops that process external data.

Data Structures: Picking the Right Container Stops You Searching 10,000 Items One-by-One

A data structure is how you organise information in memory so your program can find, add, and remove it efficiently. Pick the wrong one and a lookup that should take a millionth of a second takes a full second. At scale, that's the difference between a snappy API and a timeout that pages your on-call at 2am.

The three you'll use constantly as a beginner: Arrays/Lists, HashMaps, and Sets. A List stores items in order and lets you access them by position — perfect when sequence matters, like a queue of tasks or a history of events. A HashMap stores key-value pairs and finds any value instantly by its key — perfect when you need to look something up by an identifier. A Set stores unique items with no duplicates — perfect when you need to know whether something exists, without caring about order.

The critical concept behind HashMap performance is hashing. When you store userId → userProfile, the HashMap runs a mathematical function on userId to compute a bucket number, then drops the profile in that bucket. Lookup runs the same function, finds the same bucket, and retrieves it — in constant time, meaning it takes the same amount of time whether the map has 10 entries or 10 million. A List lookup doesn't work this way — it checks item 1, then item 2, then item 3... all the way until it finds a match. On 10,000 items, that averages 5,000 comparisons per lookup. I've seen a product catalogue feature grind a server to a halt because a developer used a List of products and searched it linearly for every incoming HTTP request. Switching to a HashMap keyed by product ID dropped the p99 latency from 4,200ms to 8ms.

Use a List when order matters. Use a HashMap when you need fast lookup by a key. Use a Set when you need to know 'is this thing already in here?' without duplicates.

ProductCatalogueService.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
package io.thecodeforge.cs;

import java.util.*;

public class ProductCatalogueService {

    // Represents a product in the catalogue.
    static class Product {
        String productId;    // Unique identifier — this becomes our HashMap key.
        String name;
        int    priceInCents;
        String category;

        Product(String productId, String name, int priceInCents, String category) {
            this.productId    = productId;
            this.name         = name;
            this.priceInCents = priceInCents;
            this.category     = category;
        }
    }

    public static void main(String[] args) {

        // HashMap<Key, Value>: productId → Product object.
        // Lookup by productId is O(1) — constant time regardless of catalogue size.
        // If this were a List, lookup would be O(n) — slower as catalogue grows.
        Map<String, Product> catalogue = new HashMap<>();

        // Load catalogue — in production this would come from a database or cache.
        catalogue.put("KB-001", new Product("KB-001", "Wireless Keyboard", 4999, "Peripherals"));
        catalogue.put("HB-002", new Product("HB-002", "USB-C Hub",         2999, "Peripherals"));
        catalogue.put("MN-003", new Product("MN-003", "4K Monitor",       34999, "Displays"));
        catalogue.put("MS-004", new Product("MS-004", "Ergonomic Mouse",   3499, "Peripherals"));

        // Simulate an incoming order with product IDs — exactly what an API receives.
        List<String> orderedProductIds = Arrays.asList("KB-001", "MN-003", "XX-999");

        // Set to track which categories appear in this order — no duplicates needed.
        Set<String> categoriesInOrder = new HashSet<>();

        int orderTotalInCents = 0;

        System.out.println("Processing order:");

        for (String productId : orderedProductIds) {

            // HashMap.get() is O(1) — instant lookup, no matter how big the catalogue is.
            Product product = catalogue.get(productId);

            if (product == null) {
                // Product not found — log it and skip. Don't crash the whole order.
                System.out.println("  WARNING: Product not found in catalogue: " + productId);
                continue;  // Skip to the next item in the loop.
            }

            orderTotalInCents += product.priceInCents;

            // Set.add() ignores duplicates automatically — no need for an if-check.
            categoriesInOrder.add(product.category);

            System.out.printf("  %-10s %-25s $%.2f%n",
                product.productId,
                product.name,
                product.priceInCents / 100.0);
        }

        System.out.println("  ──────────────────────────────────────────");
        System.out.printf("  Order total: $%.2f%n", orderTotalInCents / 100.0);
        System.out.println("  Categories in this order: " + categoriesInOrder);
    }
}
Output
Processing order:
KB-001 Wireless Keyboard $49.99
HB-002 USB-C Hub $29.99
MN-003 4K Monitor $349.99
WARNING: Product not found in catalogue: XX-999
──────────────────────────────────────────
Order total: $429.97
Categories in this order: [Displays, Peripherals]
Interview Gold: What O(1) vs O(n) Actually Means in Production
O(1) means the operation takes the same time no matter how much data you have. O(n) means it takes linearly longer as data grows — double the data, double the time. A HashMap lookup is O(1). Searching a List for a specific value is O(n). At 100 items the difference is invisible. At 500,000 items it's the difference between an API that responds in 5ms and one that times out at 30 seconds. Always ask: 'what happens to this code when the data is 1000x bigger?'
Production Insight
The most common production performance bug: using a List for key-based lookup because 'it works fine in tests'.
Tests use small datasets — production data is 1000x larger, and O(n) becomes a timeout.
Rule: Choose your data structure based on the operation, not the current size.
Key Takeaway
HashMap for key lookup (O(1)).
Set for membership checks (O(1)).
List for ordered sequences — not for searching.

Error Handling: Fail Fast, Fail Clearly, Fail Recoverably

Every program encounters unexpected situations: a file doesn't exist, a network request times out, a user enters invalid input. How your code responds to these situations separates brittle systems from production-resilient ones.

Fail fast means you detect invalid state as early as possible and stop execution rather than silently propagating garbage. A null reference that gets passed through six layers of functions before finally crashing is a nightmare to debug. Check at the boundary where data enters your system — API input, file read, database query — and reject it immediately if it's invalid. Guard clauses at the top of functions do exactly this.

Fail clearly means when something goes wrong, your error message tells you exactly what happened, where, and with what data. NullPointerException at line 42 is useless. UserNotFoundException: user 'johndoe' not found in database is actionable. Log the context — the input that caused the failure, the state of the system, the stack trace — so you don't have to reproduce the bug to understand it.

Fail recoverably means when an error occurs, the system can continue operating in a degraded mode instead of crashing entirely. If the payment service is down, you can queue the order and retry later, rather than showing a 500 error to the user. If a cache lookup fails, fall back to the database and log the miss. Don't let a single failure bring down the entire request.

The alternative — catching all exceptions and doing nothing, or letting every failure crash the application — causes data corruption, customer frustration, and pager fatigue. Invest in error handling upfront: it's insurance against the 2am call.

PaymentProcessor.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
package io.thecodeforge.cs;

import java.util.logging.Logger;

public class PaymentProcessor {

    private static final Logger logger = Logger.getLogger(PaymentProcessor.class.getName());

    /**
     * Attempts to charge a customer.
     * Fails fast if inputs are invalid, fails clearly by logging the cause,
     * and fails recoverably by throwing a checked exception the caller can handle.
     */
    public static boolean chargeCustomer(String customerId, int amountInCents) {
        // Guard clause: fail fast on invalid input
        if (customerId == null || customerId.isBlank()) {
            throw new IllegalArgumentException("Customer ID must not be null or blank");
        }
        if (amountInCents <= 0) {
            throw new IllegalArgumentException("Amount must be positive, got: " + amountInCents);
        }

        try {
            // Simulated payment gateway call (could throw IOException, timeout, etc.)
            boolean success = PaymentGateway.charge(customerId, amountInCents);
            if (!success) {
                // Fail clearly: log the specific failure
                logger.warning("Payment declined for customer " + customerId + " amount " + amountInCents);
            }
            return success;

        } catch (PaymentGatewayTimeoutException e) {
            // Fail recoverably: log and rethrow as a checked exception so caller decides retry or fallback
            logger.severe("Payment gateway timeout for customer " + customerId + ": " + e.getMessage());
            throw new PaymentProcessingException("Unable to process payment, try again later", e);

        } catch (Exception e) {
            // Catch-all for unexpected errors — log FULL context, don't swallow
            logger.severe("Unexpected payment failure for customer " + customerId + ": " + e.getMessage());
            throw new PaymentProcessingException("Internal payment error", e);
        }
    }

    // Custom exception class so callers can handle payment failures specifically
    static class PaymentProcessingException extends RuntimeException {
        public PaymentProcessingException(String message, Throwable cause) {
            super(message, cause);
        }
    }

    // Stub for demonstration
    static class PaymentGateway {
        static boolean charge(String customerId, int amountInCents) throws PaymentGatewayTimeoutException {
            // simulate
            return true;
        }
    }

    static class PaymentGatewayTimeoutException extends Exception {
        public PaymentGatewayTimeoutException(String message) {
            super(message);
        }
    }
}
Output
(No output — the code demonstrates structure, not a runnable output)
The Golden Rule of Error Handling
Never catch an exception unless you can either handle it (fix the issue, retry, return a fallback) or add context (wrap it in a more meaningful exception). Catching and swallowing exceptions without logging is how data corruption happens silently. If you can't handle it, let it crash — loudly.
Production Insight
The most expensive bug I've investigated was caused by an empty catch block in a batch processor.
Exceptions were swallowed, the batch continued processing corrupted data for 6 hours.
Rule: If you catch an exception, either log it, wrap it, or handle it — never nothing.
Key Takeaway
Fail fast: validate inputs at boundaries.
Fail clearly: log context, not just stack traces.
Fail recoverably: let callers decide retry vs fallback via checked exceptions.
● Production incidentPOST-MORTEMseverity: high

Copy-Pasted Pricing Calculation Cost $40,000

Symptom
Customers were charged incorrect amounts; some were overcharged a few cents, others were undercharged by up to $5. The accounting team noticed after a weekend of transactions.
Assumption
Copy-pasting the same pricing calculation across multiple modules was harmless — each copy worked independently, so fixing one would fix all.
Root cause
The pricing logic was not extracted into a single function. A rounding bug was fixed in one copy (the checkout module) but remained in ten other places (invoice generation, email confirmations, reporting, etc.).
Fix
Extract the pricing calculation into a single function calculateDiscountedPrice(int originalPriceInCents, int discountPercentage), call it everywhere, and write a single unit test that covers the rounding edge case.
Key lesson
  • The moment you copy-paste code instead of extracting a function, you create a bug that will diverge silently from its copies.
  • One function, one test — if the logic lives in one place, fixing it fixes all callers.
  • Monetary logic must use integer cents, not floats, to avoid IEEE 754 rounding errors.
Production debug guideQuick symptom-to-action guide for common failures5 entries
Symptom · 01
Variable has unexpected value at runtime
Fix
Check for implicit type coercion (e.g., string concatenation mixing numbers) or variable shadowing in nested scopes. Print or log the variable just before its use.
Symptom · 02
Function returns wrong result or behaves inconsistently
Fix
Isolate the function with known inputs. Check parameter values at call site. Verify the function has no side effects that modify global state. Add guard clauses for invalid inputs.
Symptom · 03
Loop runs forever or crashes the thread
Fix
Inspect the exit condition — ensure the loop body modifies a variable that eventually makes the condition false. Add a maximum iteration counter as a safety valve. Use a for-each loop where possible to eliminate index errors.
Symptom · 04
Conditional takes the wrong branch
Fix
Evaluate the condition on a whiteboard — decompose complex compound conditions into separate named booleans. Log each part of the condition to find the failing sub-expression.
Symptom · 05
Data structure lookup gets slower as data grows
Fix
Identify the data structure used. Searching a List for a value is O(n). Switch to a HashMap (for key-based lookup) or HashSet (for existence check). Confirm the hashing function distributes keys evenly.
★ Quick Debug Cheat Sheet for Core ConceptsWhen something breaks, use these immediate steps before diving deep.
Function returns wrong output
Immediate action
Write a minimal test with hard-coded inputs outside the production flow.
Commands
Print all input parameters and intermediate values inside the function.
Trace the call stack to confirm the function is called with expected arguments.
Fix now
Add guard clauses for invalid inputs and return early. Extract the function if it's doing more than one thing.
Loop doesn't terminate+
Immediate action
Check the loop condition and ensure the body changes a variable that affects it.
Commands
Add a counter that increments each iteration and break after a max (e.g., 10,000).
Replace manual increment with a for-each loop over a collection if possible.
Fix now
Insert a safety valve: int iterations = 0; while (condition && iterations++ < MAX_SAFE). Investigate why condition never became false.
API response time spikes as data grows+
Immediate action
Identify the slow operation — is it a loop, a search, or a database query?
Commands
Check if you're using a List and calling `.contains()` or iterating to find an element.
Profile with a timer: log elapsed time for the suspect operation with a small dataset vs production size.
Fix now
Replace the List with a HashMap for key-based lookup or a HashSet for membership tests. Aim for O(1) operations.
Data Structure Trade-offs
Data StructureBest ForLookup SpeedAllows DuplicatesPreserves Order
List (ArrayList)Ordered sequences, history logs, task queuesO(n) — scans from startYesYes — insertion order
HashMapFast lookup by unique key (userId, productId)O(1) — instant by keyKeys: No / Values: YesNo — undefined order
HashSetMembership checks, deduplicationO(1) — instant contains()No — duplicates silently ignoredNo — undefined order
LinkedListFrequent insertions/deletions at head or middleO(n) — slow random accessYesYes — insertion order
TreeMapSorted key-value pairs, range queriesO(log n) — binary treeKeys: No / Values: YesYes — sorted by key

Key takeaways

1
Store money as integer cents, always. Display it as dollars only at the last possible moment
never do arithmetic on floats that represent currency.
2
The moment you copy-paste a block of code instead of extracting a function, you've created a bug that will diverge silently from its copies at the worst possible time.
3
Reach for a HashMap over a List the instant you find yourself searching a collection by a specific attribute
O(1) vs O(n) is irrelevant at 10 items and catastrophic at 100,000.
4
A function that does more than one thing isn't a function
it's a liability. If you can't describe what it does in a single sentence without using 'and', split it.
5
Error handling is not optional. Fail fast, fail clearly, fail recoverably. The cost of swallowing an exception is corrupted data that you won't discover until it's too late.

Common mistakes to avoid

5 patterns
×

Using a floating-point double to store monetary values

Symptom
Totals come out as $19.990000000000002 due to IEEE 754 binary representation, causing rounding errors that compound across transactions
Fix
Store all money as integer cents (int priceInCents = 1999) and only convert to decimal for display using String.format("%.2f", cents / 100.0)
×

Writing the same logic in multiple places instead of extracting a function

Symptom
You fix a bug in one copy and three other copies stay broken, producing inconsistent behaviour that's nearly impossible to reproduce
Fix
Extract to a named function the moment you write the same block twice; the rule is called DRY (Don't Repeat Yourself) and it's not optional
×

Using a List and calling contains() or searching with a loop to check if something exists

Symptom
API response times degrade linearly as the list grows, often showing as p99 latency spikes in monitoring but not in unit tests that use small datasets
Fix
Switch to a HashSet for membership checks or a HashMap for keyed lookups; both give O(1) performance regardless of collection size
×

Writing a while-loop whose exit condition can never become false

Symptom
One CPU core pegged at 100%, the thread never returns, eventually causing a timeout or process kill
Fix
Always verify that the loop body contains code that will eventually make the condition false, and add a maximum iteration counter as a safety valve in production loops that process external data
×

Catching an exception and doing nothing (empty catch block)

Symptom
The program continues running with corrupted state, producing wrong results with no error signal until downstream systems fail
Fix
Never catch an exception unless you can handle it (retry, fallback, log context). If you can't handle it, let it propagate. At minimum log the error with input context.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01SENIOR
A HashMap lookup is described as O(1), but what can cause it to degrade ...
Q02SENIOR
You have a user session store that needs to check whether a session toke...
Q03SENIOR
A function you wrote passes all unit tests but produces wrong results in...
Q01 of 03SENIOR

A HashMap lookup is described as O(1), but what can cause it to degrade to O(n) in the worst case, and how do well-designed HashMap implementations defend against this?

ANSWER
The worst case for a HashMap is when all keys end up in the same bucket, turning the lookup into a linear scan of that bucket. This happens when the hash function is poor or when an attacker crafts keys that collide intentionally (hash collision DoS attack). Defenses: Java HashMap uses a tree structure (TREEIFY_THRESHOLD = 8) to convert the linked list into a red-black tree when collisions exceed the threshold, bringing worst-case to O(log n). Also, Java randomizes the hash seed (since Java 7u6) to mitigate collision DoS. The key is to ensure your key type has a good, fast hash function that distributes entries evenly across buckets.
FAQ · 5 QUESTIONS

Frequently Asked Questions

01
What's the difference between a variable and a constant in programming?
02
What's the difference between a for loop and a while loop?
03
How do I decide what to name my variables and functions?
04
Why does HashMap order change between runs of the same program?
05
Should I ever catch an exception and do nothing with it?
🔥

That's Software Engineering. Mark it forged?

7 min read · try the examples if you haven't

Previous
Conway's Law
15 / 16 · Software Engineering
Next
Regression Testing: Definition, Types, Tools and Best Practices