Things I've Learned About Keeping Code From Breaking
I have spent more years fixing other people's code than I care to admit, and somewhere along the way I accumulated a set of personal habits that keep my work from turning into a full-on disaster. People call these things Quick Coding Hacks, and they are mostly just small friction-reducing choices that compound over time. Let me start with something concrete rather than abstract advice. A few years back I inherited a Python project that ran CSV transformations through pandas. The original developer had written a loop that read every row, checked a condition, modified the row, and wrote it back to a new file. The input file was approximately 140MB and the script took about 47 minutes to finish. I replaced the entire thing with a single vectorized operation using boolean indexing. The old code looked something like this:
for idx, row in df.iterrows(): The replacement was one line:
if row['status'] == 'active' and row['value'] > threshold:
df.loc[idx, 'adjusted'] = row['value'] * 1.15df.loc[(df['status'] == 'active') & (df['value'] > threshold), 'adjusted'] = df['value'] * 1.15
Runtime dropped to roughly 8 seconds. The logic is identical. The lesson here is not about cleverness. It is about understanding what the tools you already have are capable of before reaching for manual iteration. Another one that comes up constantly involves shell scripting. I once spent three days debugging a deployment script that failed intermittently on production servers. The issue was that the script used date to generate filenames, but the server running the deploy job was in a different timezone than the source system logging errors. The fix was adding export TZ=UTC at the top of the script. It took me two hours to find because I was looking at the logic, not the environment. Never assume your execution context matches your expectations. Version control habits matter more than people admit. I keep a rule that every commit message must answer three questions: what changed, why it changed, and what problem it solved. Not all three every time, but at least two. This is not about being thorough for its own sake. When you come back to a piece of code six months later and try to remember why you wrapped a function in a retry loop, a decent commit message will save you twenty minutes of reading surrounding diffs.
Get the Full Details
Here is a less obvious one. Stop writing functions longer than thirty lines unless you have a very specific reason. I know this sounds like a rule from a bootcamp textbook, but there is a practical cause behind it. Functions that exceed that length almost always do two or three things at once. When they do three things, debugging requires understanding the interaction between all three. When they do one thing, you can isolate failures quickly. I have a TypeScript utility library where I had a 180-line function that handled validation, transformation, and database insertion. I split it into four smaller functions last month. The test coverage went from 34% to 91% because each function became independently testable. Environment management deserves its own mention. I use direnv now instead of manually editing .env files or relying on nvm and pyenv alone. direnv lets you define environment variables per directory and automatically loads or unloads them as you move between project folders. Before I switched, I was constantly working with the wrong Python version or missing an API key because I forgot to source a file in a new terminal tab. The mental overhead of tracking which environment was active in which directory was real. direnv removed it. For testing, I recommend a simple principle: test behavior, not implementation. A lot of developers write tests that verify the exact path their code takes through a function. If they refactor that function, the tests break even though the output is correct. Test the input-output relationship instead. Give the function the same input, verify the same output, regardless of how the code gets there internally. This makes your tests resilient to refactoring and keeps them meaningful.
Error handling is another area where people consistently waste time. Instead of catching broad exceptions with empty except blocks in Python or generic error handlers in JavaScript, catch the specific exception you expect and log the rest. A pattern I use in production code looks like this: try: The last
result = await fetch_data(url)
except ConnectionError:
logger.warning(f"Connection failed for {url}, retrying in 5s")
await asyncio.sleep(5)
except Exception:
logger.error(f"Unexpected error: {traceback.format_exc()}")
raiseraise is important. Silently swallowing unexpected exceptions makes debugging nightmares. I have seen production incidents where a database connection timeout was being caught by a bare except Exception block and logged to a file that nobody checked. The system appeared to work because the code kept running with stale data instead of failing loudly.
Documentation does not need to be exhaustive. A README with setup instructions and a brief note about the project's purpose is enough for most internal tools. What matters more is inline comments that explain why something is done a certain way, not what is being done. The code shows what. A comment explaining why a particular timeout value exists or why a workaround is necessary is worth far more than a summary of the obvious. One more thing about code review that is not widely discussed. Reading code is harder than writing it. If you submit a pull request with fifty changes across ten files, the reviewer will likely skim it rather than catch every issue. Break large PRs into smaller, focused units of change. Each PR should do one thing. This speeds up review time, reduces the chance of bugs slipping through, and makes rollback simpler if something breaks in production. The reality of coding is that most of your time is spent reading, debugging, and maintaining existing work rather than writing new code from scratch. Anything that makes those activities easier is worth adopting, even if it seems minor in isolation. The habits above have saved me an estimated several hundred hours across five years of work, and none of them require special tools or advanced knowledge. They just require paying attention to what actually slows you down.
