6 Snippets of Advice


A few weeks ago, K. Anders Ericsson of deliberate practice fame released a new book (which I haven’t yet read) called Peak: Secrets from the New Science of Expertise. The main challenge with reading these types of popular science/psychology books is taking action. They are written to be enjoyed, but there’s nothing forcing you to make any life changes once you finish the last page.

One way to avoid the passive reader trap is to maintain an idea list. Advice books are packed with words and stories, but are usually built around a few core ideas. Many of these ideas come up repeatedly in different books and articles. So as you come across them in your reading, maintain a master list of ideas that seem useful. The purpose of this list is to serve as a reminder of practices that you find effective. Try them out one at a time, and adjust as necessary to fit your work style.

Items on this list should be more actionable than guiding philosophies like “You don’t have to live your life the way others expect.” But they shouldn’t be too specific, or your list will get unwieldy. This isn’t the place for tiny life hacks about secret Gmail features. The goal is to make a list that will remind you to follow principles that you have found to be effective.

With that in mind, here’s my list:

« Continue »

Coding Style for Competitive Programming (UVa 10567)


When you’re solving competitive programming problems, it’s tempting to code as fast as possible. Once you have some idea about what the problem is asking for, just start coding and hack away until your solution passes. After all, these problems are written for timed contests, so why not solve them as if you’re racing the clock?

At some point in your competitive programming career, the “full speed ahead” approach might be the right one. If you want to do well in contests, you have to practice under contest-like conditions. But it may be a while before that’s the optimal practice strategy.

The problem with coding quickly is that you’ll end up with messy code that’s hard to debug. There’s nothing morally wrong with writing messy code that you’re going to throw away in an hour. If you’re getting correct solutions quickly, go for it. But if you’re spending a lot of time debugging code that’s incomprehensible a minute after you write it, maybe it would be more efficient to slow down.

Now, I’m not saying you should go to the other extreme and polish your code as if you were going to turn it into a product. Even if you have a lot of practice time, there’s a limit to how much learning benefit you can get out of one contest problem. Save your best coding style for code that you’re going to keep around.

« Continue »

Recursion: See Recursion

Recursive Books

[T]here are two things traditionally taught in universities as a part of a computer science curriculum which many people just never really fully comprehend: pointers and recursion. — Joel Spolsky

Let’s try to comprehend the basics of recursion using an example that comes up frequently in programming puzzles: generating all permutations of a set.

« Continue »

Wish List for a Time Tracker App


Software developers spend a lot of time in front of computers, obviously. It’s also a modern truism that a networked computer is both a productivity enhancer and the greatest time waster humanity has ever invented. The same devices that we use to make a living are also perfect for delivering endless cat videos.

But we can’t just stop using our computer and go back to the abacus. Even turning off the network is problematic, now that Stack Overflow is the de facto source of documentation for anything useful. (Turning off email while you work is recommended though).

So what’s the solution? One thing about computers, especially those that run desktop operating systems, is that they’re designed to be customized. So let’s try to solve a problem that technology has created (Internet distraction) by applying a technological solution: a time tracking app, customized for self-tracking developers.

« Continue »