To all programmers: stand up!
This is the second post in my 30-day writing challenge.
I’m not talking about moving to a standing desk, or any of those hipster contraptions.
I’m talking about forcing yourself to stop and get up from your desk. Literally back away from it and take a break, even if you’re “in the zone”.
Let me explain:
Sometimes I get so engrossed in my work that I can code for hours on end. In the moment, I think it’s awesome. However I almost always realize later that it wasn’t so groovy. That’s because I get hyper focused on improving the local maximum, rather than the global maximum.
I don’t remember where I first heard someone apply this mathematical concept to real world scenarios, but I really like it.
In the case of programming and building a web app, it means that I may think that I’m working a lot and solving lots of problems, but I’m not solving the right problems.
While I’m working on a project, I have to make decisions. Each decision means going down a path which inevitably leads to more forks and more decisions.
After a few consecutive decisions, I often find myself down a rabbit hole and lose sight of how I got there, or of the fact that I didn’t have to be there. I forget that I had other options, and had I chosen otherwise at one of the previous forks, I could be somewhere else.
To keep myself aware of the bigger picture, I have to force myself to pause and take a break, even though I don’t want to. Pausing prevents me from going too far without poking my head out of the rabbit hole.
I had a good reminder of this lesson recently when I was building the archive page for the Hacking Revenue newsletter.
I created a custom post type for the newsletter issues and needed to do some custom queries to bring the issues to the various pages that need them. All silly Wordpress stuff, and I won’t bore you with the details, but the important point is that it took me a couple of hours to set up this whole archive with the issues, tagging, etc.
Now, I set up something similar for the Hacking UI newsletter and it worked great. But when we loaded the issues into the archives for Hacking Revenue, I realized there was a problem. The list of issues looked great on Hacking UI because they started around #111. So they were in the order you would expect: #111, then #112, then #113, all the way up to our current issue, #142.
However, Hacking Revenue opened earlier this year, and we wanted to load issues all the way back to #1. So what happens when you sort those numbers alphabetically? You get #1, #2, until #9. But #10 doesn’t come next, it goes to the top, right after #1. Alphabetically, the digits that start with a 1 come first, then the 2’s, then the 3’s and so on.
So I saw this, after several hours of coding sans break, and immediately assumed that the solution was to write some custom code and essentially reinvent the wheel. I thought about querying all of the issues, and then doing a custom sort on them, treating the issue numbers as integers instead of the Wordpress default, characters.
Luckily for me, I ran out of time for the day and was forced to stop working before I could implement this terrible solution. When I came back to this problem a few days later, I realized how silly I was.
I had forgotten that I named the issues and could have essentially named them anything that I wanted. If I just edited the name of issues #1–#9 to have a “0” at the beginning, they would sort just fine.
Only after I stepped away from the problem and pulled my head out of the rabbit hole, could I see all of the possibilities and evaluate the situation correctly.
This is the second post in my 30-day writing challenge.
I decided to commit to writing a new blog post a day, for 30 consecutive days because I believe in the “commit first, carry out later” method of getting shit done. This is a method that we’ve use repeatedly with Hacking UI to accomplish more than we ever imagined, and now teach in The Side Project Accelerator.
