Protos' Musings

"In the long run men hit only what they aim at" — Thoreau

How to be a better programmer – the redux

with 6 comments

"Software development productivity would skyrocket if the least effective 30% were fired tomorrow" — Neal Ford


It was in the December of 2005 that I first wrote about how to be a better programmer. At that time I was into my fifth year as a programmer, and though I wanted to write what I am writing today, I decided to narrow down my scope to non-technical issues. I wrote about code readability and code maintainability that day. As important as these issues were (are), I guess there is a larger issue that must be addressed — the technical skill set of the programmers. Then I wrote about (nay, linked to) the fatherly advice to new programmers by Chuck Jazdzewski.

I am now into my eighth year as a programmer, and unfortunately, the rate at which the industry has understood the importance of the quality of code or for that matter about issues like code readability or code maintainability is pretty dismal. This might be justified by arguments like "in service industry, deadline is more important". But people just don’t understand that in the rush to push the software out of the door, the quality of the code suffers, which directly affects how quickly you can ship the second or later versions. To make matters worse, people who can really understand the code at a deep level, and who are really interested in programming, is a minority, and I guess it would remain that way for the foreseeable future.

The triggering point for writing that piece three years ago was a mail from my counterpart in UK, who wanted the team to ensure that they are putting comments properly, and (though he didn’t explicitly mention the words, he provided an example that pointed to writing) comment at the level of intent. I am not sure how many people read that post (considering that I find it difficult to tell people that I blog; except to my close friends and family), but at least from that day, I made it a point to tell my team members the importance of writing code the proper way, and when required, show them how it is done. The triggering point for writing this has been yet another series of events. I thought it was time I write this down, so that a) I can refer back when I want to, and, b) pass this on to anyone to whom I feel like preaching in the future :).

The first and the most important aspect to become a better programmer is to have something called interest or involvement. Half the crowd I meet are programming just for the sake of doing some work. Programming, unfortunately, is not similar to doing most other jobs where you learn and master something once, and you can carry on without learning anything new for quite some time, and in some cases, for years altogether (or for life). Careers that spring to my mind include Government Service, Accountancy, Banking, Teaching, and certain professions like certain streams of Engineering and Law. Of course, in each of these cases, there is something new to learn every year (or every few years), but compared to the frequency at which things change, and the effort involved to keep ahead of the curve, they do appear trivial and manageable. [I know this is going to be a controversial perspective, but being a Mechanical Engineer and being someone who has a passion for teaching, and who dreamt about doing M.Tech and becoming a professor, I hope I know what I am talking about here]. Anyways, I don’t mean any kind of disrespect to any of the professions. I am just pointing out the fact that you don’t have to explicitly sit down and read a few books on your subject to remain good in many a profession out there.

In programming, what you know today is of little or no use two years down the line. I remember reading way back in 2002 about an interesting incident narrated by David Chappell in his book, Understanding Dotnet, First Edition. Chappell was taking a session on DCOM (if I remember right) at Moscow, when someone in the crowd got up and asked him why is that Microsoft is changing the technology every few years, and how he is finding it difficult to cope up with that. Chappell told him, as a matter of fact, that if he finds the change difficult to cope with, he is perhaps in the wrong profession. I wish we could make more programmers understand this simple fact – the fact that in this profession one can’t stop learning. In fact the number of programmers who have read any of the top 25 books on programming or software would be less than 10%. This might be an example of the Sturgeon’s Law (that 90% of people will never care and 10% of people would cover up for them in most professions).

To make matters interesting the IT industry doesn’t quite teach them that programming is important, and I live in a society, where if I tell them I am programming in the eighth year of my career, people think I am a (lowly) programmer still, perhaps because I don’t have what it takes to be a manager or a team leader who mostly takes care of team management related activities. The trend is to learn programming at the level of writing if..else, for..do and yes, playing around a bit with something called objects (without really understanding what they actually are and what they are meant to be), and do programming for four or five years, all the while remaining at that basic level, never bothering to go out of the way to improve oneself, and jump on the management related bandwagon at the first possible instance.

This is where some of the most successful companies around the world stand out, and it is not a coincidence that most of them are run by people who were great programmers, and who still love and do programming. The best example would be Google and I can never forget the beauty of this story and what it tells you about the company (or the story of how Sergey Brin wrote an application to test Android, and the application was about using the accelerometer in the device to determine the time an Android phone was in the air when it is tossed up; the point is there are very talented programmers at the top who are really interested in coding in spite of being so successful), though there are quite a few others like Microsoft, Martin Fowler’s ThoughtWorks, Joel Spolsky’s Fog Creek Software, and Steve McConnell’s Construx Software. Construx has published the Construx Professional Ladder for its employees who aspire to move up the corporate heirarchy (the ladder), and the best part is that it ensures that those who grow to be the Team Leads or Managers, are people who are widely read, and who have understood the nuances of programming, and can still solve the problem, if the programmers are not able to solve it.

