RC Week 7: Four habits to improve as a programmer

Friday, November 4, 2022

Seven weeks down, five weeks to go! It's flying by quickly. On the one hand, I want it to last forever. On the other hand, I know it can't, and I'm looking forward to talking to coworkers again at my day job when I go back. RC has given me a renewed appreciation for what I get at my job. More on that in December, though.

For now: RC, and the goals I have while I'm here. Instead of focusing on what I did this week, I'm going to use this post to talk about how I want to improve as a programmer.

I came into RC in with certain hard skills I wanted to improve (debugging! profiling! optimization!) and those are all great, and I have worked on them. But I am starting to focus more on the meta level of how do I actually improve broadly as a programmer? What habits do I have that make me less effective? What habits do I have that make me more effective?

One of my bad habits is jumping into writing code without doing sufficient analysis. This might surprise some of my coworkers, since I'm the design doc person at work. I love writing design docs. But what I don't do as great a job of is doing analysis when I'm midstream on something.

Last week, I wrote a parser. When I was working on it, I ran into some significant memory consumption issues. I was pairing with another recurser, Manuel, and I started to just kind poke around at different ideas to bring down memory consumption. Instead, he pushed us to take a few minutes to actually calculate what a lower bound is on the memory which would be used. This informed our approach for reducing its usage and figuring out where high usage was coming from, and ultimately was a lot more effective a lot more quickly.

So that's the first habit I want to build: Using estimation to inform how I work on things. It sounds simple, and it's hard for me to break out of the flow of coding to do it. But I've already started to put it in practice this week, which is promising!

The second bad habit I have is not reading the docs. This one is pretty self-explanatory. I want to read the docs more when I start using a new library. But I also want to read the docs for standard library things that I don't use often so that I know they're there when I need them. I might need to make some Anki cards to study the standard library or something!

And that's the second habit I want to build: Proactively read/study documentation.

But what habits do I have that make me a better programmer, that I'm already doing?

The main one is writing. I believe I'm at least a halfway-decent writer1. The thing that I do that makes me more effective is writing design docs.

For the first half of RC, I didn't do this, and I'm not sure why. I've started writing design docs for IsabellaDB and it's been so helpful in clarifying my thoughts and giving me discrete steps that are more approachable. My designs are not correct on the first pass, but that's also kind of the point! After this database is working, I'll have a record of the design iterations, which I think will be a kind of neat example of how a skilled software engineer goes through design iterations, especially in an area they're not highly familiar with.

So that's the third habit, which I want to reinforce: Write design docs proactively and often.

I've also fallen out of the habit of using my favorite and most effective programming tool: Walking or running. Something about walking or running helps me work through problems that have been nagging me. The work I'm most proud of in my life has all been catalyzed by walks or runs. I don't solve the entire thing, but I typically will get the kernel of a solution that I need in order to chip away at it. I used to go for walks proactively during the day to think, and I've fallen out of that habit.

So that's the fourth habit, which I'm going to rebuild: Go for walks during the day.

These habits are what are effective for me. I'm going to keep at it. I'd be eager to hear from any of you: What habits have you found make you a more effective programmer? And are there any you think would help me that I'm missing?


1

Software engineers are often also not good writers, so this may play to my advantage. I don't know how we as a profession compare to the broader population, though. I'd be curious to learn if there's any work done comparing the writing abilities of different professions!


If you have comments, questions, or feedback, please email my public inbox. To get new posts, please use my RSS feed.