The Book Itself

First off, the book was really hyped in the time before and just after it’s release. It got glowing reviews from a number of important people including Seth Godin. I didn’t really buy into the hype and decided to let things calm down a little until I bought and read it.

Being someone who regularly reads their blog and has read Getting Real I didn’t expect to get anything earth shattering. And that was exactly what happened. I could easily recognized large sections of the book that I had read before (mostly on their blog) and I feel that if I cared to look hard enough, I’d find that a lot of the book is actually on their blog in one form or another. If you’re someone who has never heard of 37signals, or don’t know about the way they do business then you’ll learn a lot from it (and may not like everything you read). But if you already know about them and read their blog your reaction will be more along the lines of “meh”.

I also found the general organization and style of the book rather disappointing. It’s set up as groups of “essays” under certain headings. The groupings are fairly accurate, but the essays seem disconnected and aloof from each other. There is no gentle introduction and no conclusion to tie things together. You feel like you’re constantly being hit with 1-2 page snippets of what you should or should not do without a larger structure to place it into. I agree with the Management Today review in that the style of writing lacks grace and charm and often seems unnecessarily confrontational. In contrast to Dale Carnegie’s How to Win Friends and Influence People, another book that changes the way you live your daily life, this book seems pretty shoddy.

I can’t help but feel that Jason and David were just out to take the best parts of their blog and put them into print rather than sit down and write a proper book. Having 200-500 word articles on a blog is fine, but when I read a book I expect some form of continuity and cohesion. In the end, my reaction to this book is probably that it’s not worth the money for the content. The ideas are powerful and I admire 37signals for doing the business the way they do, but Rework is not one of their better.

The Artwork, Look and Feel

In contrast to how unpolished the writing feels, the physical appearance and feel of the book is very different. It’s hardcover and the jacket feels and looks great with a great choice of black, red and greys for the text. The cover features a picture of a crumpled piece of picture in some kind of glossy paper. It’s obvious that someone took care to think this through.

The illustrations and section titles were done by Mike Rohde and I personally really like them. They’re not very artsy or intricate, but they have a sort of casual beauty to them. They’re simple, but well thought out, each one fitting in well with the essay it accompanies. I would actually be willing to spend money just for the artwork (maybe not a lot, but some reasonable amount). You can learn about the process and see all the pieces together as a Flickr set.

In conclusion

Rework is not a great book or 37signal’s best product by any stretch of the imagination. If it weren’t for the good design and artwork I would tell you to just of read their blog and their last book instead. But this book only if you either really like 37signals or have never heard of them and want to know what all the fuss is about. They make great software and they do good business, but the next time they want to write a book, they should really sit down and write a book instead of seeing how much of their blog they can recycle.

Writing daily: quantity over quality

I already write a fair amount, mostly in the form of blog posts and email. But I’m also prone to slacking off terribly. I’ve gone for a week at a time without writing anything substantial. Writing isn’t a day job for me, but it is something I enjoy, something I value and something I want to improve on. So I’m going to try a bit every day.

I’ve thought about doing this at various points in the past, but I’ve always agonized about the process. I would like to sit down at any computer and just write for a few minutes. But I could never decide how exactly to do it without having writing scattered all over the place. And I always knew in the back of my head that I needed to start down for an hour or so to actually write something of value.

I’ve always been a fan of quality over quantity, but for once I’m going to give it a rest. I’m going to write everyday in the hopes that the much increased throughput will produce a greater number of good works in the long run and it will also develop my writing skills (especially in terms of avoiding writer’s block and being able to switch into writing mode at the drop of a hat). When I have an extended period of time (an hour at least) I’ll write techie articles for this blog and when I have shorter snippets I’ll just dump them into documents on Google Docs.

Reading: everywhere, anytime

While I like to write, I like to read too. Unfortunately I don’t often have the time to sit down and read for a few hours at a time. On the other hand I have short bursts of time every now and then (5-10 minutes) and instead of just sitting right or looking at funny videos of cats, I want to spend that time reading. I’ve already read one book on my iPod Touch using little snippets of time here and there. Though I don’t think I’ll want to do that with all forms of literature, I can certainly do it for short pieces. I’m considering getting the Instapaper Pro app (which lets you save stuff you want to read) and offers some features like text extraction and font customization that I think will come in pretty handy.

Using both brain hemispheres