To put matters in perspective, check this recommended reading list for a Level 10 programmer at Construx. Please note that Level 10 is not the Architect or the Technical Leader. It is the programmer with some experience ("College graduates will generally start at Level 9. Experienced developers may start at Level 10"). That might appear a bit over the top by your or my standards, but that tells you what separates the great companies from the merely good or average ones — it is the quality of the people. I think it was Kent Beck (in Extreme Programming Explained, Second Edition) who said something along the lines of "a more talented team will almost always beat an average or less talented team, no matter how disciplined and process oriented the average or less talented team is, and you can’t do much about it". A cruel (for me, at least) example of that in the wild is watching the Germans end up as the runners up (or loosing semi finalists) at the World Cups in 2002 and 2006, and in Euro 2008. With a bit more talent (or a bit more botch-up by the opposition, they could have won any of those events).

To be a good programmer, one needs to have a good grasp of the fundamentals of programming (and there is no better language to learn this than C followed by C++, though that unfortunately is out of fashion these days). This must be followed by learning a modern mainstream programming language like Java or C#. But if you start with either Java or C#, you would miss quite a bit on really understanding pointers and objects at a fundamental level. This must be followed by learning, reading and eventually mastering OOAD, UML, Refactoring and Design Patterns. It will be really useful if one can find the time to explore and learn dynamic programming languages like Python or Ruby, as they bring a different perspective to programming, thus enriching one’s knowledge and understanding.

Yet another mandatory aspect going forward would be exposure to Agile methodologies (don’t think I am crazy, but there is a big crowd out there that doesn’t understand what is agile). Even if the team is not 100% agile, there is a lot to learn from the agile community. If anyone has any doubt about agile, the only thing to keep in mind that the top guys of the Design Patterns movement are also the people who were the forefathers of the Agile movement — people like Ward Cunningham, Kent Beck, Eric Gamma, Martin Fowler, Alistair Cockburn, Dave Thomas and Andy Hunt to name a few that I can recollect over the top of my head. Since each of them are titans in their own rights, there must be something in it for us to learn.

The best part of this learning, IMHO, is that it leaves one in such a strong position to negotiate most of the stuff that comes one’s way – a bit like how Dravid could easily and with grace negotiate the unplayable deliveries from the Donalds, McGraths, Pollocks and Waqars of this world, in his pomp, in spite of not having grown up facing them or anyone of their calibre. This was made possible by the fact that in spite of not being a genius like Sachin or Lara, he kept on working on his game, improved every day as a batsman by putting in the effort, and thinking about his game. [I wrote this without being aware of the match saving 100 he made at Mohali].

The best resource that I am aware of to learn the basics of the aforementioned stuff , that I am aware of, is listed below. These books helped me immensely in my development as a professional, and I hope at least some of you can and will find them useful.

Programming Language basics:

The C Programming Language by Kerninghan and Ritchie (the K&R book)

The C++ Programming Language by Bjarne Stroustrup (it is a tome, but worth every minute of your time)

The Java Programming Language by James Gosling et al (a beautiful book)

