10,000 hours of programming

I’ve always been interested in improving my programming ability, not just my ability to write code, but also my ability to think clearly about problems and then map that thinking to efficient, working code. After all, if you’re spending more time writing code than you are thinking, you’re probably doing something wrong. Lately I’ve come across articles about how top performers like Tiger Woods, Bill Gates and Mozart put in large amounts of time and effort in their fields before they became top experts. The two most useful articles I’ve come across are Why Talent is Overrated and Outliers: The Story Of Success. There are also books from the same authors available for what I think are really low prices on Amazon. While I strongly recommend reading the articles (and maybe buying the books) the core message is really simple: to become an expert in your field of work, you have to put in roughly 10,000 hours of concentrated effort.

What is effort?

Before I go any further, let’s get clear about just what that 10,000 hours amounts to. It doesn’t mean doing repetitive grunt work and it doesn’t mean doing your work while you’re watching TV. Firstly, all of the 10,000 hours has to be devoted to actually working. You should be working with full focus on a particular task and nothing else at that time. Secondly, you have to work smart as well as hard. You need to understand what you are doing, what mistakes you are making, how they affect your performance and how you can improve. In short, you need accurate, constructive feedback and criticism. Along the same lines, it is also essential to be working towards a specific goal and making sure you are setting clearly defined milestones (as opposed to vague “I need to get better” goals).

Just as important is that your work be geared towards continual improvement. Specifically, you need to be working on problems that are just beyond your comfort level. This is a tricky balance to maintain. If the problems are too easy, you won’t learn anything new and if they’re too hard, you risk just sitting around and just getting frustrated.

Applying to programming

Programming taught in schools and universities around the world is mostly taught as if it were just another science or a form of engineering. However, unlike most other pure sciences, computer science involves a much larger element of practice. Thanks to modern technology you don’t have to wait around for your experiments to finish, you get instant feedback on whether or not your code works. This means that programming can (with some modifications) be treated similarly to performance arts like music or sport: to be a good programmer, you need to be continually practicing writing code as well maintaining a wide repertoire of techniques you can bring into play when the need arises. So let’s see how we can apply the 10,000 hour concept in order to become a better programmer.

1. Write code, a lot of it.

It’s hard to improve at programming if you’re not doing any. So pull out your compiler, dust off the text editor and get to work. The 10,000 hour mark means that you’ll be writing a lot of code. It’s important to realize that if you really want to become a top notch programmer, it’s a lot of work. If you set yourself a 5-year time limit (say all of college and then another year), you’re going looking at 6 hours a day of writing code. It’s not an easy choice, but depending on what you want to achieve, it might be worth it. For me personally, I would say that I’ve clocked about 500 hours in the past year or two, which isn’t a lot, but it’s a start. I may have done a bit more, but I wouldn’t really call all of it focused effort.

2. Make sure you’re always learning.

Just because we’re setting a number here doesn’t mean that’s the most important thing to keep in mind. You won’t be learning much if you spend 6 hours a day writing ‘Hello, World!’ in a bunch of different languages (except perhaps a cursory knowledge of I/O and program structure in the languages you’re dealing with). The best musicians and athletes out there have a variety of skills and talents they can pull out at a moment’s notice. Think about Tiger Woods and all the different places a golf ball may end up. It is essential that over the course of your work you expose yourself to a lot of different ideas.

One good way to do this is to learn new programming languages, I’d say pick up a new language every few months. There are a number of languages that you absolutely must know. C (and maybe D) for systems and down-to-the-metal programming. Smalltalk for object oriented programming. Lisp and Scheme for functional and syntactic abstractions. ML or one of its derivatives like Haskell to understand type systems well. Prolog for logic programming. A good general purpose language like Python, Perl or Ruby for day-to-day tasks and C++ and Java for all the huge amount of code out there that’s written in those languages. The list might seem daunting, but once you get started it can be interesting and quite enlightening. My programming languages course this semester has added significantly to my toolkit and in the future I plan to look into web programming, databases and concurrent systems.

3. Read other people’s code and find a mentor.