I’m going to be graduating in just over a year with two degrees: computer engineering. So yes, my left brain is going to be very well exercised. But I want my right brain to get some training too. In retrospect it might have been a good idea to pick up a studio art major, but I like what I have know.

In order to exercise my right hemisphere I’ve taken to looking at art and design. I don’t really study anything formally (though I among going to Italy over summer to study Renaissance Art) but I do observe and absorb. In particular I’ve been looking at data presentation and web design. I plan on spending some time building “blogazine“-like content on my website, probably centered about poetry and stories I’ve written before. I might even dabble in some hand-drawing (which I haven’t seriously done in years). Of course everything I do will be free for everyone to see and reuse.

Measuring my time usage

I often have days where I feel like I did a lot and didn’t really waste time, but didn’t quite accomplish much. I tried to apply the principle of “what you measure improves” by tracing all my time usage for a day. It turned out to be rather clumsy because I wanted a system where I could write things quickly and still get fairly good analytics on how I spent my time. Unfortunately paper is great for recording, but it sucks for analytics and most time tracking solutions I found were too heavy and expensive.

A few days ago I stumbled across a new webapp called Freckle which seems to hit the sweet spot between features and usability. All you do is enter a time (or use their timer bookmarklet), what project it was for and a bunch of tags and it gives you a set of fairly decent analytics. You have to pay for it and I just started a free month long trial. If I find that it actually works well, that I use it and that I’m getting more stuff done, then it’s a keeper and I’ll gladly fork over the $12 a month and wish them well.

Agile daily productivity

The agile development methodology eschews large complicated schedules and project plans in favor of smaller chunks of work, quicker feedback and review and greater flexibility. I’ve been an applying a similar system to my own daily workloads and it seems to be working, but I’ll be enforcing it better. Being a college student it makes absolutely no sense for me to have long schedules because every day brings new challenges (homework, tests, projects, random coffee drinking sessions) and any long-term plan would be shattered in a day. Instead I’m using a dual system: due dates to make sure I’m on track with my long term goals and shorter lists of daily and weekly tasks that need to be done. I’ll try to set aside large blocks of time for things like homework sets and fill in shorter blocks with reading and writing. I’m also consider doing weekly reviews but I’m not sure how much of a value that will provide to me right now.

In 30 days my free trial of Freckle will run out and that’s also when I’ll sit down, take a deep breath and see if all this actually worked or not. If it doesn’t work, I’ll try to see what it failed and see if I can fix it. Even if it didn’t work, I’m sure there will be places to tweak and improve. And though I’m tired from having written this (and from everything else I’ve done and need to) I feel pretty excited for this month.

For starters, technology, especially computer technology has permeated every aspect of our lives. And along with the computer has come the network. Within the next decade mobile broadband will become ubiquitous (at least in urban areas) meaning that we will always be connected to the full knowledge and collective intelligence of the internet. As a direct result we are all gradually becoming cyborgs: our machines, especially in the form of mobile network connected devices are becoming an inseparable part of us. Sure, we may not be jacking in with our brains as a part of the regular morning routine, but connecting to the global network of computers (and hence indirectly to everyone else using those computers) is already a routine occurrence which we don’t give a second thought.

A recent Wired article talks about how average chess players combined with the right machine assistance can beat out better human players as well as other players with better software. The key is in the human’s ability to make the most of their machine assistants: figuring out which machine results to accept, which to reject and how to ask the right questions. Our currently technology is in exactly the same position. The talent of the person using a computer or the computational power of the machine is less important than being able to combine the two properly.

Leaving chess aside, there are more practical areas where this combination of man and machine is producing great payoffs. Successful blogger and author Tim Ferriss makes no secret of the fact that he uses analytics extensively to fine-tune how his website operates and is viewed in order to maximize his earnings. In earlier days, Paul Graham created effectively the world’s first web application, Viaweb and successfully beat out better funded competitors by placing powerful tools (Common Lisp) in the hands of experienced users (himself and his team).

People my age and younger have never lived in a world when we couldn’t connect with people across the globe at the click of a mouse. All that has ever stood before us and the vast stores of information on the Internet has been a single text box with a button titled some variation of “Search”. We’re cyborgs in the sense that the use of our machines is natural and reflexive, requiring little explicit mental bandwidth. Who needs a port in the back of the skull when you have a copy of Google Hacks tucked into your brain?

