Aug 28, 2007
7 tips for programers.
It saddens me. Really makes me sad, to see how programs are written. Being in India we gloss over and drool over the foreign investment coming in, about offshoring, about being in the global market. But, just stop to consider ... how many software packages are really made in India end to end ? In my experience , its all handed down from US or UK or wherever the parent company is , line by line, as to how we are to make the software. And in most cases, the end result is something which makes us feel like ... umm... is this the best that can be done ?
Being right in the bang of how software is made, I think its more of an attitudinal problem. Its how we take writing code that is the problem.
So, my dear software programmer, this article is for you. The stuff you are expected to do, and which you are not doing. Please start at the earliest, or all your aquaintences are gonna come to pull your hair out in frustration. This goes for programmers and software architects.
1. Design it to make it Fun.
Now the definition of fun changes from application to application. In a game it is the gee-whizz factor. For spreadsheets it may be nifty features like summation. If your product does not have a 'wow' factor, there is something you are doing which is seriously wrong. Visit the design again. Add or remove from the features you have. Be bloody creative man !
2. Design for the user and not yourself.
So what if its difficult to implement. So what if you have to do some scary pointer arithmetic. The end result is for the user not for you. For the end user make it easy and simple to use. A typical end user is not techno savvy to the same extent who is going to sit down and figure out round about routes to make the software work. If you can't do it, drop your attitude of mental superiority. Test for edge conditions not straigtforward scenarios which will work anyways.
3. Make it easy to Remove.
Yes. Your software should be easy to remove. If someone does not like your software, he should be able to remove it instead of having to lug the entire software he installed cause now there is no way to remove it. What a pain.
4. Take ownership dude.
The management philosophy is more about discrete chunks which other people will work on. That is a recipie of disaster. Be aware of the entire code. Its not only good for the code as more eyes and minds will be on a problem when it comes - you can be sure it will come. It also makes it easy for people to transition in and out of projects - which is a fact of life in the programming companies we have.
5. Team Work.
Derived from pt 4, but its so strange that people hardly do it. Most of the time its about 'hey he may shine more than me'. If you are so scared about that, then probably you dont deserve to be a programmer. Go, become a politician.
6. The middle path.
Buddhism defines the middle path - the correct balance. You need that in your code too. You cannot design with having too narrow an approach or make something thinking it will be used maybe 2 iterations down the line. Strike the balance.
7. Crash it.
While devloping, try to keep crashing your code. The more it crashes during development, the more strong it is when it comes to users. Use version control if you are unsure of code changes. Thats what it is for. Dont keep local copies which will 'works on my system'.
Here endeth my rant for today. Go forth. Write great code !
Subscribe to:
Post Comments (Atom)
A good write up!
ReplyDeleteLets me know what I am doing right and what I can do right.
Would be hard for me to tell you that as I am not observing what you are doing !
ReplyDeleteGreat tips by my ex-manager!!
ReplyDeleteEspecially liked the points 2 and 5
well... good/efficient code hard to write! so it should be harder to understand too! :) hehe
ReplyDeleteSW Architects.. well i think that is more of a team effort not like a cowboy coder job! To approve a project design takes reviews and meetings for more than a year! well.. depends on the type of industry and the size of the project I guess.