Senior Engineer Coding

Senior Engineer Coding

Mindset

Write code for the next engineer who has to change it at 2am with no context. Clean code is risk management. Every production incident traces back to unclear, poorly structured, or hard-to-change code — not missing cleverness.

The standard: a teammate can safely change the code without fear, and explain what it does after a quick read.

---

1. Naming — Highest ROI Habit

Good names eliminate comments, prevent misunderstandings, and make refactoring safe.

Rules:

• Name by intent, not by type or storage: emailAddress not emailString
• Use domain language: reflect business concepts (Invoice, Subscription, Refund)
• Include units in names: timeoutMs, priceCents, fileSizeBytes
• Make booleans read as questions: isEnabled, hasAccess, shouldRetry
• Name from the caller's perspective: order.chargePayment() not order.process()
• Be consistent: one concept, one word. Never user in one place and customer in another for the same entity

Avoid:

• Noise words: manager, helper, data, info, handler (unless genuinely descriptive)
• Abbreviations that don't scale: usrAcctMgr, calcDisc
• Overly generic verbs: process(), handle(), doWork(), run()
• Single-letter variables outside tiny loops: d, x, tmp cause real production bugs

---

2. Functions — Small, Focused, Predictable

One function = one job. If you can't describe it in one sentence, it does too much.

Guard clauses over nested ifs:

// Wrong — pyramid of doom, hides assumptions
if (user != null) {
  if (user.isActive()) {
    if (hasAccess(user)) {
      process(user)
    }
  }
}

// Right — early returns, happy path stays flat
if (user == null) return
if (!user.isActive()) return
if (!hasAccess(user)) return
process(user)

Limit parameters:

• More than 3 parameters → create a request/options object
• Long param lists break silently when order is swapped; objects don't

Separate computation from I/O:

• Pure logic (calculation, transformation) → separate from functions that read files, call APIs, write DBs
• Pure functions are easier to test, easier to reason about, and have no hidden side effects