Of course, not all cyborgs are made equal. Even among people my age there are both those who revel in technology and its gifts and those who would prefer to keep it at arm’s lengths. And I’m not talking about the difference between computer science graduate students and theater majors. I’m talking about the people who are content to use the Microsoft Word’s default font and paragraph spacing and those who spent hours tinkering with their websites to get things looking just right. I’m talking about the people who tweet a dozen times a day and those who log in to Facebook once a week. I’m talking about those who have three different emails and those who pull all their email into Gmail. I’m talking about… you get the point.

On the flip side there’s a careful balance between using technology to achieve a further goal (Tim Ferriss’ website tweaks) and technology for technology’s sake (the hours spent tweaking the CSS on a blog only your mum reads). The Wired article says that there is a difference between people who use technology productively and hence feel smarter and more focused and the people who seem lost and intimated by online life. I would add a third category: those who feel smarter, but really aren’t better than the baseline. Cyborgization may be becoming ubiquitous, but that doesn’t mean that it’s easy.

The growing cyborgization of our society is also the reason why I’m excited about the second coming of tablet computers: the iPad and whatever Chrome-based offering Google throws its weight behind. Take a few minutes to check out the new guided tours of the iPad and you might get a hint of what I feel. The interface is completely different from how we use computers today and I think that’s a great idea. Let’s face it: most people today don’t really need a real computer. They need basically two devices: a internet connection device and some sort of glorified typewriter/calculator for writing reports and spreadsheets. Of course the iPad doesn’t excite those of us who type hundreds of words a minute or write code for a living. That’s because we’ve already crossed the line of cyborgization: we know (or are at least trying to find out) what we can do with our machines. The iPad is for the people on the other side, those who couldn’t care less about how many cores or how much RAM they have. It’s for people who are more than willing to trade their freedom (and their wallets) for a computing experience that they can relate to better and easier. It’s for the mum who wants to snuggle up in bed with her kid and Winnie the Pooh. It’s for the people who still consider reading a newspaper in the morning a holy rite. It’s for the people who have by and large been on the outskirts of the computer technology revolutions of the last few decades. It’s for a new generation of cyborgs who stop thinking of their machines as computers and rather view them as constant, unobtrusive, electronic companions.

With some luck, my children will be growing up in a world where they are surrounded from birth by the warm embrace of the internet. For them, actually sitting down in front of a computer will be quaint and outmoded in the same way we don’t go to a landline phone to talk to someone anymore. And it will be devices like the iPad connecting remotely to powerful servers running recommendation engines and personalized search databases that will be their first connection to the world of computation. As Pranav Mistry says, people don’t really care about computation, they care about knowledge and information. We’ve been able to bring people closer to information by erasing it’s physicality and making everything available remotely. Our children will be getting that information without the burden of thinking about a browser or keyboard or URLs. For them, all sorts of data will be all around them accessible at the tap of a touchscreen (or hopefully without requiring even that).

Here’s looking forward to the Age of Cyborgs, of which we are the heralds and first citizens. We live in exciting times.

The book is the brainchild of Peter Seibel, the author of the very well written Practical Common Lisp which I can safely recommend as a good starting point for people starting to learn Lisp. Seibel’s interviewing style is very effective, the questions are always short and to the point but they help guide the person in question into providing a lot of very interesting and useful information. They are also fairly open ended allowing the interviews to flow in interesting directions, unique to each person. He asks some general questions to all 15, things such as how they learned to program, what were their hardest problems or bugs, how they go about debugging and what their idea of the current state of programming is. But he also asks them things about their particular area of work. For example, with Jamie Zawinski he talks a lot about Netscape and Mozilla while with Donald Knuth the obvious topics are his masterpiece The Art of Computer Programming and literate programming. There are also some questions that you wouldn’t always think about, such as how to spot programming talent.

What makes the book very accessible is that it keeps technical jargon to a minimum. Anyone who has programming computers for a significant amount of time will have no problem in understanding most of the content. For areas that are more esoteric the programmers themselves provide very lucid explanations making it quite easy to follow along. A lot of the matter is about things that each programmer encounters: how to read someone elses code, how to debug programs, how to collaborate and pass on projects, how to improve as a programmer, what educational/personal qualifications are most helpful, etc. The book isn’t just about how awesome these people are: it’s about understanding how masters of the craft rose to that position and how us mere mortals might follow in their footsteps. Seibel does a pretty good job of asking the same question that many of us programmers would like to ask them if we had the chance.

