Productivity Tip #2

I recently realized that I'm actually two very different people. I'm one person at night, and another when the alarm clock goes off. My night-self, let us call him Mr. Gogo, is tired, but his brain is functioning pretty well. My night self makes all kinds of plans for the next day. And then, my morning-self, Mr. Gozen, screws everything up. So, my second productivity tip is:

Tip #2 - Kill Mr. Gozen

I don't mean to promote violence or anything, it's just that Gozen is an asshole. He has only one thing on his mind - going back to sleep. That just plain sucks. I want to do things, and he ruins everything. So I've decided to terminate him.

For the past week, my alarm clock has been going off at the ungodly hour of 5:58 am. I get up and start looking for the damn clock, usually thinking of nothing else but going back to sleep. By the time I find it, I'm pretty much awake, and Gozen is dying. You see, much like the Wicked Witch of the West (WWW) melts in water, my morning self melts in wakefulness. And I must say that life is much better without him.

Every morning, I do the dishes while I finish waking up, ignoring the last feeble screams of Gozen, then stretch and exercise, drink something warm, and head off to the computer to work for an hour on one of my hobby projects (I promise to reveal what they are soon). Then I wake the wife with a kiss, and on I go to work. It's great.

Now, most of you are probably worried that getting up in the morning will be bad because you'll lose sleep. Well, nothing can be further from the truth. While I do sleep less, I don't lose any sleep. If the left hand side of the equation is waking up early, than the right hand side must be to go to sleep early. Well, no, No, NO! That's were the beauty of this whole habit is - my evening self has some ability for cognitive action. And when he gets tired, he says - off to sleep, because being tired after a long day means that that's what you need to do. On the other hand, being tired after 6-8 hours of sleep means you are not thinking properly, Gozen has taken control.

The beauty of the system is that everything balances up. If you don't get enough sleep, you'll go to sleep earlier. But you will never oversleep anymore - you'll get exactly the amount of sleep that your body needs.

I find I'm more productive in the morning, even though I work pretty well at 2-3 am as well. It's just that I have plenty of peace and quite to do what I want.

Why Not to Write Shell Scripts

Don't write shell script. Not in bash, and not in any other shell. There are two very simple reasons for this:

1. They are not portable.
2. They are hard to read.

Nowadays, we have a much better option - write those same shell-scripts in a cross-platform scripting language, such as Python or Perl. These languages are much easier to read than some devilish combination of awk, sed and a cryptic syntax. Well, Python is. But Perl can be readable too, contrary to common wisdom, if a bit of care is taken when writing the script. Sure, most shell scripts use some really neat tricks & hacks, but let me quote Brian Kernighan:

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

Brian Kernighan

