I started a new job recently and my on-boarding mentor told me I was bringing lots of value to pull request reviews despite being the new guy. This caused me to pause and reflect on how I approach code reviews, what I might be doing differently from others, why I do it and where my habits came from.
Perhaps the best way to describe my approach is that I think of code reviews as an asynchronous pair coding session:
In 2009 I got my first smartphone, and since then it’s played an essential role in organizing and scheduling my life. Surely your experience is similar. Given that I rely on it so much, I often worry about the apps, tools and websites I’ve chosen. They might be shut down for one reason or another. My data might be leaked during a security breach, or transferred to another company during a merger.
What I would like people to do if they’re professional programmers is think about how you can use your skills not just for business. How can you change the world in ways which aren’t necessarily directly correlated to making money? Because, are all the good things in the world directly correlated to money? I don’t think they are. [We] should be thinking about how we can use our amazing, fabulous skills that we all have, that most people don’t yet have, to change the world for the good that we see.
Refactoring – Not on the backlog is a great read, and advises you to improve your code with every feature request you complete, instead of making it worse. The key is to refactor iteratively as you work.
We took this “gradual refactoring” approach at DeviantArt and I highly recommend it. You also get the side-effect of maintaining developer morale since large, long-lived codebases are often soul-crushing things to maintain.
So please, stop plowing through your tickets.
If your web application calls out to third-party APIs, set aside some time to review the timeouts surrounding those requests.
Carefully choose a timeout for the initial connection attempt. Choose a low timeout and perhaps add a retry if you really need the call to go through. Carefully choose a timeout for the overall request. How long are you willing to make your users wait for the response? Do not rely on the default timeouts set by your HTTP client library, language runtime, or HTTP server.
My podcast rotation has expanded a bit lately. Here are the ones I’ve found particularly enjoyable:
A gaming podcast featuring 3 ladies and only 1 guy. They discuss games and pay particular attention to:
Did the game creators lazily fall back on stereotypes or create a well-rounded, believable characters with history, motivations, feelings? Are we forced to play as a male lead? Extra points off if we have to rescue a damsel in distress.
A recent scroll through my blog posts got me thinking about the personal projects I’ve worked on in recent years. Last month I built my own wifi router over a three week period. It was invigorating. Similarly hardware-related, I came across a three-year-old blog post from when I built my current desktop PC. It still meets my needs quite nicely so I’ve no need to upgrade, which is a nice feeling.
Great video. Blows my mind that string concatenation + eval is faster than object/hash creation + repeated modification.
Now I see why. I’ve run an experiment here.
Don’t trust your assumptions about yourself, and don’t apply them to others. They’re probably wrong.
– calinet6 on the Hacker News post, A (Short) Rant About Working Remotely