How a new joiner can get to speed quickly...

As per my experience there is a big chasm between the academics and the Software Development industry in India. I have my theory for why it exists (a topic for a seperate blog).

But, I do wish that the new engineers that are recruited (some of them months in advance from campuses) spend some time getting ready for the industry before arriving on their new jobs. I have seen many engineers who may have scored high in aptitude tests etc. arrive on their jobs with no effort put in to get ready for the work. Many of them have the attitude “employers should provide training”. This may be fine with those who join the big companies like Infosys, TCS, Wipro who can pamper them for some months before assigning tasks but for the majority of smaller sized companies in India it is discouraging to see this attitude.

Following is my wish-list from a new joiner:

• Should have basic knowledge of the languages that the organisation works with (this must have been told during the interview or asked/researched by the person).


• Should know and used at least one Version Control System.


• Should have a “team mentality” instead of being an individual player.


• Should know when “he is stuck” or “when he needs help”.


• Should interact and communicate with peers and superiors (also helps out in 4).


• Should use the platforms provided in the organisations (meetings, information sharing sessions etc.) to expand his skills.


• Be passionate about any task assigned. Yes, you would some day architect a huge application, but you will have to prove your worth in smaller tasks first.


• Be open to challenging (though with facts & figures) ideas, processes followed.

Unfortunately I find many a times these skills lacking even in experienced candidates. If these points are conciously taken care the person would quickly feel at home in his new assignment and start liking the work and being effective quickly.

The Code Review Checklist

When a new Developer joins a team and is ready to handle tasks the next milestone for him is, to do a commit in the version control system for code. I remember being part of a team in which the code review process was so complex that when a new developer could first get it through what we called Pre-bouncers and Code Bouncers the individual used to treat everyone on the team with a Samosa or chocolates.

Though the code review should not be a very complex process it does have its advantages of preventing build failures with preventable code mistakes that your peer could easily find. Over this advantage I always felt that the greater advantage was - the communication between the engineers. The person whose code was being reviewed started to see what and how the Code Reviewer looks at the code and its side effects. It also helped transfer the coding best practices. In case of a Code Review being done by a Senior Developer it also started to set up a reputation for the junior Developers.

Though the Code Review cannot prevent all the problems it does set a minimum level bar for the code going to the version control system. The Code Reviewer should be called in only after all Unit Tests pass and the developer has done testing and step-through of his code changes. Following are the points that our Code Reviewer takes care of:

1. The code passes the Code Reviewers hallway testing.


2. The code should not be repeated at multiple places. An experienced hand can point to other places where similiar code may exist or can be easily refactored to accommodate the changes.


3. The code does not break the encapsulation of modules or introduce wrong dependencies.


4. The code is maintainable and readable with proper variable/function/class names.


5. The variables/functions and classes are at the minimal scope and visibility possible.


6. The code should be minimal lines without being esoteric.


7. The code should be commented at all places where an average developer needs to think hard as to what it does.


8. There should be no hard coding of magic numbers


9. There should be nothing in the code which prevents the same created build to operate on local machine, staging and production environment.


10. The code does not introduce obvious inefficient constructs.


11. The code written is always internationalized.

As you may observe all these are language/technology agnostic we have applied them with C++ and now in Java enterprise. What else do you think needs to be added without restricting engineer's creativity or making Code Review a complex process?

Inducting A New Employee (Software Developer)

In India there are two category of companies the big ones like Infosys, Wipro, TCS etc. who have considerable strength in their training departments and thus can layout training regimens that make the new joinee confortable. These companies have enough bench strength too, that allows ample time for a person to get up to speed. On the other hand are the majority of smaller size companies which cannot afford such a setup but still have to perform equal complexity tasks on tight schedules and resources.

I am now a days part of an organization which falls in the second category. We aim to quickly provide all data for the individual to start contributing. Apart from the talk that HR provides to the new joinee related to organizational rules and procedures, this is how my company goes about it:

A peer points the new person to where the code of the product , important files (like use cases or task breakups or decision analysis) are on the version control system. He also tells the person the softwares used and their versions. He is also pointed to a document which lists the same. In case there is a difference the new joinee has the responsibility to update it, get it reviewed and commit to version control.

A senior person gives the new new joinee an overview of the product and its functionality.

He also explains the structure and organization of the product modules and classes and answers any immediate questions. The process of code review or unit tests and software development process followed by the team are also explained.

With this background we give around one week to the individual to go through the existing code base. During this time he can ask any question to the Senior Developer who has the responsibility to answer or get the answers.

What we find is that by the end of the week the new joinee is comfortable navigating the project and now he is assigned a few bugs in his area of future working and he is soon up to speed.

Once this is done the next stage is to assign tasks as any other experienced Developer on the team.

Introduction

This blog will mainly concentrate on my journey of the Software Development world since 1992. During these years, I moved from a novice Developer to lead teams of 25+ engineers as part of a product with a 100+ engineering team and then to another young team of 6+ engineers on an Internet Project. I have worked with single site teams and distributed teams with individuals having experience ranging from 0 to 16 yrs. I have worked in programming languages from Fortran to C to C++ and Java and applications from Dektop to Client Server and currently Internet.

So, as anyone can easily guess, I have interacted with many individuals (Engineers, Managers, Sr. Managers and MDs) – observed their actions in various situations and learned a lot from them. Hopefully, I have also been able to impress upon some of them with what my ideas of what good Software Engineer/Engineering is.

The experiences that I had has lead me to forming some perceptions, theories and expectations, which I would be sharing on this blog. I would aim to provide a complete context before I write about anything so that the reader can provide constructive feedback so that my views are refined. Also, I would deliberately not name names or companies so as not to create unnecessary and fruitless discussions.

End of all this if my writings would turn out useful to a few, I would be glad as I know - that I have myself benefited from some exceptional people I have interacted with.