Write It Ugly: Temporarily Letting Go of Engineering Discipline

🛠️ Leetcode Is a Different Game

These problems aren’t production-grade. They’re:

• One-off
• Highly scoped
• Often with fixed constraints
• Always under time pressure

You’re not building software. You’re producing output.

So now the goal is:

Get something correct and readable enough to submit — fast.

---

⚖️ The Engineering Tradeoff Spectrum

Instead of treating clean code vs. fast code as a binary, treat it like a dial:

Engineering Habit	Real-World Code	Leetcode Adjustment
Avoid global state	Pass + return values	Just mutate a global list
Extract helper functions	SRP, reusable units	Only extract for clarity at call site
Avoid nested logic	Break into flat flows	Tolerate some nesting for implementation speed
Use descriptive names	get_students_by_class	g() is fine for a throwaway map
Generalize structure	Parametrize it	Hardcode if it saves you time

You're not giving up on discipline — you're optimizing for urgency.

---

💡 Practical Examples

1. Mutating a Global

result = []

def process(student):
    result.append(student.id)  # instead of return + append

You could pass and return result. But… why? You’re only calling this in one place. The clock is ticking. It’s fine.

---

---

2. Debug-First, Clean-Later

debugMap = {}
for ...:
    debugMap[...].append(...)

print(debugMap)  # Looks messy — but now you trust your loop

This is scaffolding. You can clean it later — or not.

---

3. Variable Names: Clarity vs. Flexibility

# Real-world clarity
for student in students:
    for score in student.scores:
        ...

# Leetcode speed
for i in range(n):
    for j in range(m):
        ...

Is i and j better? Definitely not. But here’s the thing:

If halfway through, you realize you’re traversing columns instead of rows, at least you’re not spending 30 seconds renaming everything.

Use what lets you move quickly. If that means cryptic names you wouldn’t allow in a PR — go for it. If that means still writing student and score because that’s what makes sense to you — also valid.

There’s no purity here. Just pragmatism.

---

🧹 What You’re Practicing Is Not Just Coding — It’s Judgment

Real engineering is about:

• Understanding constraints
• Adapting to the problem space
• Managing complexity
• Delivering value with tradeoffs

So is Leetcode — just at warp speed.

Clean code is still the north star.

But here, it's okay to take a weird path to get there — or not get there at all, if the answer is due in 5 minutes.

---

🐚 Closing: It’s Not "Write Bad Code." It’s "Write Smart Code, Fast."

You’re not betraying your discipline. You’re just temporarily turning it down.

Think of it like writing in shorthand instead of calligraphy.

The key is knowing which rules you’re breaking — and doing it on purpose.

Or not.

I don’t know. I can’t say I’ve mastered this.