This book changed me, my attitude, my way of approach towards things and much more all about which I can only feel, not say much. The name seemed weird at first : "i want 2 do project. tell me wat 2 do" by Shakthi Kannan. But as I went through it, I felt, I should have read this before. It is actually a crux of all the experience and practices developed over the years by great engineers in the world of programming. Practices that may seem trivial but actually matter a lot. Practices that may bring out the best out of a person and help him or her learn to the fullest potential. Seldom we have a code of conduct, a book of behavior and practices and we suffer as the person before us in professional world just thinks, "look what do we have here, a joker and a nuisance" and we are rejected silently or in verbose. Matters end sadly but surely.
Shakthi Kannan has provided us with a short and effective guideline on how to act, behave and pursue things in the world of programming.
The book starts with a simple advice to call people by their first names and do not be carried away by emotions as people might tell you something that you don't like. Stick to your job and focus on learning because shying away or feeling sad for some comments will only make you a loser. Then the book discusses a notion that simply a student having a degree does not guarantee his being an engineer. This may seem obvious to us but most of us think very boastfully of our degrees (at least I had that kind of an air) and pride ourselves as software engineers. Here the book plainly states that, ". . . you can not buy knowledge" and rightly advises to be a prolific reader.
It outlines the practice of writing in mailing lists. There are illustrations about how to write the subject, how not to write in short forms, how to avoid writing in all caps, how to respond inline and trim the contents appropriately. The book discusses about how to link to a mentor. It stresses the importance of stating the problem precisely and not to make orders. It highlights the importance of selecting the right job, the right person, the right tools at the right times. A very important thing that most of us often forget and easily neglect is our replies to our mentor. The book states that no reply or late replies imply that you are not interested.
The book talks about various communication tools like the wiki, rss, irc, mailing lists, telephone, chat and spells out their properties. It urges the reader to select the right tool for the right purpose. The book also urges the user to go through search engines, ask on the mailing lists, ircs, and other places before asking the mentor a particular question. Truly that way, the question becomes more precise and becomes easy for the mentor to help and address.
The book highlights the importance of learning good English as this is the main mode of communication in the software industry. One must try his or her level best to write correct English and at least do a spell check before sending in things to others. If English is weak, it becomes essential to learn the language up to a minimum level first.
The author stresses upon regular communication with the mentor and team members of the project from time to time. He also demonstrates about how to ask a question to the mentor, not be blunt about it and ask a precise question. He highlights a very important point that I always felt short of, that is do work on regularly basis and not in the last minute. Regular jobs can be checked and corrected from time to time.
Last but not the least, the author tells us not to make any assumptions and always give proof of our statements. He says that we must never hesitate to ask when in doubt. We must always make sure that we have understood because remaining in silence gives the impression that we have understood. Our hesitation or wrong way of communication may jeopardize the entire exercise of the project. The discussion ends with a wonderful quote from the great Napolean, "Impossible is a word only to be found in the dictionary of fools".
Ever since I have read it, I have recommended it to others, my colleagues and my students. And I am sure that any one of you who goes through it will also change the way you think and behave.
Shakthi Kannan has provided us with a short and effective guideline on how to act, behave and pursue things in the world of programming.
The book starts with a simple advice to call people by their first names and do not be carried away by emotions as people might tell you something that you don't like. Stick to your job and focus on learning because shying away or feeling sad for some comments will only make you a loser. Then the book discusses a notion that simply a student having a degree does not guarantee his being an engineer. This may seem obvious to us but most of us think very boastfully of our degrees (at least I had that kind of an air) and pride ourselves as software engineers. Here the book plainly states that, ". . . you can not buy knowledge" and rightly advises to be a prolific reader.
It outlines the practice of writing in mailing lists. There are illustrations about how to write the subject, how not to write in short forms, how to avoid writing in all caps, how to respond inline and trim the contents appropriately. The book discusses about how to link to a mentor. It stresses the importance of stating the problem precisely and not to make orders. It highlights the importance of selecting the right job, the right person, the right tools at the right times. A very important thing that most of us often forget and easily neglect is our replies to our mentor. The book states that no reply or late replies imply that you are not interested.
The book talks about various communication tools like the wiki, rss, irc, mailing lists, telephone, chat and spells out their properties. It urges the reader to select the right tool for the right purpose. The book also urges the user to go through search engines, ask on the mailing lists, ircs, and other places before asking the mentor a particular question. Truly that way, the question becomes more precise and becomes easy for the mentor to help and address.
The book highlights the importance of learning good English as this is the main mode of communication in the software industry. One must try his or her level best to write correct English and at least do a spell check before sending in things to others. If English is weak, it becomes essential to learn the language up to a minimum level first.
The author stresses upon regular communication with the mentor and team members of the project from time to time. He also demonstrates about how to ask a question to the mentor, not be blunt about it and ask a precise question. He highlights a very important point that I always felt short of, that is do work on regularly basis and not in the last minute. Regular jobs can be checked and corrected from time to time.
Last but not the least, the author tells us not to make any assumptions and always give proof of our statements. He says that we must never hesitate to ask when in doubt. We must always make sure that we have understood because remaining in silence gives the impression that we have understood. Our hesitation or wrong way of communication may jeopardize the entire exercise of the project. The discussion ends with a wonderful quote from the great Napolean, "Impossible is a word only to be found in the dictionary of fools".
Ever since I have read it, I have recommended it to others, my colleagues and my students. And I am sure that any one of you who goes through it will also change the way you think and behave.