Beyond the structure of the interviews, the book is made amazing by the stellar choice of programmers. Not only are they master programmers, they have very diverse experiences and interests resulting in lots of very interesting and powerful opinions. I particularly enjoyed Guy Steele’s interview which contains a fair amount of philosophy regarding programming and computer science and Fran Allen’s call for computing to become more socially relevant. At the same time, Zawinski and Thompson embodied what can be best described as the classic hacker mindset: coding for the pure joy of creation and problem solving. Many of the interviews are humorous in some way or the other and none of them degenerated into holy wars or religious diatribes.

There is absolutely no reason why you should not read this book. There are some areas for improvement, but these are of a presentational nature (I wish the interviews were broken in segments so that I didn’t have to read a full one at a sitting). Content wise there is nothing I have to say. Will this book help you become a master programmer? Well, not in any tangible, measurable sense. This book is not a howto or a handbook. Each person had their own ideas of how to do things and many of them disagree with what could be called ‘industry standards’ (in particular how code should be formatted or structured). What this book will do is give a window into the minds of some of the legends of our culture. I’ve found it most useful to compare what these people have done and how they think to what I do and think myself. Essentially, read the book the same way you would read Benjamin Franklin’s autobiography. You won’t learn how to become a great statesman, inventor or Founding Father of a nation, but you can figure out some ways to live a better, more impactful life.

Coders at Work tells the stories of people who might be very well be considered heroes of our times. If you have an interest in becoming a better programmer, go buy this book, read it cover to cover, think about everything they say about their programming practices and experiences and see how you can use that to make your own experience better. And above all else, remember and act on what you read.

Beautiful Code

This is a book about code. It contains 33 chapters and in each one a master programmer walks though an elegant solution to a programming problem. The problems range from a small regular expression matcher to debuggers and MapReduce. It covers a wide variety of programming languages and approaches all focusing on the elusive goal of elegance and simplicity. It’s worth a read, but definitely requires some patience especially if you are unfamiliar with the languages and problem domains that are being talked about. It’s a fairly large book, but that’s offset by the high quality of the writing in it. Any competent programmer should be able to follow what the numerous authors are saying without much difficulty. I’m on my third chapter at the moment, and at just over one chapter a day, I should get in done in a month.

Coders at work

This is a new book which will be publicly available later this month. It’s written by Peter Seibel, the author of Practical Common Lisp (which I recommend for anyone starting Lisp). This is a series of interviews with 15 all time programming legends. Among them are names like Donald Knuth and Jamie Zawinski: people widely considered to be experts in their respective areas. I’ve preordered it from Amazon and while I eagerly await my copy there are some excerpts on the book website and a good review up on Slashdot. I’ve always been a fan of biographies and autobiographies, especially when it involves people I really look up to. This book won’t teach me how to be as good as the programmers interviewed, but it might give me some useful ideas on how to go about improving myself. This book is actually bigger than Beautiful Code by page count, but I think it will be easier reading since it should be less technical than Beautiful Code. I won’t be able to tell for certain until I actually get the book, so I’ll keep this on hand until October.

Code Complete 2

There are lots of books out on there design principles and techniques, design patterns, agile development, so on and so forth. There seem to be much fewer books on how to simply sit down and write code. This is one of them. I’ve read bits and pieces of this before and found it very helpful and insightful. Sometimes it might seem like what’s being said is fairly commonsense stuff, but it’s stuff we often tend to forget while pumping out the code. If you’re  a serious coder looking to improve your programming skills, this is a good starting point. This is a quite a large book with lots of good material so it will be a challenge to finish in the month-long-span I’ve set for it, but I’ll certainly give it my best shot. Because of the size I might need to devote more than a month to it. I plan on starting it in November and maybe continuing till finals in mid-December.

Once again, I’d like to reiterate that I don’t expect any of these books by themselves (or even all together) to magically make me a better programmer. Rather I’m going to view them as ways to learn directly from the masters of the field and use that to guide my own programming training.

Choosing a Lisp

Before I got down to actually learning Lisp, I had to make a choice as to which dialect of the language I should actually use. I’ve used a bit of Scheme before (mostly as a result of getting halfway through SICP) and though I liked it, public opinion was that Common Lisp was more suited for real world development. And since I did plan on doing real world development, Common Lisp seemed the better choice. There was also Clojure which I could have considered. I really didn’t consider it because Common Lisp was good enough and it had both excellent tools and good books. I should also mention Paul Graham’s Arc language which is currently under heavy development. Arc development is going somewhat slow (but with good reason) and if Arc was ready, I would definitely have considered it. but I really wanted something that would give me a good environment today and Common Lisp gave me what I wanted

