5 Things I Learned From My 5th Year of Software Engineering & 2nd Year of Writing

Coding is basically writing, but in computer languages. Lessons in one often echo in the other.

Photo by Pixabay

About 10 years ago, I started coding because it was fun.

Also, it answered my biggest question at the time: I loved writing so much, but what could I write to make a living?

Code. Duh.

Coding turned out to be the easier path to making an impact by writing – the only catch was that it’s in a different language. The more I think about it, the more I realize that software is basically a book written in computer language. Both are composed of text representing some arbitrary logic the author invented. Software users and book readers are very similar; they are the consumers of that logic. Our customers.

Bad code is like a bad story. It fails in the same way: it doesn’t translate the input into the right output or doesn’t do so efficiently.

This is great news.

It means when I improve my craft in one, I’m also indirectly improving the other. Every reflection strengthens both of my favorite skill sets.

With that in mind, I’ve decided to write a reflection post every year.

This is my attempt to jot down the lessons I’ve learned from coding and writing in 2024.

1. Figure out who you are. Not every creator is a good manager. Nor do they need to be.

There’s a myth that software engineers need to eventually grow into product managers or leaders.

“Delegate more; scale your impact,” the advice goes.

But what I slowly realized and accepted this year is that some people — including myself — love coding because we love being creators.

The more I delegate the fun parts to others and start spending my time on things I’m not excited about, the more I lose motivation. Coding feels like playing to me, and I want to keep it that way.

The other way to look at this is: No one in their right mind would ever tell Brandon Sanderson that he needs to graduate from being a successful writer and become a manager for younger writers.

That sounds absurd.

This mindset might change for me in the future, but for now, I’m clear about what keeps me engaged. I’ve even told my manager: please don’t promote me.

Let me play.

Let me stay the coding machine that solves technical problems, not human ones.

---

2. Everything is possible, but not everything is worth the effort.

It’s just code. Everything’s possible.

My tech lead said this to our PM in a planning meeting when I was an intern. I thought it was the coolest thing ever. I wanted to be that person one day.

For the first three years of my career, I did just that. I said “yes” to every task. I delivered. It worked well.

But by the fourth year, I burned out. And needed to take a month off to recover.

Like writing a novel, I can technically avoid the “boring“ thinking or planning and just start typing — because that’s where the fun is. But if what I end up writing is just another generic AI-dystopia novel, I’m only going to find out in the end, that I’ve wasted months on a story that no one wants to read, and I’m not going to be very proud of that.

The same applies to writing code.

To create impactful work, I need to spend time distilling ideas first. Planning may be sometimes boring, but it is not optional; it’s how I protect my colleagues and my energy and maximize our output.

Sam Altman said it best in his blog post “How to be successful“:

Almost everyone I’ve ever met would be well-served by spending more time thinking about what to focus on. It is much more important to work on the right thing than it is to work many hours.

---

3. Be careful about the fun part! Don’t forget about the goal.

After deciding on what to prioritize, sticking to it consistently is just as important and sometimes harder.

Because coding and writing are fun, I often find myself sidetracked into enticing side quests when I shouldn’t.

If a scene’s goal is to introduce the protagonist. Do that efficiently.

Don’t spend 3 paragraphs talking about how fancy (or unfancy) the medieval bar looks like.

Similarly, if a project’s objective is to build some AI tooling, focus on that.

Don’t worry too much about how the button looks like, yet.

Make the core functionality work extremely well, release it, and test it.

In my experience, there are often unexpected bugs (I mean, bugs are never expected) and I’ll need to fix and iterate later anyway. I will have my time to improve the button later when that does get prioritized.

Or if it never gets prioritized, it never gets prioritized.

---

4. Learn to enjoy iterations. And yes, “kill your darlings” when necessary.

Feedback is a gift. Don’t fear it.

In my software engineering career, I’ve learned to enjoy code reviews for years.

It just took me a bit longer to understand the same applies to writing.

Beta readers, critiques – these are opportunities to improve.

Sometimes, this means cutting something I’m proud of to make the whole story better. With the right people and the right community, Write of Passage helped me see this. I just need to remind myself of this.

---

5. Rest is non-negotiable.

It’s kinda like swimming; you can’t finish a long swim without breathing.

And the way to overcome that is not by training yourself to swim longer without breathing, but by finding the rhythm to breathe while swimming.

I spent most of my 2024 doing my 9-5 (sometimes -6) software engineering job, and forcing myself to still write something after dinner every day. It felt “productive“ for the first half of the year, but was no doubt the main reason for my burnout.

Plus, my best work happens when I’m rested; when my mind is clear.

Sleep, breaks, and time away from the screen are not indulgences; they’re necessities.

Preview of the next essay…

Here’s what I’m working on next::

• My takeaways from Sam Altman’s How I Write episode about writing and A.I. I love this episode too much and have re-watched it too many times.

• Some random thoughts on how NotebookLM will replace my writing; and Cursor or A.I. coding agents like Bolt.new will replace my coding job.

• My thoughts on blockchain, after playing around with smart contracts & finishing the book Read Write Own.

If these look interesting, please consider subscribing to this newsletter!

I’ll (try to) publish 2 essays every month :)