Where are the 'average engineer students' ?

I am pondering on this question for last 2 months. I will really like to hear from more people.

I work with Smart India Hackathon and was mentor to teams in Smart India Hackathon and Singapore India Hackathon. Here I work students who are enthusiastic and ready to learn. They are ready to experiment, they are confident, they are not afraid to fail initially to succeed later. Its a joy to work with them.

Obviously they are high in demand in job market and command premium for salaries. Recently I was recruiting for my startup and salaries of many of these students do not fit in our budget. Also lot of our work do not require high end talent. We are looking for students good in attitude and programming aptitude but may not be the best. We are also looking for interns.

For internship, we ask students for solve some small programming problems. I got 40+ responses from 2-3 colleges. 35+ students have copy/pasted the code from internet. Come on guys, I am using google since before your birth. I can find from where you copy/pasted your code in 5 mins. I still talked with 3-4 students and realized that they have not taken any efforts to understand the code. They don't want to take any efforts. I have similar experiences of interacting students with few colleges from Pune (not naming the colleges). These students are essentially at the bottom and practically unemployable.

Where did the average students disappear ??? Expected "normal" distribution will mean small set of students at both extremes and large number of average students in middle. However, now we have 'skewed' distribution with really large number of unemployable students at one end and small number of top notch students at another end and nothing in between. How did we land up in such a bad situation ??

Sane Branch Management of Version Control Systems for Teams

[NOTE : This is still a 'draft', please point out mistakes and suggest changes/improvements]
Some time back Nagaraj Mali asked a question about 'best practices for repository branch management' on one of our whatsapp groups. This is commom query. 'bad branching strategy' or 'no strategy about branching' are very common mistakes in project teams. These mistakes can seriously impact the teams productivity and quality. Unfortunately very few manager/scrum masters or tech leads really understand devastating impact of 'bad version control practices'. In this blog, I am attempting to explain my views and logic behind various practices that I recommend.

Mistake : Too many branches

A developer need to understand the difference between a 'branch' and a 'tag'. Many times teams use 'branch' where tag is sufficient. 'branch' is an 'active line' of development. Common practice is product teams is to support 3 previous versions (i.e major releases) for bug fixes and one new release'. For example your current release is Ver10 and you may supporting major Versions9, 8 and 7. Essentially you have 4 'lines of development'. Then you need 4 branches. Ideally you should checkout 'only' the  branch that you are working on. There is no need to checkout all branches. Since 'branches' represent 'live lines of development', once you stop supporting a particular major release, you should 'delete' the branch for that release. Typically you will have 4 to 6 branches and many/many tags.

Mistake : Creating new branch for every minor release

Assume a major release is 'version 9'. Then 'version 9.1' is developed on 'version 9'  branch ONLY. Remember 'Version 9' is the supported major release and 'live development line'. Version 9.1 is usually a 'NOT live development line'. Any code changes/bug fixes for Version 9.1 should be developed in 'Version 9' branch'

Common complaint : We spend long time in merging.

This is another symptom of bad branching and bad practices followed by team. Consider following branch scenarios.

1. Release branches for past releases
   
   Lets assume that new releases are developed in 'master' and team is supporting 2 previous release 'Version1' and 'version2'. Now team have done a bug fix in 'Version1'. Obviously customers will expect that same bug fix is available on 'patch release on Version2' and also available when new Version3 becomes available. So every day branches must be merged 'upstream'. i.e. merge Version 1 commits to Verson 2. And merge version 2 commits to 'master'. If you get any merge failure fix them. Daily changes are typically small and can be easily merged. This simple practice ensure that time required to do merges are drastically reduced and bug introduced because of merge problems are almost entirely eliminated.
   
   