Getting Lisp (and tools)

Languages like Python, Perl and Ruby all have a single ‘reference implementation’ and some have alternate implementations (like Jython, JRuby). Common Lisp is an ANSI standard with a number of standards-compliant implementation from various vendors. There are a number of good open source Common Lisp implementations (like GNU CLISP and Steel Bank Common Lisp) as well as proprietary ones like Allegro and LispWorks. I’ve decided to use the Steel Bank Common Lisp. It’s a branch off the older Carnegie Mellon Common Lisp. It runs on a bunch of platforms and compiles down to high performance native code. The native compiler (which I’ve heard good things about) was the main reason for choosing it, plus I think the name is cool.

If you’re serious about developing in Lisp on a Linux box (as I am), your IDE of choice is almost certainly Emacs with SLIME mode. SLIME stands for Superior Lisp Interaction Mode for Emacs and it really deserves it’s name. Not only does it provide solid editing features like highlighting and indentation, it also integrates very well with whatever Lisp runtime you’re using. It allows you to dynamically evaluate definitions and expressions and send them to a Lisp process where you can interact with your code just like you would with any modern dynamic language. SLIME also provides excellent debugging tools and they’ve already proved quite useful, even though I’ve only scratched the surface.

Finding Reading Material

The internet is a great place to find information, but when it comes to learning something seriously, I really like to have a proper book, or at least a well organized tutorial. Luckily for Common Lisp there are at least two great free books. The introductory level book is Practical Common Lisp, which I’m currently using. It’s a great book for people who already have a good idea of programming and want to learn Lisp. I like to think of it as a sort of ‘Dive into Python’ but for Lisp. I’ll put up a more thorough review once I progress a bit more.

The second book I’m going to start is On Lisp by Paul Graham. It’s for people who already have a good idea of Lisp programming and want to learn more advanced techniques. I read the first chapter (which is a rehash of basic Lisp) but it makes more sense to get used to Lisp first before I try for advanced stuff.

Practice makes perfect

Computer science has a lot of theory behind it, but when it comes to something like learning a new language or framework, the only way to get good is to practice. I’m not at the point where I can write large scale programs in Lisp yet and till then I need to practice. I’ve found a really great web page that has 99 problems to be solved in Lisp which vary in difficulty and cover a large range of the things you can do in Lisp. I’m at number 20 at the moment and trying to keep a good pace.

Future plans

I eventually want to write  some server-end software in Lisp, I’m contemplating some sort of content management system. I’d like to get a start on it before summer ends, but right now I’m more concerned about just learning the ropes. I hope to work my way through Practical Common Lisp by the end of next week and start On Lisp after that. If you guys know of any other good resources or small sized Lisp projects I could get involved in, do let me know. And I’ll have more updates on my Lisp adventures soon.

I think that the major contributing factor in the increase in how much people write is the fact that it is now so easy to get your writing out to other people. Using a keyboard, you can put down over a hundred words per minute with some practice, far more than you can write with pen and paper. Once you have something written down, you can then send that to large audiences very easily, either by private communication (email or IM) or publicly as part of a mailing list/forum or a blog or website. That’s not the end of the story. Once you have something ‘out there’, people can start writing about what you’ve written. The internet has allowed large groups of people to take part in massive conversations which in their turn generate even more text and spawn other conversations.

Given so much opportunity and incentive for writing (and publishing), there are two main questions that are worth answering: how do you actually go about writing and what is it that you actually write.

How do you write in the computer age?

With all the choices of how to get your message out into the world, you have to actually choose which one to use. Not too long ago, simple static webpages were pretty much the only way to communicate on a large scale across the net. Today, with the explosion of such things as microblogging, wikis, social networks and the such, a simple web page is probably the last option you’ll consider. I personally think that’s mostly a good thing. I’d rather be thinking about content and writing style than about HTML and CSS (though I do enjoy making the ocassional web page layout).

