Knowing the concepts is necessary but not sufficient. This article covers the patterns that show up in real projects and the anti-patterns that bite teams who skip fundamentals.
Patterns that scale
- Start with the boring, mature tool. Reach for advanced features only when you need them.
- Automate the steps you repeat — CI/CD, scripts, one-off runbooks.
- Instrument early — you cannot improve what you cannot measure.
- Make the common case fast and the uncommon case possible.
Anti-patterns to avoid
- Mutating a dict during iteration — Iterate over list(dict) or use a copy: for k in list(d):
- Using == instead of is for None/True/False — Use `is`/`is not` for singletons — faster and idiomatic.
- Catching bare `except:` — Always specify an exception class: except ValueError:
- Importing * in production code — Use explicit imports for readability and to avoid namespace pollution.
- Not releasing resources — Use `with open(...) as f:` or context managers — never raw try/finally leaks.
What senior engineers do differently
They write code that fails loudly and predictably. They prefer boring solutions over clever ones. They instrument first, optimise second. And they document the why, not just the what.
Summary
Pick one anti-pattern from the list above that you have actually done. That is the one to fix first.