Skip to main content

Lessons learned over a period of time as an IT developer

Have listed down few Lessons learned on the field which I found useful over a period of time.

1: Always execute every line of your code

After developing a feature one needs to obviously test it. Make sure every line of your code has been executed at least once. Many times see bugs on a certain line of code which had never been run by the developer. Kind of a condition within your code where the control never reaches during the normal flow. The code might look decent enough while reviewing, but unless you had made sure control comes to that part of your code and test it nothing is guaranteed to work.

Sounds obvious, doesn't it? Think how many times you would have faced this scenario by having used some test data which never takes you to an "else" part of the code (or) "case" of a switch statement etc.,

2: Logging, Error Handling to be part of the code from the very beginning.

While developing a new feature/module/project add logging and error handling from the beginning of the development as both of them would be really useful & help you be more productive. You always need a way to know what is happening in the program like how much time important parts of the code are taking, exceptions being thrown etc.,

Sooner you know about the issues in your code easier it is to get them fixed.

3: Always change only one thing at a time

Always make sure to do short iterations, confirm that it works, move on to the next one & repeat the same process. It is easier to identify the root cause of the failure if you had made just one feature change at a time.

I used to follow the same principle while committing changes to source control as well. So that if I need to revert back any specific feature it becomes easier.

You might think to make multiple fixes (or) adding multiple small features quickly and then add the code to source control thinking you have control over things. But that is just a good case scenario. What if something messes up in the code (or) some features were pulled out of the release at the last minute?

4:  When in doubt use paper or whiteboard

Whenever I get stuck while writing a program I just stop, move away from my laptop, pick a piece of paper or a whiteboard marker and start writing the program there. Many times I had found it to be useful to recollect my thoughts, don't worry about the syntax, just think about the actual problem & solve it quickly.

5: Load test your code

Do not claim the code to be complete by just checking your code with few hundred sample data in the database. Try to simulate the load of the actual scenario of your production environment.

With just 10 or 100 records most code would run faster without many issues but maybe the table you hit in your production database might have few million records and it might take forever to return you the data. Maybe in your production environment, there might always hundreds of users using it at the same time but you had tested with just one user connection.

6: Unit Testing should be made compulsory 

All code change should be accompanied by a unit test. Though it will make developing any change slightly slower it's worth it because it makes the code base scalable. Also, need to make sure automated unit testing is in place at the earliest.

I find that writing unit tests actually increase my programming speed - Martin Flower

7: Talk to your team frequently

If you tend to talk only to your peers, upper management over and over again there is a high possibility of you missing out on important feedbacks, suggestions which your team might have.

8: Share credit.

It's sad we have come to a level where this had to be mentioned separately.

Many times have seen leads, managers claiming that they did all the hard work to make something work. On any failure, the same folks would put the blame squarely on the team. Your team would have made 90% of the code to work and get stuck with some 10% of the tasks. You would have helped them fix it, fair enough, but you shouldn't take credit for the whole 100%.

It's very small world and in no time your team would come to know of this. One - your team would be demotivated, Second - you lose your teams trust.

Always go out of your way to mention who all contributed to this and don't ever steal somebody's credit.

"If anything goes bad, I did it. If anything goes semi-good, we did it. If anything goes really good, they did it." - Bear Bryant
In life, one has to be learning all the time. How important it is to never stop growing. That being said, would love to hear your feedback on this post.

Comments

Popular posts from this blog

Registry manipulation from SQL

Registry Manupulation from SQL Server is pretty easy. There are 4 extended stored procedure in SQL Server 2000 for the purpose of manupulating the server registry. They are: 1) xp_regwrite 2) xp_regread 3) xp_regdeletekey 4) xp_regdeletevalue Let us see each one of them in detail! About xp_regwrite This extended stored procedure helps us to create data item in the (server’s) registry and we could also create a new key. Usage: We must specify the root key with the @rootkey parameter and an individual key with the @key parameter. Please note that if the key doesn’t exist (without any warnnig) it would be created in the registry. The @value_name parameter designates the data item and the @type the type of the data item. Valid data item types include REG_SZ and REG_DWORD . The last parameter is the @value parameter, which assigns a value to the data item. Let us now see an example which would add a new key called " TestKey ", and a new data item under it called TestKeyValue :

Screen scraping using XmlHttp and Vbscript ...

I wrote a small program for screen scraping any sites using XmlHttp object and VBScript. I know I haven't done any rocket science :) still I thought of sharing the code with you all. XmlHttp -- E x tensible M arkup L anguage H ypertext T ransfer P rotocol An advantage is that - the XmlHttp object queries the server and retrieve the latest information without reloading the page. Source code: < html > < head > < script language ="vbscript"> Dim objXmlHttp Set objXmlHttp = CreateObject("Msxml2.XMLHttp") Function ScreenScrapping() URL == "UR site URL comes here" objXmlHttp.Open "POST", url, False objXmlHttp.onreadystatechange = getref("HandleStateChange") objXmlHttp.Send End Function Function HandleStateChange() If (ObjXmlHttp.readyState = 4) Then msgbox "Screenscrapping completed .." divShowContent.innerHtml = objXmlHttp.responseText End If End Function </ script > < head > < body > &l

Script table as - ALTER TO is greyed out - SQL SERVER

One of my office colleague recently asked me why we are not able to generate ALTER Table script from SSMS. If we right click on the table and choose "Script Table As"  ALTER To option would be disabled or Greyed out. Is it a bug? No it isn't a bug. ALTER To is there to be used for generating modified script of Stored Procedure, Functions, Views, Triggers etc., and NOT for Tables. For generating ALTER Table script there is an work around. Right click on the table, choose "Modify" and enter into the design mode. Make what ever changes you want to make and WITHOUT saving it right click anywhere on the top half of the window (above Column properties) and choose "Generate Change Script". Please be advised that SQL Server would drop actually create a new table with modifications, move the data from the old table into it and then drop the old table. Sounds simple but assume you have a very large table for which you want to do this! Then it woul