I am often asked what is it that I do that results in the programmers with whom I interact being so productive; what is it I do to get them motivated and to keep them motivated; and where can I find / who is the World’s Best Programmer.
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.
Today, let’s take a deeper look at Clarity.
An important condition in crafting an environment, within which the World’s Best Programmer can exist and thrive, is Clarity. Clarity is the act of providing programmers clear project requirements and goals. Elaborate upon objective, measurable project, and longer-term overarching, expectations. When deadlines are involved (as they typically are) convey them within the context of clear, reasonable, understandable timelines.
For example, instead of saying to a programmer …
“This program has to be scalable with little maintenance.”
… elaborate by saying something like …
“This application has to be able to handle up to 300 transactions per second per machine and can scale horizontally up to 20 machines. Maintenance can not take more than 1 hour of a system administrator’s time per day.”
Use consistent terminology. Maintaining this consistency can often be facilitated via a wiki, or other centralized knowledge repository, that people can access and update as new words are introduced and existing expressions evolve. Building upon the previous example, the word ‘machine’ should be a defined quantitative, such as…
“A computer with 512 GB RAM, Dual-core Intel Itanium 1.6Ghz, 1TB Raid 0+1, running RHEL 4.”
Another common example can be seen in the frequent use of words that imply an amount, coming in short of the necessary Clarity that a quantifiable value would provide.
“This application should always be available.”
… should elaborate upon ‘always.’ The manager providing this requirement to a programmer should consider and provide, to the programmer, insight into …
What does ‘always’ mean?
How long should the application take to recover?
What type of fallbacks should be in place?
Also, with word like ‘always,’ a wide range of solutions depending on its final elaboration that can lead to vastly different cost projections for building and/or maintenance of a project. Further Clarity can be imparted by providing guidance on the budget available, and / or the budgetary goals with respect to a task, when available.
Consistent Expectations = Improved Clarity
Within projects and tasks, make it a habit of having a goal(s) statement; walk the individuals involved in the task through an explanation of the goals. Leave no requirements implied.
Another great approach to providing Clarity, especially consistent Clarity, is working from project template documents with sections for goals, requirements, deliverables, tasks, work assignments, etc. (n.b. A template also reduces the chance of forgetting to clarify an important item/step.) Templates provide a sound foundation to build upon, enhancing and expanding a developer’s project and task Clarity, as everyone learns and adapts.
Short of these points, providing confusing, unclear, indecisive requirements with unrealistic, or artificial, timelines will only breed frustration, and worse, anger.
The Search Continues
In addition to…
… and before this individual, World’s Best Programmer, is announced, the characteristics…
… will be further explored and discussed in the subsequent articles of this multi-part series.
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 the denouement of World’s Best Programmer, as well as other insightful posts from The Product Guy.
The Product Guy
|Add to Social Bookmarks:|