Athletes and musicians have a definite in advantage in that there are trained coaches and a large body of work regarding how to develop and train top athletes. Unfortunately computer science and most of its sub-topics are yet to develop such a body of work. We have to substitute coaches with professors and teachers and the massive body of well-written code that is already out there. Reading other people’s code is a good way to pick up new ideas and techniques, in much the same way that athletes study past games. At the same time, you’re going to have a hard time improving yourself if you don’t have a clear idea of what you’re doing wrong. It’s hard to have an honest unbiased opinion of your own work, so it’s good to have someone you can give you a honest assessment of the quality of your work and tell you if you’ve gotten any better. This is the part where your teachers and senior colleagues can help you out. If there is no one you know who can fill this role, then there’s always the Internet available to look for like-minded individuals.

4. Find interesting problems.

Let’s not kid ourselves: going through this process of continual self-improvement is going to be hard. For most programmers I know, doing hard work for the sake of working hard is not their top priority. Part of the classic hacker mindset is that we prefer to work on problems that are fun over anything else. Luckily for there us there are lots of problems out there that can help us channel our efforts while at the same time giving us tons of enjoyment in the process. Contests like TopCoder and Project Euler are a good source of practice problems and if you prefer doing something real world, there are tons of open source projects out there that could use your help. Thanks to initiatives like Google Summer of Code, you can even get paid for what you’re doing. So if you ever find yourself being pulled down by the sheer immensity of the task ahead of you, find something that genuinely interests you and start pumping out the code.

5. Set goals and keep track.

To be able to continually improve yourself, you need to set yourself goals and then plot straight courses towards them. Though it’s easy to set a broad goal like “become a better programmer”, such a goal tells you nothing about how to actually get there. Much more helpful are short term goals that target specific abilities. For the past few months my goal has been to understand more about the abstractions provided by different programming languages. For the first quarter of next year, I’m going to be focusing on algorithms and memory management techniques. Set a specific goal and then lay out an outline of subgoals that will bring you closer and closer to your goal. Most importantly, make sure you actually meet those goals: specifically, produce working code that involves the areas you’ve tried to improve in.

It won’t be easy…

but that also means that most other people won’t be making the commitment. For me, it’s slightly easier being a student: I don’t have to worry about holding down a job or feeding my kids. I can also structure my courseloads to require programming intensive courses; next semester I’m taking Software Engineering and a Theory of Computation course as well as computer organization and a Digital Circuits course. I’m just over 20 years old right now, and keeping the 10,000 hour mark means that I could become a top notch programmer by the time I’m 25, i.e. about halfway through graduate school. That’s still a few years late, but better late than never. 6 hours a day for the next five years is a hard commitment and I can’t say that I’ve ever done anything quite like it. But considering that I really can’t see myself doing any other kind of work (except perhaps writing) it’s a commitment and investment I’m willing to make. I had better go and get started.

Discovering Dreamweaver

Over the past few weeks, I’ve been doing a considerable amount of webdesign work. First off, there is my personal website, which I’m trying to make more serious and comprehensive. Besides that I’ve also been working to redesign my college Computer Science Department’s website. I have a part time job with the Foreign Language Resource Center at college and they’re launching a new program to give students an ePortfolio where they can store and show information regarding their course work and other language experience at college. Originally the plan was to have some art students design a set of templates, but I was rather appalled by the low quality of their work (and the extremely long time they took to create it) so I decided to just make my own.

For my personal site and the CS department’s site I was using a Emacs with the html-helper mode and manually managing things like links and so on. Though it was very nice to have hotkeys wired to inserting specific tags, some things (like making site-wide changes or changing the structure) were simply too time consuming. I’ve known that Adobe Dreamweaver is pretty much the current gold standard for website design, but I was rather reluctant to use it because I’m not a big fan of WYSIWYG editors. However, the lady in charge of the Foreign Language Resource Center had made it quite clear that no matter how good my template was, she couldn’t use unless she had a Dreamweaver Template file for it and could be edited from Dreamweaver.

I really didn’t need to actually make a new template, because the ePortfolio project would have gone on without me. However, it’s times like this that the hacker inside simply won’t take no for an answer. So I decided to just sit down and learn just about enough Dreamweaver to get the job done.

However, after using Dreamweaver for a few hours and creating a full skeleton of a portfolio in record time, I’ve decided that there is no going back for me. First things first, Dreamweaver fully unites WYSIWYG editing and roll-your-own code editing. I wouldn’t have used it if editing code was difficult or impossible. The instant preview is very handy to show just what is going on without needing to fire up a browser. More importantly the preview lets you see exactly how your code maps to elements on screen, something which is very handy if you are trying to nail down a tricky layout.