Thinking in Java by Bruce Eckel (or the unpublished C# version freely available on the net)

Design basics:

UML Distilled by Martin Fowler

Refactoring by Martin Fowler

Applying UML and Patterns by Craig Larman

Object Oriented Analysis by Peter Coad and Edward Yourdon

Object Oriented Design by Peter Coad and Edward Yourdon

Design Patterns:

Design Patterns by Gamma et al. [the GoF book; I am yet to read this as it is in C++]

Head First Design Patterns by Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates

Design Patterns Explained by Alan Shalloway and James R. Trott

Taking the skills to the next level:

Code Complete by Steve McConnell, Second Edition

The Pragmatic Programmer by Andy Hunt and Dave Thomas

Software Craftsmanship: The New Imperative by Pete McBreen

Books on Agile:

Extreme Programming Explained: Embrace Change, Second Edition, by Kent Beck (there are two editions and it is fascinating to read both back to back :)

Agile Software Development: The Cooperative Game, Second Edition, by Alistair Cockburn

There are no shortcuts to mastery in any field, and software is no different. Unless you read some of the above books, you wouldn’t even know what all you miss (in terms of knowledge and skills missing from your toolbox). Again, this must be supplemented by some real hard work at the PC — programming, trying to implement and refine what one has learned. As the old saying goes, there is no substitute for practice.

Next, since we live in a society, we do need to work upon our soft skills, and people interaction skills come right at the top of the skills to acquire. One of the best resource to learn from this would be How to win friends and influence people by Dale Carnegie, as attested by both Jeff Atwood and Steve McConnell. In fact, if I remember right, McConnell writes something along the lines of "it must be made a mandatory book for every member of the team". How true!

Internet is such a free and ever available source to learn new stuff. In addition to reading MSDN or other technology oriented sites, read the great programmer’s blogs and learn from the masters. Let Google Reader be your best friend in this attempt. It has been for me, for three years now.

Update [14-Jan-09]: cleaned up the essay a bit and included a few more links in the story.

Advertisements

Written by Proto

December 22, 2008 at 18:15 hrs

6 Responses

Subscribe to comments with RSS.

  1. […] unknown wrote an interesting post today onHere’s a quick excerpt It was in the December of 2005 that I first wrote about how to be a better programmer. At that time I was into my fifth year as a programmer, and though I wanted to write what I am writing today, I decided to narrow down my scope to non-technical issues. I wrote about code readability and code maintainability that day. As important as these issues were (are), I guess there is a larger issue that must be addressed — the technical skill set of the programmers. Then I wrote about (nay, linked to) the fatherly advice to new programmers by Chuck Jazdzewski. I am now into my eighth year as a programmer, and unfortunately, the rate at which the industry has understood the importance of the quality of code or for that matter about issues like code readability or code maintainability is pretty dismal. This might be justified by arguments […] […]

  2. Great stuff man!
    Every fresher should be made to go through this :)
    Unfortunately world doesn’t care about this, if you get it done that is well and good.
    Even if maintenance and 2nd version are going to be difficult later on, you anyway charge the client for the mess you have created.

    The biggest problem in industry is that there are no good Mentors, whom ppl can look at up and grow. And I think only a few will be self motivated as you to explore internet and learn stuff…..when success comes even without so much of effort :)

    Arun

    December 23, 2008 at 12:12 hrs

    • Thanks, Apple, for the kind words about the post. The point of the post was not that every one should strive to be an expert. The point of the post is that the skill levels are not where it ought to be, and they ought to improve, if the Indian IT industry is to be a really serious player in the next 20 years. We have been into IT for how many years now? How many great Indian products have we heard about? One of the reasons for this, IMHO, has something to do with what you said — that you can be successful (read make money and move up the ladder, and not necessarily be a good role model or be good at what you do) without having the talent or learning the basics. But my point is how long are we going to be successful while creating software that is not good? As Stuart Halloway says:

      In what serious discipline is “It’s too hard” a legitimate excuse? I have never seen a bank that eschews multiplication: “We use repeated addition here–multiplication was too hard for our junior staffers.” And I would be uncomfortable if my surgeon said “I refuse to perform procedures developed in the last 10 years–it is just too hard for me to learn new techniques.”

      I mean, if one don’t know the basics, there is a limitation to the kind of problems you can tackle or the code or design you might employ to solve a particular problem. But, as you said, who cares? ;)

      Proto

      December 28, 2008 at 23:16 hrs

  3. May be its all lack of passion. “There are no good Mentors..” – thats exactly what some big organizations are emphasising or trying to achieve. What u cud learn from a good mentor or even by just observing them work – i dont think u cud learn that even from books.

    I am not too sure if i wud agree that by reading the whole lot of books a person cud be drastically different. The indian IT industry is more about labour arbitrage than anything else. If people with no technical exposure are being made managers what else is to be expected – too many cases of give and take.

    Also, i feel fundamentally its also a problem of talent. Lets face it – we are far from the cream of what our generation had to offer. We are here not because we opted for it..somewhere at some point we have not been able to achieve what we tried for. While i do admit that passion and hard work would certainly improve the state of affairs from what they are now – still, the “real” work would be done by the 10%, as u said, of the real thinkers.

    Anonymous

    December 29, 2008 at 15:58 hrs

  4. […] thought I was done and dusted having wrote that previous redux post about how to be a better programmer. But my good friend Subru had posted a comment that made me (as […]

  5. Thanks, Subru for the comment above (posted as Anonymous) dated Dec 29. My reply to that took the form of another post here: https://protoiyer.wordpress.com/2009/01/02/how-to-be-a-better-programmer-the-redux-part-2/

    Proto

    January 2, 2009 at 01:45 hrs


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: