This was a post I wrote in 2011 that hit #1 on Hacker News. I accidentally deleted all my old posts at some point, so I am bringing it back. Some of the references are a bit dated, but most of the core messages still ring true today.
“We may be very busy, we may be very efficient, but we will also be truly effective only when we begin with the end in mind.” – Stephen Covey
It seems like everyone is busy these days. Especially when you are in IT. You are constantly being asked to do more and do it more efficiently. But, the important question is, how truly effective are you? In other words, you may work 100 hours a week and perhaps you do a particular task faster than anyone else, but that does not necessarily mean that you are effective.
Effort and efficiency are related to what you do while effectiveness is more about what you achieve. In other words, does it really matter how long or fast you work if you are not achieving your goals? Of course not! Hard work and intensity are valuable but only insofar as they help you reach your end goals. Effectiveness, therefore, is what organizations should look for in their developers and how developers should gauge their own abilities. I believe there are 4 primary characteristics of effectiveness for software developers.
Everyone makes mistakes. Everyone. I mean, seriously, ev – ery – one. In one sense, saying that no one is perfect is like, “duh!”, but understanding and accepting this does not come naturally. When a software developer makes a mistake, the reaction of the developer typically falls somewhere between the following two extremes.
- The developer gets defensive and focuses most of his/her energy on deflecting blame and/or protecting himself or herself. After the problem is resolved, the developer does his or her best to make the issue a distant memory.
- The developer sees that there is a problem and focuses most of his or her energy on solving the problem. After the problem is resolved, the developer reflects on what he or she did wrong and what changes can be made to ensure a similar mistake is not made in the future.
Both Developer 1 and Developer 2 have some sense that they made a mistake, but their reactions to that information are vastly different.
In the mind of Developer #1, making a mistake is not normal. It is not something that can be explained easily to others without losing face. Developer#1 thinks that mistakes are a black mark against him or her that will never go away. In all likelihood Developer#1 will continue to make the same types of mistakes again in the future because he or she learned nothing from the experience.
Developer#2, on the other hand, may not like that a mistake was made, but he or she accepts the mistake and focuses on solving the problem. In fact, you could even say that Developer#2 typically owns the mistake. He or she openly and clearly says to everyone “yes, (this) is what I did wrong and (this) is what I am doing to fix it and (this) is why it will not happen again in the future”.
“When you make a mistake, admit it, correct it, and learn from it immediately.” – Stephen Covey
Over time, Developer#2 makes fewer mistakes because he or she understands what went wrong and he or she is able to make the changes necessary to avoid future recurrences. Because of this, the overall productivity (i.e. effectiveness) of the accountable developer continuously increases over time.
2. Ability to Work with a Team
Prior to the start of the 2010 World Cup, it was common knowledge that the French national soccer team was in disarray. In spite of that team strife, however, the team was regarded as one of the best in the world with players like Thierry Henry, Frank Ribery and Patrick Viera. They were runners-up at the previous World Cup and many people expected them to contend for the 2010 World Cup. Unfortunately, things didn’t go so well.
- Game 1: France 0 – Uruguay 0
- Game 2: France 0 – Mexico 2
- Game 3: France 1 – South Africa 2
France didn’t just lose and get knocked out of the tournament. They thoroughly embarrassed themselves. Despite all their talent, they couldn’t even pull off one win. Soccer is an unforgiving sport when it comes to teams that don’t have chemistry. Teams that work well together generally do better than teams that don’t work well together.
The same can be said for software development teams. You can do a great job of collecting the best collection of individual technical talent, but if they can’t work with each other things start falling apart and the overall team productivity takes a nosedive. Some of the symptoms that are pretty typical with dysfunctional development teams include:
- Issues during testing or in production due to the fact that the developers were not in sync.
- Time wasted arguing and complaining instead of solving problems.
- Dissatisfied customers that don’t get the products and/or service that they expect.
- Unhappy workers that quit or become less productive.
So, how can developers get better at collaboration and IT managers build teams that have synergy? I think it all starts with instilling a win-win mentality throughout the team.
“Win-win sees life as a cooperative arena, not a competitive one. Win-win is a frame of mind and heart that constantly seeks mutual benefit in all human interactions. Win-win means agreements or solutions are mutually beneficial and satisfying. We both get to eat the pie, and it tastes pretty darn good!” – Stephen Covey
There are many small things that people have to do to work well together, but if you don’t start with a strong foundation based on the win-win mentality you will face an uphill battle. Win-win represents the earnest intention to work well with others. People don’t just pretend to want their other team members to succeed. They actually do want them to succeed. When this happens, the overall productivity of the team can skyrocket.
3. Ability to Learn
“I know kung fu.” – Neo
I love how everyone in the Matrix can learn whatever they need to on the fly in a matter of seconds through a program that uploads the information directly into their brain. Totally cool. Whenever they encounter a situation that requires some new skill, they just tell the operator and then two seconds later…BAM! Neo needs to learn how to fight and after one sweet, 10 minute training session with Morpheus he is suddenly a martial arts expert. Trinity needs to know how to fly a helicopter and a couple of seconds later she knows how to fly a helicopter.
If only software developers had a way of doing the same thing in the real world, things would be a lot easier. The need to learn new things is just as strong in this world as it is in the Matrix. It is just that actually learning takes a little more time and effort. Highly effective developers usually display the following two characteristics:
- Desire to Learn – The developer understands that the skills and knowledge he or she has is only valuable insofar as they help achieve the desired goals. Therefore, whenever the situation requires learning a new skill in order to achieve a certain goal, the effective developer doesn’t think twice about diving right in and figuring out what is needed to properly equip himself or herself.
- Ability to Learn Quickly – There are no expectations that developers learn as quickly as Neo, but the faster a developer can pick up a new technology or learn a new system, the better. It is a skill unto itself to be able to learn quickly. The specifics of how this can be done differ from person to person depending on their how their brain is wired, but at a high level, it generally involves grasping the overall concept very quickly and then being able to filter out the important information from the less important information.
There is very little chance that new developers will know everything when they start a new job. Newbies will most likely have a learning curve as they get up to speed on the business and technical environment. Existing developers must also constantly work to keep up with the business and IT due to the fact that they inevitably change and grow over time. The ability to learn, therefore, is more valuable than any single technical skill on a developer’s resume and it is an essential characteristic of highly effective developers.
Passion is what drives all of us with what we do and is critical to the success of a developer. If you don’t love what you do, there is no way you are going to sit at a computer and write code for 12 hours a day. I love what I do (some would say borderline obsessed) and every single highly effective developer I have met has had a similar passion for designing systems, writing code and thinking about technology in general.
For employers, highly effective developers are very difficult to find. For developers, becoming a highly effective developer can be extremely challenging. In either case, a focus on these 4 characteristics can help a great deal. Employers should attempt to test for them during interviews as well as integrate them into the team goals. On the developer side, the more someone is able to show accountability, act as a team player, learn new information quickly and have true passion, the more effective he or she will be which should ultimately translate into various benefits, rewards and recognition.