Reading Code Like an Engineer

Easy

Engineers spend 80% of their time reading code, not writing it. This concept teaches systematic approaches to understanding unfamiliar code: identifying inputs/outputs, finding the happy path, using variable names as clues, and understanding why comments exist.

Interactive Visualization

1function calculateTotal(items, taxRate) {
2 let subtotal = 0;
3 for (const item of items) {
4 subtotal += item.price;
5 }
6 return subtotal * (1 + taxRate);
7}
Step 1/3Start by identifying WHAT goes in and WHAT comes out. Ignore the body for now.
💡 Key Insight:Before reading the body, understand the contract: what goes in, what comes out.
Input
Output
Happy Path
Edge Case
Comment

Key Points

  • Professional developers spend most time reading existing code
  • Start by identifying inputs (parameters) and outputs (return value)
  • Find the "happy path" first - the normal successful flow
  • Variable and function names are documentation - read them carefully
  • Comments explain WHY, not WHAT (code explains what)
  • Trace execution mentally before making changes

Code Examples

Step 1: Identify Inputs and Outputs

function calculateTotal(items, taxRate) {
  // INPUT: items (array), taxRate (number)

  let subtotal = 0;
  for (const item of items) {
    subtotal += item.price;
  }

  return subtotal * (1 + taxRate);
  // OUTPUT: number (total with tax)
}

Before reading the body, understand what goes in and what comes out

Step 2: Find the Happy Path

function getUserData(userId) {
  // Edge case handling (read later)
  if (!userId) return null;
  if (cache.has(userId)) return cache.get(userId);

  // HAPPY PATH: normal successful flow
  const user = database.find(userId);
  cache.set(userId, user);
  return user;
}

Skip error handling on first read. Understand what happens when everything works.

Step 3: Read Names Carefully

// Names tell a story:
const isValidEmail = email.includes("@");
const hasPermission = user.role === "admin";
const shouldRetry = attempts < maxAttempts;

// Good names are self-documenting:
function sendWelcomeEmail(newUser) { ... }
function calculateShippingCost(order) { ... }

Developers choose names to communicate intent. Trust them as documentation.

Step 4: Comments Explain Why

// BAD comment (explains WHAT - we can see that):
// Add 1 to counter
counter += 1;

// GOOD comment (explains WHY):
// Offset by 1 because array indices start at 0
// but our API expects 1-based positions
position = index + 1;

If a comment explains what code does, it should probably be deleted. Good comments explain why.

Common Mistakes

  • Trying to understand every line before the overall structure
  • Ignoring function and variable names as hints
  • Not identifying the happy path first
  • Reading comments as absolute truth (they can be outdated)

Interview Tips

  • In code reviews, show you understand the code before suggesting changes
  • Verbalize your reading process in pair programming
  • "What does this function do?" - start with inputs and outputs