Book-Summary - Peopleware - Productive Projects and Teams

• Author: TomDeMarco & Timothy Lister
• GoodReads: Peopleware

This book talks about different aspect of software project development, software development environments and how to develop software engineers.

• High performance engineer is 10 times better when compared to the worse ones. They are 2.5 times better than medium ones. This is something we can observe with respect to delivery timelines, ramp up time of the projects worked by high performance engineers and others. This is even more observable when a high performance engineer leaves the team. I guess key is to find that before hand and make sure engineer will not leave the team.
• We tend to hold very high value to language of choice for development. But in reality there is no relationship between performance and language of choice. Off-course there are some exceptions, example you are developing kernel code or embedded systems.
• Authors mention there is no relationship between performance to that of salary and experience. This I tend to disagree a bit. I feel salary should be such that it should provide a satisfaction to developer that I am honoured for my work. This is also true that as we get experience in the same team, the tribal knowledge grows which helps in improving performance in that team. This might not help when team or project changes.
• Device your own ways to measure your productivity. There cannot be a standard way to measure it. Every developer works in their own style and ways. What works for one may not works for others as things which are important for one may not be important for others.  
• Your measurements of productivity should be used for improvement, motivation, enhanced job satisfaction. This measurements data should be private
• Your work environment should be silent and private with very less interruption. Open office looks cool but really not good for productivity. That does not mean open office does not have any advantage. It is very much necessary for scenarios like when you are new joinee trying to learn about team and service, project is in initial phase where lot of adhoc discussions are needed.
• For any interruption/message you are about to make, ask is it really important to be interrupted? How long can I wait before answering the message?
• Appearance does not matter. We are bound to choose who stick to norms which is not useful. Our mind becomes uncomfortable when something is out of the way whether it is dress habits, work hours. Try to break that bias.
• Leadership is a service
  • Step up to the task
  • Be evidently fit for the task
  • Prepare for the task by doing homework ahead of time
  • Maximise value to everyone
  • Do it all with humour and obvious goodwill
• The ability to lead without being given authority to do so is what set apart others from leaders
• For interviewing new candidate
  • Verify their past work - github, papers, resume
  • Have a programming session. Its always best if you let them work on your project. Simple programming sessions also helps. Personally, I feel we should be trying to find about the engineer not the end result of the programming. Even though program was not solved but engineer shows all the right aspects of working with a team and learning, then they should be given opportunity.
  • Let all the future co workers interview the candidate and provide feedback. This may not work in bigger team but at-least majority of team should get chance to interview.
  • Aptitude tests are not that useful. Till now I do not see it helping in any way in deciding how a developer will succeed in their programming career.
• Do one thing at a time. In meeting, be in meeting. In stand-up meeting be at stand-up meeting. Do not mix up with other tasks. Give total attention. This is the greatest quality as you grow in engineering. You are expected to work on multiple things at time but its your ability to make sure you work on a single thing at time otherwise you will not deliver results on anything. This does not mean you will not be managing multiple projects.
• Understand what is your contract of work. This helps to set the right expectations. This helps to make decision regarding whether to accept a work or not, what are your priorities.
• Many things what we consider today’s technology will become tomorrow’s environment.
• Train the new hires such that they can do the new work independently without your guidance in the future. Training the new hires is linked to the long term retaining of the employee. Instead of just firing because their skill is out of date, retrain them to new skills
• For jelled team there should be a common goal towards which team works on
• Team members should have freedom to make mistakes/wrong and learn from it. They should not be too afraid to make changes fearing what happens when there is a mistake.
• Phoney deadlines do not work. It will bring down moral of the team. Little bit tight deadline will give a challenge but impossible deadlines will falter.
• Tight deadline will always lead to bad quality product and this will lead to team attrition.
• We do overtime to shield our selves from not getting things done on time and also we did not say no to things.
• Peer coaching is a healthy sign of jelled team. If we put team members competing with each other, it will affect peer coaching 
• Annual salary or merit reviews, management by objectives, praise of certain workers for extraordinary accomplishment, awards, prizes, bonuses tied to performance, performance measurements in any form will impact team badly
  • But what is the alternative here?
  • Any action that rewards team members differently will start competition among team members.  
• Team members should feel proud of their work and yet Team members should not become defensive about their work
• Team members need time to time small victories/ closures to get inspired and assured. So break a project into smaller milestone so that we can start tracking from early. This helps to understand our deviation from the project much early and also helps us to have the sense of accomplishments from the beginning.
• For every meeting before scheduling/accepting decide what ends this meeting? It should never be time/clock 
• Fragmentation of work and project effects our productivity a lot. Its just interruption masked as multi project/tasks. So when you are having multiple projects, understand clearly what are the priorities of each one. Make sure you work on first priority project complete a milestone and then move on to another project or other milestone.
• Any change has following stages
  • Old status
  • chaos
  • practice & integration
  • new status
• For any one to try the change they need to feel safe. They should not be ridiculed or punished for failing
• Knowledge of the company exists in the middle management/engineers - not the high level managers/heads or beginners.
• Identify free electrons in the team and give them complete freedom to define their own responsibilities