While some of these tools (blogs and wikis) are conducive to long-form writing, many of them aren’t, no matter how much users might try. Most of my writing is done on this blog and in the form of emails (though I have a few other projects up my sleeve). I would find it very hard to do the same sort of writing I can do here if I were restricted to (for example) Facebook’s notes. Part of the reason is that WordPress offers a more feature-righ experience, but also that a blog is designed to make content presentation the prime objective and discussion or feedback secondary (even with comments). I know some bloggers use their blogs as discussion tools as well, but I feel that a forum or mailing list offers a better environment for that than a blog post.

You could apply the same argument to wikis as well. Wikipedia in particular makes discussion a background process. But some wikis such as the very useful EmacsWiki and the originial wiki at c2 make discussion an important part of the wiki. However, both of them still have strong seed articles and the discussions provide supplementary information and allow disagreements to be placed on record.

Even when it comes to private communication, there are choices. You have email of course, as well as instant messaging. But you also the have various social networks and forums each with their ad-hoc email-like messaging system (and maybe basic chat). A private Twitter account or blog can also be used to let people close to you know about things in your life if you’re not comfortable with laying bare to the world. I’m personally just an email guy, but with multiple accounts to keep things separate. I also use IM, but only for close friends.

While it’s certainly great to have all these cool toys to play with (many of which are generally helpful), an equally important question is what do I write and who gets to read it?

What do you write in the computer age?

This answer depends a lot on what sort of person you are. How much of your life and thoughts do you want to share? I’m personally comfortable with sharing a lot of my life. I have this blog and I Twitter. I do it because I want people to know who I am and I’d like there to be a public record of my thoughts, ideas and transformations over time for people in the future who might be interested (and might learn something). Many people don’t think the same way as I do, and that’s fine. I agree completely with Steve Yegge regarding the reasons you should blog, though I think any other medium is fine.

That being said, I certainly don’t write about everything I think about. If I did, I wouldn’t have time to do anything else. I have a few criteria for what I spend my time on. I put in writing what I think would be most interesting for other people to read. I also use writing as a thinking tool and so I write about whatever problem I’m facing to see if I can write my way to a solution. I don’t write much about my personal life because I think it’s not very interesting to most people and I’d get bored writing about it. Once again, other people probably have different criteria and reasons and that’s fine too, as long as you’ve given the issue serious thought. Above all, you should make sure that you write what you want to. Stephen King’s advice has been helpful for me: “you must not come lightly to blank page”.

While you should absolutely place yourself first when thinking about what to write, you should also give some thought to who’s going to read what you’ve written. Thanks to the internet, the chances of other people seeing what you’ve written have greatly increased, especially if they’re looking for it. Computers may be more secure than a paper diary, but for a determined enough seeker, no electronic hurdle is too much. Public encryption technology is pretty good quality, but its not bulletproof. On a less sinister note, there are chances that you yourself might accidentally send out something that you don’t want others to read (remember those great jokes about hitting the “reply-to-all” button). What if you’re afraid that you might accidentally put out something that will cause you great distress later? I found the answer a few weeks ago while reading Ender’s Shadow (which is a really good book that you should read). It goes something like this:

He would never, never commit his real thoughts to a readable form. He keeps his own counsel. Always. You will never find a document written by him that is not meant to be read.

Sister Carlotta, about Bean

Pretty simple, huh? Don’t put in writing something you wouldn’t want people to read. This doesn’t just hold for embarassing stuff, it’s also for stuff that you may think is ‘copyrighted’ or something along those lines. Unless you want people to actually read your stuff, don’t write it. Its ok to want to make money off you’re writing, but understand that not everyone who reads your stuff will pay and it’s best that you accept that and not let it stop you. Newspapers are having real trouble getting to grips with this fact about the computer age, but you can be smarter than that.

In conclusion

Writing in this age is different because computer technology has made distribution very easy. This basic fact is what you have to keep in mind while writing or thinking about writing. Publishing has never been easier, but that puts the onus on you as the writer to decide carefully what you want to publish and make the most of the wonders of computer technology.

Before I jump in, it’s worth taking some time to clarify what exactly intermediate is. For starters, I’m assuming that you know at least 3-4 different programming languages including at least one object-oriented, one functional and one utility language (eg Perl/Python/Ruby). I’m also assuming that you’ve worked in teams and have successfully accomplished at least one medium scale programming project which involved both program design and implementation. And since computer science is more than just programming, you should have at least a cursory knowledge of computing theory and algorithms, meaning that you know, at the least, what a Turing Machine is and what Big-O notation means. That being said, let’s get on with it:

