This article contains affiliate links. See my affiliate disclosure for more information.
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.
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 do you wish you'd done earlier in your career?
Read what professional coders say as they reflect on how they learned to program and how they practice their craft in Peter Seibel's book of interviews Coders At Work.
Artwork © @zdeneksasek via Canva.com