10 Rules for a Productive Programmer

I just read The Productive Programmer by Neal Ford, and this is my takeaway:

10 Rules for a Productive Programmer.

Rule 1: Never do things your computer can do faster than you

This applies to finding files, launching applications.

Rule 2: Those who forget history are condemned to repeat.

Command history (Ctrl+R in bash), clipboard (in your editors), web history, macros.

Rule 3: Turn off needless notifications

Email/ does not need to be checked every 5 minutes.

Rule 4: Computers are for automation, use them.

If you notice yourself repeating some steps, automate!

Rule 5: Test

Testing makes you less fearful of changing things. It ensures that things always work. And it allows you to benchmark

Rule 6: YAGNI

(There’s no explanation here ‘cos YAGNI!)

Rule 7: Occam’s Razor

When given multiple explanations for something, the simplest is the most likely.

Rule 8: Law of Demeter

For any object or method, the only methods that should be invoked are:
– The methods of the object itself,
– parameters of the method
– any objects created within the method.

Rule 9: Question authority

The idea here is not revolting, but rather seeking explanations, for current processes and practices.

Rule 10: Use the perfect tool

The perfect tool is the one you know best, so find one that satisfy your requirements, use it, learn it inside out and master it.


Space Apps Challenge 2013

I participated in the NASA-backed Space Apps Challenge (Singapore) last week, here some some reflections.

The first thing about this challenge (and practically any other hackathon) is that there is very little time. Some events discourage planning before coming down, but Space Apps specifically asked the participants to decide their project early and do some preliminary reading. Which I didn’t. ‘Cos I was busy with school and stuff. Also, I went down as an individual. So the lack of prior communication meant that we spent a good hour talking about how we are going to do things. Nonetheless, I enjoyed meeting new people, making friends, it was a fun experience. Also, despite having decided on a challenge to work on prior to the event, I was unable to form a team due to a lack of interest in the topic I chose. On hindsight, I think that I would have been able to convince people if I had some some prior research or produced a mock-up. This would show my commitment.

The challenge was not a overnight hackathon. Staying over was not mentioned, and I conveniently went home. I felt that this had some negative impacts on the final product: less time to hack, inertia the next day, context switching… In short, hackathons should really be all-nighters, that’s what makes them fun, and challenging, and unhealthy. Buy hey, it’s only once in a while right? 😉

I loved the challenges that were suggested. They were very interesting and open ended, hence we could do whatever we want. Throughout the challenge, my team had to do quite a bit of research, and I think in the end, we got more out of the challenge than what we gave to it. Shameful in a way, but brilliant.

My team won the Big Vision award, for our implementation of a website that talks about NASA’s impact on the economy, as well as effect on humanity. Our website also has a little “crowdfunding” side to it, where we allow the public to indicate interest in NASA projects, so that NASA has leverage to request for more funds.

Overall, I had a great experience: two eye-opening talks during the event, many new friends, more knowledge about NASA. I’m looking forward to next year’s Space Apps Challenge, and next time I will be more prepared.