(If you follow the link, you'd see Mr. Kernighan has a hand or two in the scripting pot himself. Oh well...)

In my experience, even the most temporary script ends up expanding beyond its original intention, and thus needs to be modified and maintained. Shell scripts are just not the right tools anymore.


Further Reading

1. Python, Subprocess and Multiple Arguments
2. Programming with VI
   

Productivity Tip #1

I lead a pretty busy life. Besides working full-time, I'm taking a very intensive university course in Japanese, I try to blog weekly, exercise, read lots of books, work on hobby programming projects, do the dishes, spend quality time with my wife each and every day, go hiking every month and occasionally have some semblance of a social life. It's not much, and I won't give up any of these things, at least until we get a dishwasher. I do, however, need to better utilize my time so that I can get more things done.

This post will hopefully kick off a series on what I learn as I try and be more productive, or, more precisely, more efficient. I don't intend for it to be anything like those "self help" blogs, I actually kind of hate those. I want these posts to be about concrete, down-to-earth tips that I find useful. So, without further ado:

Tip #1 - Listen to Podcasts

Most people know this already. For a programmer, I'm pretty caveman like in my knowledge of the latest technological hype. I'm usually several years late when in comes to the latest thing. But although I've known about podcasts for months, I could never find the time to listen to them.

This where this tip gets productivity related. Podcasts are great for doing something useful in those "dead" moments we have each day. Most people listen to podcasts on their way to work. For me, however, it takes less than 5 minutes to drive to work each morning, so it's not really an option. The solution is obvious, although it took me ages to find it out - I listen to podcasts in the gym.

I think exercising regularly is very important, but that will have to wait for its own blog post. Listening to podcasts while exercises has been really great for me, and I can finally catch up on all those StackOverflow podcasts.

Programming Editors

I've used a wide range of programming editors throughout my life. From the glorious copy con and QBasic of the DOS days, through the Turbo C of my teenage years, including the emacs of my college days and the Source Insight and Eclipse of my professional career, one thing is clear:

I was a terrible IDE user

This means that I rarely used, or even knew of, more than 5% of the features of each IDE - excluding (maybe) the glorious copy con editor, of course. I can still remember the shock at watching someone else debug code by using a debugger (!!!). Turns out there was one right inside Turbo C all along.

And then came along The Pragmatic Programmer, which is a phenomenal book. One of the things they recommend is to choose a text editor and learn how to use it. Learn how to use it real well. Which is why, I think, having a learning curve that's a bit steep is a good thing.

In college, after the first year the emacs police got off of our backs, and we could use eclipse. Many people did just that. I didn't - I had been forced to endure emacs for too long, and had to pay too many hours to learn the likes of "Ctrl+X 2", that I just didn't want to learn how to do it all over again (I still don't know how to do it in eclipse). This was, of course, a stupid idea. But to rationalize why everyone had red squiggly lines below their errors as they typed and I didn't, I had to learn emacs just bit more in depth. Or at least spend hours talking to the emacs psychiatrist, which eclipse doesn't have. Take that eclipse!

The problem was that I never really liked emacs. It can do horrible thing to your keyboard's CTRL key. And I never liked it's MS-Word philosophy of putting together one huge application (or OS) instead of many small programs which can be bundled together as you see fit. And getting a decent copy outside of unix-land is always an annoyance, even on my Mac, which is a citizen of unix-land, kind-of. I still hate programs that are several mega-bytes overweight. That's why I'm switching to vi.

So far, I really, really like vi. The whole normal mode is great for touch-typing - no more reaching out for the arrow keys (or the CTRL key). It's a nice programming editor, though I still have a lot to learn. My main IDE is still Eclipse, and although its C++ support is sketchy, it will probably take a while before I'm proficient enough in vi to give eclipse up completely.

Above all, I still miss Source Insight, now that I'm on a linux machine. It's probably the best editor for a large code base. It's one of the most ugly editors, but when most of the code is already written, it can't be beat. But now I mostly write new code, so it's not too bad. I'm good with vi.

But I still don't know how you say Ctrl+X 2 in vi...

edit: it's ":split filename"

Source Code Highlighting - In Blogger!

There are a great many posts on how to post syntax highlighted code in blogger. I can't really understand why google doesn't have a ready made solution in place.

I think I've found a solution I'm comfortable with:

1. Convert the code to html (":TOhtml" in vi)
   
2. In the Compose tab, type: <pre> </pre>
   
3. Paste you code between the tags
   
4. Publish

That's it - no installation, not too much hassle.

For extra credit, you can modify the css for <pre> sections.

If you want line numbers:

1. ":set nu" - show line numbers in vi
   
2. ":TOhtml" - convert to html
   
3. ":set nonu" - remove line numbers for easy copy & paste (or, use Ctrl-V)

1  #include <stdio.h>
2
3  int main( int argc, char *argv[] ) {
4      printf("Hello World!\n");
5      return 0;
6  }

All that's left is to find a good color scheme for vi.

edit: Ars Pythonica has added that in your .vimrc file, you can add: "let html_use_css = 1" to include css in the output.

Thanks to:

1. Eli Bendersky - for the pre trick
2. FluidBlog - For the vi TOHtml trick