Make It Work (Before You Make It Fast)¶
Glossary¶
Refactor / Refactoring Rewriting or restructuring existing code to improve clarity or maintainability without changing behavior.
Clean Code Code that is easy to understand, consistent, well-organized, and readable by others on the team.
Iteration A repeated cycle of improving or refining something, where each round builds on what was learned in the previous one.
Library / Framework Collections of pre-written, reusable code or structures that help developers build software more efficiently.
Docstring A documentation string inside code that explains what a function, class, or module does.
Every developer starts somewhere between excitement and chaos. You have an idea, you write some code, and it almost works — until it doesn’t. That’s when experience begins: learning what to fix first, what to leave for later, and how to tell the difference. The order in which you solve problems matters more than it seems. Professional software engineers don’t aim for perfection from the start; they build stability first, clarity second, and speed last. Everything else follows from that rhythm.
To “make it work” does not mean to throw together junk code that somehow runs. It means reaching a point where your program reliably does what it claims to do, even if it’s not yet beautiful. Think of it like building a table: the legs must hold before you worry about polish — but they still need to be straight. If your early work is full of guesswork and shortcuts, improving it later becomes twice as hard. A working foundation is not just code that runs; it’s code that can grow.
Info
In Project Work, “make it work” means reaching the minimum viable product for each milestone. It should be stable enough that improvements don’t break it, and clear enough that teammates understand it.
YAGNI – You Aren’t Gonna Need It¶
Once something works, the next challenge is restraint. YAGNI is a reminder not to build castles for imaginary users or add knobs nobody asked for. Write what’s needed now, not what might be needed one day. The future will come with new ideas and better knowledge; let it guide your next iteration instead of cluttering your present one.
Tip
Build for what is known, not for what is guessed. Future features will come with future context.
KISS – Keep It Simple, Stupid¶
Simplicity is not laziness; it’s clarity. A simple solution invites teammates in, while a complicated one shuts them out. Most bugs hide in cleverness. Good engineers know when to stop polishing and let clean logic speak for itself.
Example
Choose the straightforward approach first. “Boring but clear” beats “clever but brittle” every time.
DRY – Don’t Repeat Yourself¶
Over time, patterns start to repeat. That’s your signal to refactor. If the same logic appears in several places, give it a single home. Reuse prevents contradictions and reduces mental load for everyone who reads your code. It’s the difference between a library and a pile of snippets.
Tip
Each important idea should live in one place only — no duplicates, no copy-paste twins.
Clean Code¶
When the system works and behaves predictably, attention naturally turns to cleanliness. Clean code is not an aesthetic luxury; it’s a professional habit. Clear names, short functions, and consistent structure make collaboration possible. Imagine a shared workshop where every tool has a label and a place — that’s what clean code feels like.
Info
In Project Work, clean code means reviewers can follow your reasoning without you explaining it out loud.
Standing on the Shoulders of Giants¶
Don’t reinvent the wheel. Using well-tested libraries, frameworks, and community wisdom is not dependency — it’s efficiency. Modern development is a relay race, not a solo sprint. Every good engineer learns to pass and receive the baton.
Example
Using pytest, pandas, or GitLab CI isn’t cheating — it’s professional reuse.
Boy Scout Rule¶
As the project matures, one quiet rule keeps it healthy: leave the code a bit better than you found it. Fix one small thing each time you open a file — add a missing docstring, rename a vague variable, remove an outdated comment. Big rewrites are rare; steady improvement is sustainable.
Tip
Treat the repository like a shared workspace. Everyone cleans up one thing per day; the project never decays.
Make It Fast¶
Finally comes performance. Speed only matters once everything else is correct and clear. Optimizing messy code is like tuning an out-of-tune guitar: you might make it louder, but not better. Measure before guessing. Real optimization starts with data, not with feelings.
Danger
Don’t chase speed at the cost of understanding. A clear, correct program can always be improved later — a tangled one cannot.
In Practice¶
These layers form a quiet rhythm that professionals follow instinctively. You start with something that runs, then make it clear, and only then make it shine. In Project Work, that rhythm keeps teams sane and systems stable. The goal is not just working software but shared confidence: knowing what to fix first and what can safely wait.
Quote
“First, make it work. Then, make it right. Finally, make it fast.” — Kent Beck