Archive for the ‘computers’ Category
"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)
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 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.
I have been working as a programmer for a little over 5 years now, and it was with great interest that I read the article What is a Professional Programmer, written by Sarah George, and hosted at DeveloperDotStar Magazine.
I think I can say that I have been on the right path so far when I evaluate myself on the various parameters she has mentioned, viz., trustworthiness, teamwork, leadership, communication, constant updating of skills, an interest in minimizing risks and accountability.
However, there was another theme running right through that article, the theme of “how much Domain knowledge you need to do good Software Development?”. It was triggered by this comment by Mario Van Damme, to which Andy Tegethoff posted a great reply. But Andy didn’t just stop there. He followed it up with this wonderful post on this topic.
I have been of the opinion that Domain Knowledge just cannot be the be-all and end-all of Software Development. Yes, one needs to know enough of the domain to make sense of what one is doing, and what the client is saying. However, the current trend in the Software market in India (and probably elsewhere) is this: an average candidate with average-to-good domain knowledge is a better bet than a good/great programmer with almost zero domain expertise. During screenings and interviews, I have often experienced this line of thought in action. The argument is something like “programming anyone can do[!]; but to get guys with domain knowledge is very difficult”.
So, one is considered a better/worthy candidate if one is having previous working knowledge in a domain. And sometimes, the programming skills takes a clear back seat since this new guy is average-to-good at domain. Of course, domain is where the money is (meaning you get paid more).
What these recruiters forget is the basic fact that you are recruiting people for doing software development, and not to look after your domain/business. In fact, as established by Extreme Programming school of thought, it is much more valuable to have a true blue Domain guy (the actual Customer/Client or someone representing him) in the programming shop with good programmers than to have an army of domgrammers — short for domain-oriented-programmers. After all, most of the time, you just can’t become great at a domain in a short span (say 1-2 years) without sacrificing your programming skills. Of course, I am talking about normal people here. As the rule goes, “there will be exception to all rules, except this one”!.
In one of my previous projects, there was this culture of “anyone can do programming; understanding the domain is what it is all about” logic. I was really amused and shocked at that line of thought, but thankfully, I never subscribed to that school.
Towards the end of my first year in that project, we found out that the most critical module of that project was causing a hell of a lot of problems. We also found that there were serious design flaws and hell of a lot of bugs in that module. Luckily, I was learning Refactoring, UML and Design Patterns at that time, and my design skills were good at that time (or at least I thought so :). During this time I was looking after that buggy module and so was spending lot of time fixing bugs and logic-flaws, that just should not have been there in the first place.
I took it upon myself to set the house right, by re-designing the core of that module, and doing enough refactoring to change the design. After “some” struggle, I managed to convince my boss(es) that this is the only way to do it and that I can really do it. Remember, I was still considered one among the juniors in the team.
By this time, client was also breathing down the bosses’ throat to solve the highly critical bugs in that highly critical module. So, at the end of it all, the boss(es) agreed to allow me a free hand in doing what I wanted to do.
I was able to come up with a new design, and then refactor the existing code to fit the new design framework. It was not refactoring actually — though I used it a lot — since it involved a change in the behaviour; after all I had to weed out the bugs. During this process (which took me about 3 months) I had to talk to the client scores of times, communicate the design to the team, do lots of coding and teaching, explain the design to the boss(es) and client etc. I thoroughly enjoyed the experience.
I also understood that no matter how hard I try, I can never match a pure domain guy’s depth of knowledge. Also, it is not useful too, since I can easily learn from them. In the process I also learned that it is pretty hard for a software guy to be as good as a real domain guy, who is breathing the domain day in and day out.
More importantly, had I fooled myself into believing — during my initial days — that learning a few hundred terms and definitions of the domain will make me a better programmer, I would never have been able to come up with the new design.
Just thought will post about one of my core beliefs — that technical knowledge is a hundred times more important for a programmer than domain knowledge.
But of course, the fact remains that I am paid and will continue to be paid less than a hot shot domgrammer or Business Analyst. But that is ok, since I get to do, what IMHO is, the most challenging task of converting what is required into a great design/software that provides the solution.
Of course, Dan Read offers his point of view here on this topic, and as always, it oozes with pragmatism and common sense. But yet, it is difficult to miss the message that in 90% of Software houses, domain knowledge is only that important.
Thanks for reading thus far. It will be really great to get some feedback/comments. Have a great week ahead.
"Let the information come to you instead of [you] actively searching for it." — From the introduction to RSS by LoadAverageZero.
I have been thinking of posting about the greatness of RSS [acronym for Really Simple Syndication] and how it has completely changed the way I browse for about 4 months now (believe me!). I just couldn't motivate myself to write about this thing which might or might not be useful to everyone.
But today I got the bit of inspiration I was looking for. One of my friends who is extremely busy these days, send in this by mail today:
"…are u updating the blog? Tell me if i would get a mail after u update…"
This triggered off a train of actions that ultimately resulted in this post.
OK, having got the why this post part out of the way, let me get down to explaining what this fuss is all about. RSS is a three letter acronym that stands for Really Simple Syndication, Rich Site Summary or RDF Site Summary. Whatever, it is, all we should be worrying about is how to harness the power of RSS.
But, at least some of you might be interested in knowing a bit more about RSS. So please this post by Dan Read of DeveloperDotStar first, where he touches upon the beauty of RSS and how useful it is, and after that links you to this simple intro to RSS posted at LoadAverageZero. However, there is a much simpler and more layman-ish intro available at the BBC Feedfactory site.
So go, first read Dan's post followed by either of those two intros. Till then I will wait, I promise.
Ok, now that you know how simple RSS is — it is just an XML file — you need to know how to harness its power.
There are special (and simple) software available that can make sense of all this XML stuff being spewed out by the various sources, including BBC and DeveloperDotStar. For this, we use something called as a News-Aggregator or a News-Reader, of which there are two kinds — desktop and web-based.
The basic tasks of a feed reader will be to:
- Keep track of the news and blogs you are interested in
- Highlight the entries you are yet to read
- Have a way to link to the original post for each entry
The desktop reader is a simple application that you can download and install in your PC, that will keep track of all the emerging news and blog posts. There are also special plug-ins available that can be added onto either Outlook or Firefox (Sage) to do the same thing. This avoids the use of an external application (other than your browser and/or mail client). Another cute way of achieving the same is to use the mail client Mozilla Thunderbird that has a built-in news aggregator.
The disadvantage of this approach would be that if you are using more than one PC to browse the web (say one at work and one back home as I am doing), then these two versions will not be in sync. So you won't be able to easily find out what all feeds you have already read.
This is where the web-based version comes to our rescue. Here you login to a site — just like logging into your mail account — that keeps track of your feeds for you. The best among the desktop version would be Bloglines, Rojo and Google Reader. I am using Google Reader for about 5 months now though it is still in Beta.
There is a another class of web based aggregators emerging now, that offers much more than just aggregating your feeds. These are popularly known as a web-desktop. The best among the lot would be Netvibes, closely followed by Google Personalised Home, PageFlakes, My Yahoo, MSN Live and countless others.
But of this lot, I prefer Netvibes, which I am using for about 4 months now. I use it to track the feeds, but prefer doing the actual reading in Google Reader.
Now, here comes the best part. To help you experience what I am talking about I have created one account each in Bloglines, Google Reader and Netvibes.
You can access all the three using the same eyedee, pasvord combination of "protos?_DOT_?buddy?_AT_?GeeMail?_DOT_?Com" and "welcomebuddy" respectively. Hope you got the eyedee thing right. Just ignore the question marks and underscores. Replace DOT and AT with the real thing. OK? Please do visit each of the three and see for yourself the power of RSS and web based aggregators, not to mention the extreme usability of a complete web desktop solution like NetVibes.
A few tips: When you visit Bloglines do click on the "My Feeds" link at the top left section. In Netvibes, admire the fact that you can track anything from weather to your mail to news to stock prices just by staring at that page.
So, in a nutshell, RSS is all about letting the info come to you rather than actively searching for it, as mentioned in that LoadAverageZero intro.
I really would appreciate if you can comment about the usability of this article. That will help me in improving my posts in future. Thanks for reading thus far.
Postscript: Yes, I am going to mail my friend that I have posted an entry. But I just hope this will be the last time I will be doing so :).