2. Feature branches
   
   Many teams create 'feature' branches for every new feature or bug fix. However, they don't delete the feature branch one the feature development is over. At end of 'feature' development feature branch must be merged into 'master' and then delete the feature branch. It is best to use 'git flow' plugin/workflow for working on feature branches.
   
   Typical feature branch flow will be 
   • create feature branch from 'master' (so 'parent branch' will be 'master')
   • keep making changes and commiting in feature branch. Its ok to push feature branch.
   • every day merge 'parent branch' to 'feature' branch. This way any changes to 'parent' branch done by other developers are available to you and any conflicting changes are detected early.
   • once the feature is done, merge the 'feature branch' to 'parent branch' (usually 'master'). Since you are regularly merging the 'master' to 'feature', you will not see any conflicts when you merge 'feature' to master. Now delete the feature branch
   
   In both scenarios 'key' is the regular (preferably every day) merge from 'release branch' to master' or 'master to feature' branch.

Remember It is OK to delete a branch

Remember in version control there is nothing like 'permanent delete'. When a branch is deleted, you will not see it 'branches list'. But that does not mean all the history of such branch is also deleted. Recommended practices is to create a 'tag' from branch and then delete the branch. This will keep the history intact. It will also allow to restore a branch from the tag, if you need to do some critical bug fix in an older (now unsupported) release

Bottomline

Remember 'version control' is 'productivity tool' for the development team and NOT just a backup tool. Learn how to take advantage of the version control system and you will see signficant increase in productivity of your team.  Start by defining policy for 'branch creation/branch deletion and daily merge'.

Recruiting programmers through Hackathon/Techathons from Colleges

Last 2 years in Geometric Ltd. we recruited few freshers through Hackathon/Techathon from I2IT college.. And it worked very well. I believe the student we did not select also got benefited tremendously. I am documenting the idea and logistics and various tips/tricks in the hope that it will help other colleges and companies to implement similar programs.

The whole idea of recruitment Hackathon got a push by a chance meeting with Ms. Aruna Katara. Later I met Aruna and her team with few other members from Geometric Ltd. in I2IT campus. We got such a tremendous response from everyone at I2IT college, that within 3 months of initial discussion we had our first hackathon in I2IT.

Problems in typical Campus/Fresher Recruitment process

Typical campus recruitment happens through (a) short listing through General Intelligence test, (b) a technical interview (c) HR interview. Depending on the company there are additional steps as well. If you pass through all these steps, you get offer letter. However, this process has many flaws/problems in practice.

• Someone who performs well in General intelligence test may or may not perform well in actual programming/design tasks
• Technical interviews are many times superficial. Esp. if the student is not from computer science background, then it is difficult to judge his aptitude for programming in interview.
• Also if the person is introvert, is not fluent/comfortable speaking in English, then he/she may have difficulty in cracking interview (technical or HR). So a really good programmer may flunk in interview and may not get selected.
• Many times good programmers are not class toppers. So short listing using some cut off percentage based on college exam marks does not work well.
• It is very difficult to judge if the student will work well in team or not from the interview. Software development is a team activity. Hence it is important to judge student from team work perspective as well. (Group discussions does not really give any idea about how the person will perform in team)

Typical Techathon/Hackthon Recruitment Process that we followed :

• This process is for one college. All the students studying in final year are eligible to participate in Techathon/Hackathon. Typically its 3 to 6 student per team. If number of teams are high (e.g. more than 20 teams), then some short listing happens through review of hackthon project proposals.
• Hackthon winners may or may NOT get job offers. Mentors observe participants and record their observations about initiative, knowledge, programming quality, working in team, etc. Job offers are maded based on these observations. There are NO technical interviews or general intelligence or any other tests. Selected candidates go directly for HR interviews. And if selected from HR interviews, get offer letters.
• Before Hackthon we conduct various sessions for Students so that they can develop their ideas for hackathon. These sessions are conducted by Geometric Ltd. mentors and not outside trainers. For example,
  • Mindmapping - We encouraged students to use mindmap for brainstormng and developing their ideas
  • Basics of User Experience Design
  • Basics of Version Control using Subversion (so that teams can easily coordindate their work)

Logistics of Hackathon :