I’m still not a fan of using the WYSIWYG mode to build the layout, because I like having an intimate knowledge of what exactly my code is doing. At the same time, I’ve realized that a WYSIWYG mode does come in very handy once the layout is set and all that remains is to put down the content. Auto insertion of tags is nice, but not having to look at tags at all when you’re making your content is even better. That being said, I’ve seen that Dreamweaver has a tendency to insert and prompt for element attributes that I would rather set using CSS. This is a mild bother, but is acceptable in view of other productivity boosts that you get.

Templates and automatic link management are two other features that I’ve come to love. Templates alone are a massive productivity boost, especially since you can set distinct editable and non-editable areas. This lets you define exactly what parts of your pages stay constant across sites and what can change. The larger your site gets, the more important this becomes. On the same note automatic link management is an equally useful feature. Most than once have I found myself rearranging my pages and having to manually go about changing links. I haven’t had a chance to properly utilize this feature, but I intend to do so in the future.

Coming up ahead

I’ve decided that I will be using Dreamweaver as my tool of choice for future web design work. Things I would like to play around in the immediate future would be multiple templates for a site, as well as testing out the site management tools. I’m also going to be migrating my exciting sites to Dreamweaver and will look to see if I can actually develop them faster in Dreamweaver. I know I’ve only scratched the surface of what Dreamweaver can do, but I think it’s going to be a fun experience learning more.

Why you should blog

I was checking out the list of referrers to this blog and one of the top referrers was another blog called Red Sprouts that had linked to my post on Coder’s Block. One of the other links on that page was to another blog where the blogger had posted on why he wouldn’t be shutting down his blog. That got me thinking about why ordinary people like you and me, especially student should write blogs. Here are some of the reasons I could come up with:

1. Everyone has a story to tell

No matter how uneventful you might think your life is, there are bound to be some things that are interesting. In fact, you probably won’t even find out what the interesting things are until you sit down and start to actually write about them. Most of us spend our lives just going with the flow without really thinking about what is interesting and what we really want to do. Telling your story is a great way to learn more about yourself. Athletes and musicians don’t get good at what they do just by practicing blindly, they get extensive feedback and then apply that feedback into their training routines. Similarly blogging will make you look at your life and realize what’s good and what’s bad. With that information at hand, you can start working to improving your life story.

2. Organize your thought and ideas

Teaching someone is a great way to test and improve your own knowledge and familiarity with the topic. I think that blogging serves a similar purpose. Much of my blog posts consist of technology related topics and I’ve found that I have to do a decent amount work to make sure that what I write is technically correct and makes sense to someone who doesn’t have an intimate knowledge of the topic. Looking for links and references is especially useful and I’ve made quite a few useful discoveries along the way.

3. You do a lot of writing anyway

Chances are that you’re already writing a lot already. Most of the time it might be mundane things like emails, memos or reports to your superiors. Buried under all that text there’s probably a lot of information that might be useful to someone out there. If you have enough time to sit and down and putting something in written, you have enough time to take it and put it in a blog post. Especially if you’re a college student, you do many pages of writing a semester. And the good thing is, all your writing is already edited for an audience so it requires even less effort to put it out on the net. In fact, I think it’s time college build blogging and online publishing into part of everyday course work.

4. You won’t know until you try

A lot of people I’ve talked to about bloging say that they don’t blog because they aren’t good writers or that they don’t have interesting or useful things to say. I find it hard to believe these people. How do they know that they can’t write a blog if they’ve tried writing one? Like most other things in life you won’t know how good a blogger you are until you actually try it out. Luckily for you, the barrier to entry is extremely low. Free is the average price you pay for having a blog on the net today, which means there’s one less reason for you not to write a blog. Perhaps your blog won’t land you in a book deal or even be very popular, but that’s ok. In fact that is another reason why you should blog.

5. No one will read your blog

Sounds irrational doesn’t it? Why write a blog if no one is going to read it? Well if this was any other medium like books or magazine, I would agree that no readers is a bad thing. But for blogs, I don’t think that’s the case at all. Blogs are the most personal mass communication medium ever designed. Unless you’re an official blog for a company your blogging more for yourself than you are for anyone else. And it’s a great thing that no one else reads what you write. College papers come with the burden of the teacher having to read it and decide your grade based upon it. A lot of people who tell you that they hate writing actually hate people tell them about their writing rather than the act itself. Blogging frees you from having to write to please a professor (or and editor or publisher or some other superior as the case may be). Your blog is your space. You pour out your heart and soul and experiment with your writing in all sorts of interesting, amazing ways. Think about the best class you ever took and just imagine how much better it would be if you could take that class and do everything you did without having to worry about your grade. And guess what, if you do write something that is really good and a lot people enjoy it, the popularity will come without much work on your part.