Structure and Implementation of Computer Programs

Yes, I know MIT uses this book for its intro-level programming course, but it quite clearly states in one of the prefaces that most students taking that course already have some programming experience. It’s certainly a fine book, but I do think that novice programmers won’t quite understand the full power of some of the concepts presented. However, having spent some time in the trenches, you’re likely to have a better understand of what sort of things can make your life easier. This book will teach you a lot about abstractions and algorithms and once you’ve experienced the austere simplicity and inherent power of Scheme, you’ll never think the same way again.

On Lisp

Even though the book is supposed to about “Advanced Techniques for Common Lisp”, the first few chapters are devoted to a rather basic review of functional programming concepts. I’m currently working my way through this book and I think it’s fair game for anyone who has had exposure to functional programming in general and some dialect of Lisp in particular. Be warned however, that this book is quite topic specific. It makes no secret of the fact that many of the ideas that are explored will be useless, or at least very hard to implement without the powerful framework that Lisp gives you. Unless you plan on actually using Lisp for a substantial amount of your work in the future, this book might not be worth the time investment.

Design Patterns

At the other end of the generality spectrum is this classic. It’s authors have gained somewhat legendary status in the software engineering community as the Gang of Four and the book very well deserves its reputation as a must-read for serious software engineers. If you’re bulding production software and use any form of object orientation, you’ll soon be encountering some of the patterns described here. The books purpose is to describe general patterns that continually occur in software. It reads more like a catalog or cookbook than a standard textbook, but that adds to its appeal. Each pattern can be studied more or else separately and references to supporting patterns are made clear. There is also a considerable amount of sample code in Smalltalk and C++. This isn’t exactly a book that’s made to be read cover to cover and you’re likely to get bored unless you have a problem in mind that you’re looking to solve. The best way to get the most out of this book is to treat is as a reference and another tool in your toolkit.

Code Complete 2

Another general software engineering book that will make you a better programmer for the rest of your days. Code Complete is hard to describe in a few words and the best way to get a feel for what it is to read the first few chapters. Code Complete focusses on the actual writing of code. It deals with issues that arise was you and your team sit down to actually implement the design. If you have any experience at all working with a team on a large project, you’ll understand a lot of the issues that are dealt with here. This book isn’t about fancy optimizations or agile team management techniques, its about actually sitting down and writing your code. A must-read for anyone who wants to build better software (which I hope, is everyone who has ever written software).

Compilers: Principles, Techniques and Tools

You may only have a passing interest in compilers and may not be looking to become an expert in programming languages, but learning about compiler technology will help you in numerous other ways as well. A word of warning, this book is a classic but it also edges into the ‘advanced’ domain. I’ve started reading this book in earnest since I became interested in programming languages and I still have a long way to go. This book will force you to develop along multiple fronts: algorithms, data structure, even interface design (by way of designing usable languages). And as Steve Yegge pointed out, starting to write a compiler is not for the faint of heart, because there is no end to it (though that’s something for another post). Read this book only if you are seriously committed to someday becoming an expert programmer.

The Mythical Man Month

It’s a bit dated and a lot of the examples might seem archaic, but the underlying message is clear even after all these years. This book is must read if you’re ever in a position to lead a team ( and chances are, at some point you will be). If there is any book that I would say is a must for a software engineering curriculum, this is it. It can be tempting to skip over the more technical parts, but please don’t do so. Read this book cover to cover and then read it again a few weeks later.

The books I’ve listed above won’t make you an expert programmer, but they will start you on the way and take you a fair distance along. The truth is that it’s much harder to go from intermediate to expert than to go from beginner to intermediate (though I suppose that’s true of all disciplines). I’m looking for a good book on algorithms to add to the above list, but I haven’t come across one that is at the proper level yet. I consider Knuth’s masterpiece to be at a somewhat higher level than what I’m prepared for at the moment. Any suggestions would be welcome.

Google Scrubbing

Google is quickly becoming the world’s homepage. If anyone who doesn’t know you wants to look for you, then chances are the first thing they will do is type your name into Google’s search box. So the question is, what are they going to see? Hopefully you’ve been smart enough not to leak your personal life onto the internet. But even if everything that a Google search reveals are things you wouldn’t mind people seeing, they might be very random and chances are they won’t give the full picture about you. So it’s up to you to make sure that Google does present the real you. How do you go about it? Well, that’s what the next section is about