• Along with College we identify a 'big enough' Hackathon Area in the college campus. On the day of Hackathon, this area is equipped with tables, power outlets, LAN/WiFi connections, some rest/sleeping arangements. College takes care of these items
• Geometric Ltd. took care of (a) food arragements (i.e. lunch, dinner, snacks, 24 hour availability of tea/coffee)  (b) T-Shirts for all participants with Geometric Logo (c) Awards for winners and participation certificate for all participants and other misc items. (d) other branding related activities
• Geometric mentors are present (typically 8 to 10 mentors) through out the event to help participants if they get stuck.
• College Faculty members are present to help students.
• Actual Hackthon is a 24 hours Event. We typically start on Friday 6.00pm and we end the Hackathon with Award ceremony etc on Saturday 7.00pm.
  • On Friday 6.00 pm, Hackathon starts with a very short (Max 30 min) inaguration ceremony.
  • We typically have 3 team status updates during hackathon.  (a) Just before dinner on Friday (b) Saturday morning before breakfast (c) Saturday morning before or after Lunch. Status updates are very brieft. Teams have to give a quick update on where they are , if they need help on anything, if any team needs help then a mentor is assigned to that team.
  • Around 3.30/4.00pm on Saturday judging starts. Judges go to every team and see the demo. Team gets 5 to 7 minutes to demo what they have done and there is a brief Q &A.  Powerpoint presentations are NOT allowed.
  • Teams are judged based on innovativeness of of idea, completeness of demo, quality of demo, etc.
  • Around 6.00pm Saturday, award ceremony starts.

Identifying potential candidates for recruitment

• We create a 'whatsapp' group of Geometric Mentors. During 24 hours Techathon, Mentors continously post their observations about students and teams on this group. Observations are typically related to quality of ideas, team work, programming knowledge ,programming quality and aptitude of specific students etc. 
• At end of Hackathon, We email the archive of this discussion to all mentors and then delete the whatsapp group.
• After Hackathon, we ask college to send us the Photographs of each team with names of Team members clearly marked.
• Using the observations posted on Whatsapp group, we identify pontential candidates. Each mentors shares his opinion,observation and experiences of identified candidates.
• The names of these candidates and team photographs are cross checked to ensure that there is no mistake. 
• A final list is prepared and shared with Recruitment Team. The recruitment team then coordindates with Training and Placement office of College for final HR interview and offer process.

Few unique ideas from Geometric Ltd. recruitment Techathon 

1. Many companies invite 1 or 2 teams from many colleges and then select students from these teams. We decided not to go in that route. Our observation were (a) same 2-3 teams from a college ends up participating in multiple Hackathons.  (b) hence larger student population do not benefit from these events (c) same team participates in multiple hackathons and show the same project in those hackathons, essentially defeating the purpose of hackathon.
2. With our model, different companies can go to different colleges and do the Hackathon as outlined above, many more students will benefit from it.
3. Typically Hackathon happens in July/Aug timeframe. The teams can further develop these hackathon projects as their final year projects.
4. We keep in touch with selected candidates during the next one year. Last 3 years we conduct quarterly Techathons in Geometric Ltd. We invited these selected candidates to participate in our Techathons. Candidates then work with Geometric Teams in our internal Techathon. This one simple idea helped in various ways.
• we kept in touch with college and students.
• it created a bond with those candidates.
• Because Geometric employees closely worked with these candidates in Hackathons, they developed personal connnections with these students.
• When the studentsjoined Geometric after completing their degrees, It was much easier to place these students in various teams compared to other fresh joinees. Mainly because many Geometric project/product teams already knew about them and were ready to welcome them immediately.

Aknowledgement - 

These Hackathons were enormously successful because of support and cooperation from many people. In case I missed anyone, I am sorry. Feel free to remind me and I will add.

• Senior Management of Geometric Ltd.
• Geometric Ltd. Recruitment Team (esp. Sandip Panat, Kamal Dunani) ,
•  HR team (esp. Rakhi Sinha, Anwesa Sen) 
• and Very Enthusiastic Techathon Volunteers (Pratik Jain, Sagar Oak, Rajeshwari Purohit, Bhaskar Sinha, Hemant Shah, Ajit Vaze and Many others. It is really difficult to list everyone name here) 
• I2IT College Faculty and Students (esp. Ms. Aruna Katara, Dr. Vaishali Patil -I2IT Principal, Prof. Ravindra Joshi, Prof. Adesh Patwardhan and his team).

Characteristics of Software Technical Expert - As documented by Hemant Shah