Of course, this is a problem if you’re in it for the big time. But then again, if you want a reason to blog to make money or become famous, this is not the right ‘why’ post to be reading.

6. You might just become rich/famous/controversial

I guess I need to mention this as a converse of the above. Sure there are extremely popular bloggers out there and a lot of them make a lot of money at it. But I can’t tell you how to get there. Starting a blog for the purpose of making an income from it is a good idea, but it’s a lot harder than if you’re just doing it for the reasons outlined above. It’s going to take work and time and you probably shouldn’t quit your day job while you’re building it up. However, if this is something that you are committed to doing, then there are many sources of inspiration and a lot of great information out there about how to go about it. Good luck, and let me know when you make it.

If you have an interesting reason for writing a blog, or if this post inspires you to write your own, let me know about and I’ll give you a llnk and read your blog (or not if you don’t want me to).

Using Latex for college papers

A few months ago I posted about how I was tired of Microsoft Word and was looking for an alternative. I had decided on Latex as a substitute because it was a plain-text format that easily translated to PDF. It also has great tools including Mactex for OS X and the Auctex package for Emacs. This semester in college has been the most writing intensive so far. I have an Engineering Professionalism and Ethics course that has regular memos, reading summaries and four longer papers (and planning sheets for most of the above). My digital circuits course also requires regular lab memos. I’m glad to say that I’ve been using Latex full time for all my writing.

During the past few months using Latex full-time, I’ve learned a few lessons which might be useful for anyone starting to use it for full time writing. Here’s a quick guide to get you on your feet with Latex for daily college life.

1. Get Latex.

First order of business: head over to the Latex website and find yourself a package that you like. If you’re on a Mac I highly recommend the Mactex distribution. It’s somewhat heavy, but certainly worth it as it will have you all set to get going. For Linux, it’s best to find a package for your distribution, but if you’re an Emacs user, the Auctex package will come in handy.

2. Find a good tutorial

I’ll admit, Latex can be a bit overwhelming for beginners. So it’s important to find a good tutorial. The official documentation page is a good starting point. I also found Getting to Grips with Latex to be a very good jump start guide. Once you start feeling comfortable, be sure to use Google to find tips and tricks to achieve what you want. With its long history, chances are someone has solved the problem you are facing. On the same note, you probably want to just learn as you go along instead of reading one of the tutorials chapter by chapter.

3. Build some templates

Latex can be a bit of a pain for quick documents, but it can become very effective once you start using it for larger projects. If you’re writing a lot of memos or a number of papers with the same general format, it would be best to spend some time and create a Latex format that you’re comfortable with. I’m currently using two such templates: One for memos which is set up with To:/From: fields and all the usual trappings of a memo, and another for longer papers set up with proper spacing, title page, table of contents, bibliographies, the works. Making these templates might take some work, especially if you need custom packages like I do, but believe me, they’re worth the trouble later.

4. Keep focused on the content

Coming from the WYSIWYG world of Word, it’s very tempting to continually typeset your work to see what it looks like. Here’s a suggestion: don’t. Latex is designed to handle the looks for you so that you can focus on content. Take advantage of the fact that you don’t have to worry about how your paper looks and what it says at the same time. I find it helpful to do at least two passes on my paper. One is where I just write, without seeing what it looks like. I focus 100% on content. I care about nothing besides getting my point across. I don’t even bother about page limits at this point. Once I’ve put down everything that I need saying, I start pruning. I do a typeset to check basic things like length and to make sure that I don’t have huge solid blocks of text. I’ll then start shortening (or lengthening) to get to the limit and then alter paragraph and section boundaries to make sure that the text flows properly. However, none of this done at the cost of the quality of my writing.

5. Look over the result

One of the consequences of using a system like Latex instead of Word is that it harder to edit on the fly. So make sure that the result (probably in PDF form) is what you want it to be, (typos, formatting errors etc). I generally go through everything two to three times to make sure that everything is how it should be.

Like many powerful tools, Latex will take you some time to get used to. But once you get used to the powerful and clean efficiency that it offers, you won’t want to go back to WYSIWYG again.

Switch-case statement in Python

