4 Things I Wish I'd Done Earlier As a Coder

If you do something long enough, you'll inevitably wish you'd done things differently when you started.

I've been coding daily for over nine years now. Plenty of time to make a few mistakes and learn from them (I hope). If I could go back in time to the beginning of my programming career, there are a few things that I'd do differently.

Here are four of them.

Stop Treating Code as Sacred

Untouchable code isn't a code smell; it's a wretch-inducing code stink bomb.

I had a job maintaining a tangled mess of PHP. Execution paths that I'd swear were unused would break things if they were removed. Every change had unexpected effects. The codebase was full of "sacred code" — code that had to be left alone because no one understood it.

It gave me a sense of impending doom.

I just knew that one day I'd encounter a bug in the sacred part of the codebase, and the entire application would come crashing down.

It never did — at least, not while I was there. But the unwillingness to tamper with certain parts of the code meant that patches had to be hyper-localized. The codebase blossomed in size, which made it harder to maintain. I left that code in worse shape than I found it.

I wish I'd never treated that code as sacred.

Master a Code Editor

If you spend all day in a code editor, take time to investigate and practice helpful shortcuts.

For a few years, coding was a secondary activity for me. I used it as a tool for research in graduate school and wrote automation scripts and user interfaces at my first job. In both cases, I spent less than ~20% of my time coding. I never got all that proficient with a code editor.

At my second job, though, I spent all day looking at VS Code in a cubicle.

I was intolerably slow navigating the editor.

Little by little, I picked up tips and tricks. Then I started intentionally practicing shortcuts. Although I haven't truly mastered VS Code, the difference is massive. I waste so much less time and energy on editor-specific tasks and can focus more on the actual work.

I wish I'd started mastering my editor earlier.

Learn Unrelated Languages

If you've learned one language, pick an unrelated one to learn next.

In college, I used C, C++, and Java. In grad school, I used MATLAB and Python. I've used Lua, PHP, JavaScript, Python, and Julia for work. Of course, each of those languages has its differences. But they're all imperative. From that perspective, they're more similar than different.

Until recently, I'd only ever used one declarative language: SQL.

I never wrote any complex SQL queries, though.

Lately, I've been learning a declarative language called Rel for my current role at RelationalAI. Writing code that doesn't express control flow took some getting used to. But learning Rel has changed how I think about and write code no matter which language I use. In particular, it's given me a new appreciation for functional programming.

I wish I'd learned a declarative language sooner.

Read Other People's Code

Every now and then, read someone else's code… like you read a novel.

All coders working on a team of two or more people read someone else's code at some point. But even if you read other people's code every day at work, I'd guess it's probably in the context of fixing bugs or adding features. There's always a task behind the scenes, and often a deadline.

That's not the kind of reading I'm talking about.

I'm talking about the kind of reading Donald Knuth told Peter Seibel in Coders At Work he did after he broke his arm in a bicycle accident:

I had a month where I couldn't do much, so I read source code that I had heard had some clever ideas in it that hadn't been documented.

— Donald Knuth

I've been reading Peter Norvig's Pytudes, although probably not at the same level of depth that Knuth read whatever code he was reading. Still, it's a worthwhile exercise. It's exposed me to new ways of thinking about solving problems with code.

I wish I'd started reading other people's code earlier.

What To Read Next

The most important thing any coder can do is cultivate a deep sense of curiosity, but it isn't always easy. Learn some of the tips and tricks I use to flex my curiosity muscles:

How To Stay Curious as a Coder

Curiosity is not an immutable trait. You can learn how to be more curious.

davidamos.devDavid Amos

Dig Deeper

Learn how fifteen of the all-time great programmers practice their craft in Peter Seibel's book of interviews Coders At Work*.

* Affiliate link. See my affiliate disclosure for more information.