Align your compass

Not often enough, I take a moment to look at my personal compass. From it I can adjust my heading and remain sure that I am doing the right thing. This is very much needed, especially when the wind is strong, or there is no land in sight (figuratively speaking). Recently, I came across an article written by Keith Self-Ballard that highlights the rules of success for a budding graphic artist. I feel that Keith presented a universal sense of rightness, and this inspired me to briefly discuss these three rules from a software developer's perspective:

Rule 1: Manage your ego. If you're like me, your ego could be the very thing that started you on this career. With pride I'd show off the cool stuff I created, and I'd make sure every one knows how quickly I get my work done. Bugs were my worst enemy. Wild horses could not keep me from proving that I had absolutely nothing to do with any bug. This ego thing was good. It motivated me to improve my skills and forced me to keep my eyes peeled for ugly gotchas that bite during testing. Unfortunately, the ego puppy grows up to be an ugly monster. Left unchecked, the big ego stifles your ability to grow and prevents you from reaching your potential. The developer with a small ego is always open to receive advice from others. He accepts responsibility for weaknesses in the software, and he is willing to adapt his own work (and his own ideas) for the greater good. It is definitely worth your while to become an ego-less developer. Don't worry: you'd still be writing good code, but it would be for much better reasons.

Rule 2: Communicate professionally. Bad communication is it the root of many problems; and it can litter your career with many failures. Always look for ways to improve your ability to communicate. A practical way forward, is to adapt your communication style to fit the audience.

• With peers, share knowledge. Dedicate yourself to share and learn from your peers during informal interactions and during formal reviews. When you find something valuable, such as a new development technique, a new feature in your tool set or a new development in your company, share this knowledge with others. Remember that you have a limited time with each individual, because people move on to other jobs. Thus, when the opportunity arises, strive to learn as much as you can from each of your peers.
  
• With supervisors, understand and recommend. As a developer, we face many types of supervisors. These come in many guises; architects, team leaders, development managers, and so on. With these people we share some responsibility, and they influence what we do and (sometimes) how we do it. Our primary aim must be to understand what is expected from us. Sadly, the world is not perfect - the reality is that situations arise where we strongly disagree with the supervisor. Instead of pointing out the (possibly obvious) problems with her idea, rather take some time to formulate an alternative course of action. Recommend this alternative to your supervisor as a well structured argument. Keep the interaction honest and respect your supervisor's view and also her decision.
  
• With non-developers, change your hat. When interacting with a person from another department, or with your customer, the aim is information exchange. This information is mostly related to expectations and priorities. You can contribute in these interactions by being acutely aware of the other person's point of view. For example, do not ask the marketing manager: "What columns should I add to the costumer table?". Rather, ask: "What information is needed to help you identify potential customers for the new product?". Also, when dishing out information, do not baffle others with technical jargon (this often happens unintentionally). In short: to improve the transfer of information, wear the hat of the other person.
  

Rule 3: Diversify. Sometimes, we think of ourselves as UI developers, or as database developers, or maybe as C# developers. We use these pigeon holes to identify with some development tasks more keenly than with others. Generally, there are tasks that fail to attract our interest or are deemed to be no challenge to our keen intellect. Firstly, we need to acknowledge that these tasks must in fact be done by someone. Then, when such a monkey lands on your back (believe me, it will), approach it with the same level of commitment you'd tackle an absolutely worthy task. Doing tasks outside your area of core strength is an ideal opportunity to diversify. You might surprise yourself, and there is no doubt that a more diverse developer is more valuable to a company. So, diversify to improve your career prospects.

That's it for this blog. In summary, to improve your chances for success mind these three tips: trim your ego, communicate well and diversify your tasks. Simple, isn't it?