This post is part of the Powerful Python series where I talk about features of the Python language that make the programmer’s job easier. The Powerful Python page contains links to more articles as well as a list of future articles.

In the months since this was written, I have received a number of comments and learned more about programming languages in general. I put some of the new things I learned into a revised post on the topic which you might be interested in.

A switch-case statement is a useful programming language that lets you control the flow of the program based on the value of a variable or expression. In particular, if the variable or expression that you’re testing has a number of different of possible values, you could execute a block of code for each separate value. Here’s a simple example in C (courtesy of Wikipedia):

switch(n) {
  case 0:
    printf("You typed zero.\n");
  case 1:
  case 9:
    printf("n is a perfect square\n");
  case 2:
    printf("n is an even number\n");
  case 3:
  case 5:
  case 7:
    printf("n is a prime number\n");
  case 4:
    printf("n is a perfect square\n");
  case 6:
  case 8:
    printf("n is an even number\n");
    printf("Only single-digit numbers are allowed\n");

Based on the value of the variable n, a different message will show up on the standard output. The default case is executed when the value of the variable doesn’t match anything for which a case is defined. Notice that some cases have a break statement while others don’t. If a particular case block is executed and no break is found, then all the following case blocks will be executed until a break is found.

The switch-case statement comes in handy when you’re writing a language parser like I am now. For simple languages, like most programming languages, each token in a sample of the language can be followed only by a very limited number of possible tokens. My putting the options of possible following tokens in a switch case statement, you have an easy mechanism for performing different tasks based on what token is actually found. For example, if it’s a variable name, you check if its been declared before, if it’s an operator, perform the corresponding operation etc.

Unfortunately, my language of choice for the time being is Python, which doesn’t come with a typical switch-case statement. One simple substitute is using a string of if-else blocks, with each if condition being what would have been a matching case. Here is part of the above code in Python using if-else blocks.

if n == 0:
    print "You typed zero.\n"
elif n== 1 or n == 9 or n == 4:
    print "n is a perfect square\n"
elif n == 2:
    print "n is an even number\n"
elif  n== 3 or n == 5 or n == 7:
    print "n is a prime number\n"

It certainly works and should be pretty easy to work, but it’s not a very elegant solution. Especially if you have more than a handful of cases, you’re going to have a very long string if-else cases. Since each of the if conditions must actually be checked, you might run into performance issues if this is a vital part of your code.

The Pythonic solution is to make use of Python’s powerful dictionaries. Also known as associative arrays in some languages, Python’s dictionaries allow a simple one-to-one matching of a key and a value. When used as part of a switch case statement, the keys are what would normally trigger the case blocks. The interesting part is that the values in the dictionaries refer to functions that contain the code that would normally be inside the case blocks. Here’s the above code rewritten as a dictionary and functions:

options = {0 : zero,
                1 : sqr,
                4 : sqr,
                9 : sqr,
                2 : even,
                3 : prime,
                5 : prime,
                7 : prime,

def zero():
    print "You typed zero.\n"

def sqr():
    print "n is a perfect square\n"

def even():
    print "n is an even number\n"

def prime():
    print "n is a prime number\n"

Now that you have the switch case setup, you can actually use it by simply doing a dictionary lookup:


Thanks to the fact that Python functions are first class values, you can use the functions as the values of the dictionary and then call them via dictionary lookup.

The advantage of this method is that it is generally cleaner than a long line of if-elses and someone reading your code can simply ignore the functions they are not interested in. Performance-wise, the Python dictionary lookup will almost certainly be more efficient than any solution you can rig yourself (with perhaps the exception of custom C code, but if you can do that, why are you reading this?). However, except a penalty associated with calling and coming back from a function. In fact, it’s the function call that is both the strength and the weakness of this method. While it lets you cleanly segment your code, you also have a bunch of functions lying around. This isn’t a problem if you were going to use functions anyways, but they can be a mess if you have a lot of tiny ones lying around. If your functions sufficiently small, consider inlining them in the dictionary as lambda expressions.

As a final note, the above example doesn’t provide a default case in case nothing matches. You can make up for this by having the actual lookup be inside an if-else block, with the condition checking for the presence of the key in the dictionary (using the ‘<keyname> in <dictionary>’ idiom). But a more Pythonic way is to wrap it in a try/except block. If the option isn’t presence, a KeyError Exception will be raised which can then be caught and the default code executed. Be sure to check the Wikipedia entry and this blog post for more information.