Hemant Shah listed these characteristics of a Software Technical Expert in a mail to participants of Accelerated Technical Expert Program. I think this is a great list and forwarded this mail to various other Teams in Geometric Ltd. I am reproducing the list here as it will be great reference to everyone.

(PS - Hemant has uncanny ability to simplify complex ideas to simple core concepts. If you are in GeometricPLM/HCL Technologies, don't miss his sessions) 

 

While Nitin has been articulating the qualities which he wants to see in Techincal Experts,
Here is a list of things which has been compiled.

I understand that it might sound too much of super-human-like. Also most of the things you would already know.

This is just to document things in a single place.

Note that not all of them are unique or mutually exclusive. Some of them might be repetition of already mentioned points, with a different view point.

Technical Expert

1. A Technical Expert should be able to design a software.
2. A Technical Expert should be able to implement a software.
3. A Technical Expert should have a wide-ranging experience.
4. A Technical Expert should be the go-to person in the team for Technical queries.
5. A Technical Expert should be able to give Technical Presentations.
6.  A Technical Expert should be able to make, review, evaluate a Technical Proposal.
7. A Technical Expert should be able to formulate Technical Guidelines for e.g., Technical Coding Guidelines etc.
8. A Technical Expert should be able to evaluate a new software and give recommendations.
9. A Technical Expert should do Technical Bench-marking.
10. A Technical Expert should be aware of / read technical standards.
11. A Technical Expert should be aware of / read latest things available in his/her field. 
12. A Technical Expert should be member of Technical bodies. 
13. A Technical Expert should write Technical Blogs.
14. A Technical Expert should be able to compare and evaluate two software.
15. A Technical Expert loves challenging problems and attempts at solving them.
16. A Technical Expert should answer queries which are posted on Technical Forums.
17. A Technical Expert should take part in Technical Competitions. 
18. A Technical Expert should be a judge of a Technical Competition. 
19. A Technical Expert should attend Technical Conferences / Events. 
20. A Technical Expert should be a Speaker at Technical Conferences / Events. 
21. A Technical Expert should be able to guide / mentor new comers in the organization and the project team.
22. A Technical Expert should be able to analyse technical reports / findings.
23. A Technical Expert should have some preliminary business sense. 
24. A Technical Expert should be aware of the various tools available in his/her field of expertise, or should be able to find out and figure out.
25. A Technical Expert should take part in Techathons, Hackathons. 
26. A Technical Expert should have in-depth knowledge of a particular topic / subject. He / she should be an authority on that subject. A Technical Expert should have broad knowledge of other areas. 
27. A Technical Expert should have broad knowledge of the various Software Development Processes
28.  A Technical Expert should be part of the Technical Evaluation / Promotion of Individuals. 
29. A Technical Expert should improve the efficiency of the Team on Technical
30. A Technical Expert should share his/her knowledge across multiple domains.
31. A Technical Expert should share technical information with others.
32. A Technical Expert should inspire others also to become a Technical Expert.
33. A Technical Expert should do external Technical Certifications. 
34. A Technical Expert should be an innovator. 
35. A Technical Expert actively contributes on Social Media. 
36. A Technical Expert knows how to build a technical team. 
37. A Technical Expert challenges his / her peers with technical problems.
38.  A Technical Expert comes up with other challenging problems. 
39. A Technical Expert should be a curious person. He / she should be an early adopter of a new technology. 
40. A Technical Expert comes out with challenging test papers / question papers for the next generation to solve.
41. A Technical Expert should be able to talk to, articulate things to non-Technical folks like Human Resources, Business, Finance, Sales, etc.
42. A Technical Expert should be able to simplify complex topics so that other non-technical folks or other technical folks are able to understand and comprehend the complex topics.
43.  A Technical Expert should be able to take Technical Interviews. 
44. A Technical Expert should be able to sustain a dialog with other Technical Experts. 
45. A Technical Expert should be able to teach others about the Technical Skills which he/she has acquired.
46. 48.  A Technical Expert should be sincere, perseverance, able to express, diplomatic, great inter-personal skills, approachable. 
47. A Technical Expert should be an avid reader.
48. A Technical Expert is a Guru.
49. A Technical Expert is a Final Authority on Technical matters. 
50. A Technical Expert is a Role Model for others.

Machine gun programmers and sniper programmers

Based on my experience in working with various teams using different technologies and working on either projects or products, in maintenance or new development I have started classifying software developers into two categories.

1. Machine Gun Programmer
2. Sniper Programmers

Machine Gun Programmer

Typically when you give such programmer a problem to solve (e.g. fix a bug or add new feature). Typically he/she jump into debugger and randomly start changing some variables. Or he will start googling for answer and cut/paste the code from 'codeproject.com' or stackoverflow.com and see if that fixes the problem (mostly without understanding the code or the answer).  Essentially he/she is firing lot of bullets on 'target' hoping that one will hit the target. 

Many times he/she will spend hours working on some trivial problem because he has not understood the program flow and hence cannot analyze the root cause. So he tries lot of small small code changes. Somewhere one change hits and changes the programs behavior and in turn apparently fixes the bug. However mostly likely it will introduce another bug in the system. My friend Anirudha Raste calls it 'programming by coincidence'. 

Such programmers usually end up fixing one bug and introducing two more.

Sniper Programmers

On other hand Sniper programmers behave differently when given a problem. He/She will analyze the program flow, understand root cause, may go to white board and draw the flow. You may see him staring somewhere while he is mentally analyzing the problem. If he googles the problem, he spend time understanding each answer and validating if it is really a possible answer for his problem. Then he may change few lines and that will fix the bug permanently. 

Problem is Majority developers that I have interacted with fall into 'machine gun programmer' category. 

Sniper programmers are few and far between. If you have some sniper programmers, make sure that these gems stay in your team. Try to propagate and encourage the 'sniper programmer' attitude.

Remember you don't need much training to use Machine Gun so practically anyone can become a 'machine gun programmer'. However, every army have separate 'sniper schools' and sniper training programs. 

Becoming 'Sniper programmer' is difficult task. It requires constant learning and update. It is also most rewarding. 

Is your company really identifying the 'sniper programmers' and educating/training them ? or just depending on lot of 'machine gun programmer's ?  Answer to this question may determine the future of your company.

 

Persistent Systems and Mr. Anand Deshpande.

I think in last 7-8 years Persistent Systems has grown by leaps and bounds. I always wondered what is the key to Persistent's phenomenal growth. Few months back I met Mr. Anand Deshpande (CEO of Persistent) during a CSI (Computer Society of India) event. Well, I met him for 10 min but I keenly listened when he was talking to others. I also had a chance to have some informal discussion with few other Persistent employees. I am impressed with clear and practical thoughts and ideas of Anand Deshpande. Consider following ideas.

1. Persistent employees are deeply involved in organizations like Computer Society of India (CSI) and Pune Open Coffe club, ACM Pune chapter

Anand Deshpande encouraged Persistent employees to get involved in organization like CSI, Pune Open Coffee Club for long time. Now Persistent employees are key to these organizations. Persistent also allows these organizations to use its infrastructure like conference rooms, training rooms etc. This policy has given some great advantages to Persistent. The developers who get involved in these organizations usually care for 'their craft'. They are passionate about software and about developing their own skills. Now consider a developer who is involved in CSI and is now interested in changing his job. First company he is going to consider is Persistent, because he already knows the people from CSI work. And Persistent is getting some good developers with such personal contacts.

If this is such a good policy, why other companies don't do it ??

Problem is a company will get these benefits only if it consistently does this for 5/6 years at least. So companies who focus visible benefits in short term will never do this. Most of the companies (i.e. their management) don't have this long term vision.

2. College projects
Typically companies who sponsor college projects do it this way.

• Send a mail to all employees asking for ideas for projects.
• Company insists the project has to be in the technology domain that company works in.
• Usually at most 3/4 people reply. Some time nobody replies
• So company has a list of 3 or 4 projects 
• Since companies don't regularly work with colleges or give the list of projects to colleges, this works on personal contacts of students (i.e. students parents).

Obviously there are no great benefits to students or companies.

Usually companies publish 'list of projects'. Persistent publishes a list of 'mentors' and mentor's expertise areas And this is a Key difference. Now students work on their project ideas. And based on technology and problem domain and the quality of project idea Persistent chooses the projects and assigns a mentor. This way mentor's work in areas of their own expertise. As far as I know, there is no restriction that the project has to be the domain that Persistent works in. 

Now this process works great for Students and for Persistent. Students get to work on their own ideas rather than somebody else's idea. Students have to meet their mentors every week. And Persistent gets to know the students and can pick up good ones. Since the project students already know Persistent and its developers they are more likely to join Persistent than other company.

Persistent is the only company I know who have such practical policy on college projects.

3. Courses for college professors.

Last few years Persistent is running one week course for professors of computer science departments in colleges in the month of May. Again there is unique approach. This course is not about some latest buzz word techniques like 'cloud computing, Sliverlight etc'. This course is about some topic that these professors have to teach in next semester in their college (for example, 'algorithms'). So whatever these professor's earn in this course they will use immediately to teach their students in their colleges. 

Again Professors  benefit, Students benefit and Persistent benefits. We crib about quality of students coming out of colleges and quality of professors in such colleges. So Anand Deshpande concentrates on how to improving the skills of professors and indirectly the skills of students coming out these colleges. Now next time Persistent goes to these colleges for campus interviews, it will get to choose from the best. Also it already knows about quality of professors in those colleges. So it can decide which colleges to go for campus interviews. Again a win-win for everyone involved.

Just three policies told me a lot about Why Persistent is so successful. The secret ingredient of Persistent's success in 'vision and ideas of its founder Anand Deshpande'. My admiration for the company and especially it's founder increased many fold based on just one encounter. 

Congratulations Anand Deshpande for mentoring and developing a great organization. 

And Thanks. Just once chance encounter gave me lot of ideas. I hope I will get a chance to work with you.

Students and Professional Software Development

In May 2010, I conducted a workshop on 'Introduction to Profession Software Development' in Sir Padmapat Singhania University, Udaipur (SPSU). Previously I have conducted various introductory sessions for new joinees in Geometric Ltd (my previous employer). In all the projects that I worked on, usually 50% team members were 'freshers'. While working with these fresher/new joinees, I realized that even computer science students have no clue about 'professional software development'. Most of them have not even heard of 'version control'  so there was no question of using any version control system.

Obviously when they join a software company, it is a 'culture shock'. Also when these students try to work on some short internships with the industry, they spend more time learning such tools/practices rather than  development of their project. Hence industry mentors are not very happy with the output of such internship programs. 

The objective of this five day workshop was to reduce the intensity of this culture shock and help students to with internships, last year projects and also prepare them to work on programs like 'Google Summer of Code'.

Participants were divided into teams 4-5 students each. A SPSU professor was assigned as 'mentor' to each team. The daily program was divided into 

• class room sessions of about 2 hrs every morning, 
• 15-20 min presentation about yesterdays work by the teams 
• working a 'mini-project' during remaining time.

I conducted following sessions during the 5 day program along with reviewing the design/code. The team of SPSU professors worked with me to mentor the students, answer their queries, review the code/design etc.

Day 1 : Difference between amateur and professional software development. And the tools of professional software development (e.g. Version Control, Bugbase, Build systems etc).

Day 2 : Writing specification document

Day 3 : Key Principles of Software Design and how to write design document.

Day 4 : Principles of User Interface Design

Day 5 : Bad coding practices and how to avoid them.

The workshop was very interesting experience. 

• Most of material I prepared before hand has to heavily modified based on interaction with students. 
• As usual some student groups were not at all interested while some groups did fabulous job. 
• The professors were serious about mentoring the students and took a keen interest in their teams work. However, many professor didn't have any experience of working in a industry and it showed.
• Many students had done a basic java course. But most of them did not have any idea on developing a GUI in Java. Same was true for students working on C# or C/C++. 
• Some teams worked on Turbo C compiler. Obviously that experience with Turbo C and developing GUI with TurboC is not going to be very useful today.

Have a look at the news and photographs of the workshop.

The Program was organized by Industry Readiness Center (IRC) and Sir Padmapat Singhania University, Udaipur (SPSU) in collaboration with Poorvanchal Systems Pvt Ltd.

What do you think about such workshop ? Will they be useful to students and industry ? I am interested in hearing about your experiences.

Leadership

I found this good list of characteristics of Leader in 'C++ Coding Standard'. Well, c++ coding standard is not a likely place for finding advice on leadership. But sometimes you find get thought gems at unlikely places. So here it is

Leaders:

1. lead by example
2. don't ask anything of anyone that they wouldn't do themselves
3. are called on to make difficult and unpopular decisions
4. keep the team focused
5. reward/support their team in whatever they do
6. keep/clear unnecessary crap out of the way of the team
7. TAKE the blame when things go wrong and SHARE the credit when things go right.

The advice resonated with how I think.

Craft Of Programming and Mentors

One thing I learned from my experiences in Software Development is 'Software Development' is not 'Computer Science'. Its not a science and its not fully an art also. Sometime back I read an article where the author called it 'Craft'. I really liked the idea. Indeed, programming is a craft and a Good Software Developer is like a Master Craftsman.

As Craftsman you learn the tricks of the trade by doing it many times, mostly under the watchful eye of Master. There are really few Craftsman so gifted that they can learn it on their own. It means early years of Software Developer are very important. Those early years define if you become a average developer, a good developer or a Great Developer. If you are working with a Master Programming Craftsman, you will learn much just by observing how he works. If the Master Programming Craftsman is also a Good Teacher and Mentor, Then You are Very Very Fortunate.

I am fortunate because my initial years were spent with Master Programmers like T.N. Umamaheshwaran, Abhay Tarnekar, Pravin Waghmare, KK George in MSDCAD, Telco. I learned a lot in 1 year at Telco. Afterwards, I learned from the books of other Masters like Brian W. Kernighan, Rob Pike, GoF, Robert Martin, Martin Fowler, Steve McConnell, Herb Sutter, James O. Coplien, and many others.

Here is a my list of Good Books from some these masters which shaped my ideas of software development.

1. C++ Gems series
2. Code Complete
3. The Practice of Programming
4. GoF Design Patterns Book
5. Advanced C++ Programming Styles and Idioms
6. Robert Martin's articles on Design Principles.

Trust your developers (employees) and treat them as Responsible Adults

This is the first lesson I learned when I become a Manager of a software development team. 'Treat your Developers as Responsible Adults and Trust Them'. This simple advice, gave a me big advantage namely Trust and Support of the Development Team. 

Sometimes big benefits start with a simple ideas. Let me give an example to clarify my point.

Scenerio : An Important release of your project/product is coming up and a developer comes to you and asks for a 2 day vacation (leave). What will you do ?

The most common reaction in companies/project groups is to DENY the request. Manager will ask the developer to postpone it or even go to extremes like accusing him of 'not being a team player'.

Saying 'no' is a REALLY BAD IDEA. Does your team know the importance of the release ? Do you trust the judgement of the team members ? Do you treat them as kids to be disciplined or as responsible adults ? If you are treatng them as responsible adults and if the developer knows the importance of release and still asking for vacation, then it must be that important for him. So Don't be a PHB AND say that 'YES, you can take the vacation'.

If my release is stopped because of unavailability of one developer, then actually I am a BAD MANAGER. In Software, people do change companies. So if only one guy knows some part of the project and if he leaves for some reason, I (the Manager) am in major trouble. Its my responsibility to ensure that doesnot happen. I should not pass the blame to the team.

Treating developers as 'responsible adults' has lot of side benefits. You become part of THE TEAM. Lot of times, its team versus Manager (you). Now its Team (you + developers+qa) versus the product/project/deadline/problem. Now you have much better chance of Winning.

You respect the team members for their abilities and they respect you for your abilities. The Team is much more confident to suggest unconventional and innovative solutions to problems at hand.

If I ask the team members to come on weekend (a rare ocurrance in my teams), the team comes in without any complaints. Most of the time I don't even have to ask. If they feel its neccessary work on weekend for some reason, they will come on their own.

The team depends on each other expertise, advice is freely sought and given, the team morale and hence productivity is high.

Its real WIN/WIN for everyone...