Ok, I’m not a big blogger, so I’m gonna keep this thing real short.

I happen to meet a bunch of software engineers who are really new to the industry and I saw their mistakes, which I did at the beginning of the career. Lets cut to the chase. This is my simple advice if you are a software engineer trying to tune yourself up.

  1. Always indent the code
    Why? I mean, when you have a load of tasks to complete, why would you spend time on indenting? Two things to note here – a) you wont be able to debug your own code. b) No one likes to support your code later.

    Overview of unindented vs indented code
    unindented vs indented code
  2. Import or include libraries only you use
    I have seen people using java.util.* for using a HashMap. Ok, let me make this clear – loading classes with asterisk DO NOT load the actual classes in memory thereby consuming more memory. This is just a way to tell compiler where to look for it. So, why do we want to do that if thats the case? This is the clear way to tell others what libraries or classes used by your program.
  3. It’s not what you write. It’s how you write.
    Use proper language specific standard for defining variables, methods, classes, etc. Understand this – anyone can write a program but programmers write a good one. Also, use meaningful variable names. There is difference between using a standard and a meaningful name. For eg: Say, you are using lower case key for a particular operation “lKey” is ok but “lowerCaseKey” makes sense for that variable.
  4. You already know how to write a simple program. For everything else, there is Google.
    Always depend on Google. Not on the guy/gal who sits next to you. Dependency will cause two main problems a) you will not learn a thing. b) The other person’s time is wasted, eventually.
  5. Put yourself in client shoes
    Don’t stick yourself to the requirement document. Always, think how would you react if you happen to use that site and suggest client about improvements, constantly. Not only this helps bring up a good application at the end, but also improves client confidence with you.
  6. Prefer object orientation
    Object Orientation is the best approach to programming till now , which is why, even interpreter languages switch to object orientation. The benefits are limitless and is textbook but what benefits does it bring you, a programmer? Many things including redundant code reduction, re-usability and other textbook definitions like inheritance, etc.
    It is a best practice to comment every 3 lines but please comment during every logical checks, breakpoints, iterations, etc. Also, follow all types of commenting – class level, method level, line level, etc.
  8. If you don’t get something right, don’t quit
    Be a competitor, Be a fighter and Be a winner.  If you have selected a logic/path to code a particular design, do not change unless you are sure there are no way out of that path to completion. Changing the logic often confuses the programmer of his initial objectives.
  9. Proper – meaningful error messages
    Do NOT log error which makes sense only to you. I have seen production code with funny errors (even seen Tamil word errors) and that’s definitely not funny. Always be professional. Either it be testing by self or a prod code, just be professional and log professional errors. And one more important thing – do not let an exception get out to customer UI. I mean, if I’m using a site which throws NullPointerException in the front end, I would close the browser right away.
  10. Test the code, at-least once
    Ah, this one is very very important. I hate people who don’t even test/run their program once to verify everything is okay. If you don’t even care about the correctness of the program, better don’t code anything. Be conscious about what you have written, understand the requirements, check for correctness in your code and finally, release the code only if you are satisfied.

Alright, that’s all I had in mind. These points are not exactly the perfect way to code but these are the ones, I, as a programmer felt that anyone, who claims to be a programmer should be made of.

Thanks for reading and hope you will be reading my next posts in the future!

6 thoughts on “Are you a programmer? Really?

  1. I am a tester by profession, i agree to ur last point strongly …. if the code is atleast unit tested.. it saves a lot of our time, to perform other kinds of tests on the system , rather than the sanity tests..

    BTW the blog was useful .. and not stupid !

  2. Well composed Velu. I absolutely accept with point on code indentation or clean coding,Commenting the code both are absolutely necessary for future code maintainability and future enhancements.

  3. I am far removed from coding, and I don’t think I am ever going to write any piece of code. Nevertheless, the post did refresh my memory and am sure it will be very useful to freshers.

    You write well. Keep writing.



Leave a reply


<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>