Revisited: Thinking versus doing

I've talked about this before. But Knowing, doing and learning puts it better.

I liked this:

...we really don’t know something until we use it. Understanding that we can’t really separate knowing from doing explains why people who love to code are so much better at it than those who don’t: they try stuff out.

And this:

The cycle of learning is to learn a little, then use what you’ve learned, then learn some more.

Reinforces what I said, while being more articulate.

Rails for fun

After months doing other projects at work, I've been "drafted" for some Java this week. Specifically, I'm making a middleware servlet. Since I knew I was going to do the Java-thing again, I bought Head First Servlets and JSP. Like the others books in this series, it's really really good. Yes, I have mentioned this series twice before, but rest assured that I am not getting any money from this. People who know me know that I have trouble not mentioning the things I love.

Java is still not great, but it's not as bad as I remembered it to be. And maybe it's the machines we have at work, but it feels insanely fast. INSANELY fast. But I digress.

I've been programming in Rails for about a year now. I have 4 fully-functional personal webapps to my count. I also have forkmapit.com that I coded part of. However, much of the credit goes to my friend Daniel.

I eat my own dog food. All the applications I developed, I use on a daily basis. I coded my applications to solve actual problems that I was having. Application development, however, is an iterative process. You release something and your users tell you how close (or far) you are from what they thought they would get. I am my own customer, and I am pretty demanding. When you're forced to use your own application, you soon discover the annoyances and the many ways you could make it better. Tonight, I hit the mental threshold where I decide to fix bugs, streamline and improve.

After a week of Java, going back to Rails is a much needed break. I code in Rails for fun. Like myself, a lot of people using Rails have normal 9-to-5 jobs where they code in whatever technology will ensure a regular paycheck. In many ways, Rails is double-edges sword. It's a pleasure to work with ... but a curse to those who have to "go back" to, say, Java for work. I mentioned to coworkers that going back to Java after having used Ruby felt like having your hands tied behind your back and trying to program by typing with your nose...

The application I was working on, I call "tvguide". With "tvguide", I keep track of the episodes for the TV shows I watch. It was a plain application with a little bit of AJAX to update the numbers in a table.

It was a glorified spreadsheet.

No more... I implemented photo upload to the application, thumbnails for my listings, I completely changed (and improved!) the presentation, I took out pre-RJS DIY AJAX. Best of all, I have a much better application now, with more features and LESS code.

I want the tools I use to empower me. Rails and Ruby are such tools. As for "fun", I would say it's a side effect of using good tools.

Ruthless Automation

How many people truly use computers to automate repetitive daily tasks? Even if they do, to what extent are they automating these tasks?

I've always been a fan of automating boring and/or repetitive stuff out of my way, but I never conciously made an effort to automate all I could automate. That was until I read Saving Time and Pragmatic Project Automation.

I can think of 4 reasons for automating your tasks:

1. It forces you to really "understand" a task. What am I exactly doing here? Is there a better way? Is this robust?


2. It documents a task. Not just a series of steps in your head anymore. The script is the intent, the all encompassing series of steps you need to do combined with the things you need to "touch" to accomplish your tasks.


3. It saves times. This one is obvious and is the most often presented reason. I would dare say that taking 10 minutes to automate something that would have taken 5 minutes is still worth it. Read on.


4. It hones your skills. Makes you practice your soft-scripting skills

In light of #4, you can now see automation as an end rather than a means.

Daily automation will expose you to a lot of small problems. "How would I get the third column from that file?" "How would I insert a line after a match in a file?" "How many lines are in that file?" "How many times is the word 'tomato' in that file?" Note here that everything is a file in UNIX, so these examples are more general than they appear.

The more you automate, the better a programmer you become. The better a programmer you are, the easier it is to automate. You can also consider better understanding, better process documentation and time-saving as welcomed side-effects.