Get a domain name

Domain names can be had for under $10 a year and there are lots of free hosting options. Having a domain name lets you carve out a part of the Internet and brand it with your own signature style. Trying to get a meaningful domain name that you can keep around for a long time and which you won’t mind telling lots of other people about.

Once you have a domain name, put it to use by building a good website around it. Put up normal things like a resume, but also put up PDFs of articles or papers you’ve written and link to your other work online. If you write blogs (one or many) consider turning them into subdomains of your website. This way there is a central location for your work on the web. Unless of course, you specifically want your blogging life to remain separate.

Consolidate your email

Another great reason to get a domain name is so that you can have email addresses attached to it. Having an email address attached to a domain name means that you don’t have to change it whenever you change jobs or schools and it looks more professional than a free email address. I would recommend having multiple email addresses for each domainL one for business, one for friends and family, one for mailing lists, one for free subscriptions etc. This way if you start getting spammed you can find out where it’s coming from and take measures.

Of course having a separate inbox for each email address would be very unproductive. I strongly recommend using the free Google Apps for your Domain and then using the Gmail app to alias multiple addresses to the same inbox. Then you set up filters to appropriately label, hide or delete emails sent to the various emails. Look at the first chapter of Upgrade Your Life for more useful email tricks.

Get your nicknames under control

Chances are you have multiple nicknames for different forums, IRC and IM. It might be a good idea to stick to a uniform set of nicknames so that people can find you. However, depending on whether or not you want to actually want to be known or if the nicknames are available, this might not be an option.

If you have any advice on how to get your online life under control, please drop me a note in the comments.

Though our field is still one of the youngest in the world (probably only genetics and nanotechnology is younger), there has been an incredible amount of knowledge generated in the last 60 years or so. We’ve come a long way and solved an awful lot of complicated problems along the way. All the collective knowledge of our field is locked into three primary sources:

1. Thousands of articles, books and other publications
2. Billions (maybe trillions of lines) of powerful computer code.
3. A growing number of blogs, wikis and other easily accessible electronic forms, most of which are free.

Of course it is humanly impossible to read all of it. Okay, maybe it is possible, but then you’d never get around to doing any programming. The good news is that reading even a very small fraction of the total mass of computer science literature out there will give you a far better idea of what’s been done and what’s going on.

No matter what part of computer science you’re in, there are bound to be a few classics that are required reading for everyone in that area. These might be in the form of books or research papers (especially if you’re into theoretical aspects). Though these might be somewhat more difficult than the daily problems you are used to solving, there are probably only a handful of them, so it’s not going to take forever to get through them. And it will probably be worth your time to go through them with some rigor. Reading the classics and founding works of your area will give you a fresh perspective of your work and offer a valuable insight into the minds of the early pioneers.

Now that you’ve started you might as well keep going and read something more modern. A lot of the things that were significant problems 60 years ago aren’t problems anymore and it might come in handy to know what the solutions are. There are modern books of course, but in this case the Internet might prove a better source. You can always start from Wikipedia to get a general idea and then work from there. Being in such a dynamic field, it’s important for us to keep abreast of current happenings and developments. Enter the blog. Sure, many blogs are of questionable quality and there’s a very high noise content. But that being said, there are still a number of authoritative voices and it shouldn’t be very hard for you to find ones pertinent to your interests.

Blogs are important not just as news sources, but also because often they link to or mention sources of information that would otherwise have passed under your radar. Blog comments are often a vibrant (and sometimes vitriolic) medium of discussion, and you might often be led to question your own assumptions on the topic.

Finally there is reading code. Reading other people’s code is not always an easy thing to do. After all it does represent someone else’s thought patterns which might be very different from our own. It’s even harder if the code is badly written. However reading code is important, both good and bad code. If you don’t know what bad code is, you won’t be able to tell when you’re writing it. Luckily with the rise of open source, there’s a profusion of code out there. Again the same warnings apply: there’s a lot of crap out there and you have to be a bit careful as to what exactly you’re looking at. However, just as with blogs, there should be some well known source you can safely trust.

Since I started actively reading a few months, I’ve seen that I’ve become better at recognizing certain classes of problems and thinking of innovative solutions. I’ve also come to know of very interesting parts of our field which I would never have known of in a class setting. I’m still rather deficient when it comes to reading code, but that will be something I will work on over the rest of the year.