The prevailing element cited by all those who participated within this series or provided suggestions for World’s Best Programmer was Respect. From UltraRob discussing the understanding of ‘why’…
February 26, 2009 at 1:02 pm
Most programmers are very self motivated. We like to solve problems and create cool things. Sure we sometimes need to be guided to focus on things that make business sense but if we’re given the information to see what is important that usually isn’t a problem.
From my perspective programmers don’t need much to be motivated but many managers don’t understand what it takes. For me it’s the little things that make me feel respected and take ownership. I don’t even have to agree with decisions as long as I understand why the decision was made and my view was heard. If I’m given those things, I’m pretty unstoppable.
…to Chris Geier’s nomination of Mike Scheider as World’s Best Programmer…
chrisgeier: @theproductguy Mike Schneider. Does the amazing in limited time, and is always looking to do it better. A great quality
…the one element, evident throughout the successful implementation of all of the previously discussed characteristics, as well as noted in almost all of the feedback received is Respect.
My answer is many fold and I provide a framework towards greater understanding in part 1.
The path to the motivated programmer, the happy programmer, is unique to each individual. There are, however, some general, instructional guides towards better understanding for all involved parties, and especially regarding those conditions that make for that highly motivated programmer.
Let’s take a deeper look at Respect.
If Communication is the glue that binds together the environment of the World’s Best Programmer, from Clarity to Inclusion, then Respect can logically be seen as the glue’s glue, the foundational element upon which the rest is built.
Without Respect between programmers, between programmers and managers, and any other relevant permutations of these, no one, not even the World’s Best Programmer, can thrive. The key characteristics described throughout this series…
… cannot be built upon without the most basic foundation of them all, Respect.
Respect, more importantly, MUTUAL Respect, a 2-way relationship, comes from all parties establishing and fostering mutual credibility and understanding. It is something that either exists or is lacking in the whole. If Respect is not mutual, then it can be truly said to be lacking. If Respect only flows in one direction, the effect on the individual on the receiving end is negligible since the source is not respected and, therefore, is not valued.
Sometimes easier to accomplish than others, most difficult if already lost, there are some examples that everyone, from programmer to manager, can learn from.
Micromanaging. Getting overly involved in a technical process for which you will not be directly creating, no matter the intention (e.g. "to help") is most frequently interpreted as a lack of trust, either of skills, and/or Respect, for co-worker space.
"So Easy." Don’t be the individual known for telling other programmers "Oh, that’s so easy." Programmers consider boundary cases, scaling, etc. which are not always "so easy." Just because a high-level business case is simple, its simplicity does not necessarily extend to the technical implementation. Exclaiming such simplicity often minimizes programmers’ skills, and, in turn, their Respect for individuals making these broad assumptions.
Corollary: Time. Make sure everyone has the time to do things properly. It, of course, goes to say that everyone is communicating about time constraints and other requirements associated with the "things to be done."
Explain. Don’t assume everyone is on the same page when it comes to methodologies and processes. Whether you are a programmer or a manager, explain and clarify the processes. For example, when projecting that a task will take X time, explain the ‘what’ and the ‘why’ behind the methods and logic of the projection.
Strength. Present strength with clarity. When working with other programmers, do not mislead them about the level of influence you have in the processes, or their change.
- Stand up against feature creep.
- Stand up for your programmers / co-workers / managers (from time to disruptions).
- Don’t promise what cannot be delivered.
The World’s Best Programmer may be sitting right next to you, maybe it’s you. Every programmer has that potential and it is up to everyone; programmer, manager, and organization to carefully craft and maintain the environment with the characteristics…
Clarity. Providing clear project requirements and goals.
Organization. Balancing the art and science, of programming, through structure.
Focus. Removing distractions and hurdles.
Communication. Promoting openness, free flow of ideas and information, and teamwork.
Inclusion. Empowering throughout all aspects, from idea origination to release and support, from business facing to backend, of the product processes.
Challenge. Fostering growth, new learning, and meaning.
Respect. Establishing and fostering mutual credibility and understanding.
Through careful thought and application of the characteristics discussed throughout this series you may soon become, meet, or be introduced to the World’s Best Programmer.
Subscribe now (click here) to make sure you don’t miss any part of this series highlighting many of the key driver’s of your team’s motivated programmers, nor other insightful posts from The Product Guy.
The Product Guy
|Add to Social Bookmarks:|