This chain of thought then prompted me to ask myself this same question. What do I find most disturbing when reviewing code? My instinctive reaction was to answer "defects", but upon a little reflection I realized this was not true - I expect to find defects as a fundamental principle of quality. So it usually does not bother me to find a few during a review.

There are times when I am very disappointed when reviewing code - what am I finding at those times? Here are some specific occurrences:

• Code riddled with defects reflecting a fundamental lack of understanding about the requirements.
• Code very difficult to understand due to poor names and overly complicated logic that seemed repetitive or unnecessary.
• A large amount of non-GUI code written without any supporting tests.
• Code with inconsistent formatting and style.

What is the common theme here? After further reflection, I realized that the common element underlying these situations that I find most disturbing is a lack of professionalism / craftsmanship. This can manifest in a number of ways as indicated by the above list. The key criteria is whether a developer is helping achieve or is hindering our mission as software developers, based on what they produce for code. My evaluation of what is most disturbing is at its essence based on my core values and beliefs concerning software development.

Role-Based Attitudes

I will first answer this question on a role by role basis, starting with the role of tester. Since one of the primary objectives and professional skills of testers is to find defects, I would expect them to generally be happy when they find problems. The more significant (e.g. critical) the defect or more tricky to find, the happier I would expect them to be. If the defects are trivially easy to find, or are so serious that they prevent further testing, then I could see testers getting upset because they are prevented from exercising their craft to the fullest level of their capabilities.

What about developers? When developers find defects in other people's code, perhaps via a code review, this is fairly similar to the tester role above so I would expect developers should generally be happy in this scenario.

When a developer finds a defect in their own code as part of the development process - e.g. by having an automated test that unexpected fails after a code change then how should they feel? It is only natural to feel some disappointment at having made a mistake, but I do not believe this is the best reaction. In fact, it may be harmful. If you experience mild distress or pain whenever you find your own defects, you may subconsciously start to try to avoid the pain by, for example, doing less testing. So I believe a better reaction is to be happy when you find your own defects. This may seem challenging to do, but consider these rationale:

• Finding the defect validates your skill at performing whatever defect detection activity you were doing - whether it was automated testing or personal code review - and reinforces the value of performing that activity.
• Discovering this defect provides a learning opportunity on how you might better prevent or detect this type of defect in the future. Learning opportunities are good.
• As a professional, you want to pass along high quality code. Every defect you find in your own code is one less defect others will find, thus raising the quality of your final output.

The final scenario to consider is when someone else finds defects in the developer's code. A typical example is when the developer considers a feature finished and a tester is testing it. Now this must be bad, right? Even more than the prior scenario it seems natural to feel disappointment. Each defect that is discovered is essentially downgrading the quality of what you have produced. However, some of the reasons we listed previously for feeling positive still apply. In particular if the defect was still found within the team rather than being passed along to the end user or client, then this is a good thing. It can be hard to see this as a developer when it is your code at fault.

So let us consider the final role: that of the team lead or manager who is supervising activity rather than specifically doing coding or testing. This role has no personal stake in individual defects, but instead is typically concerned about the broader implications to the project or product. Assuming that high quality is a key objective, how should such individuals feel about defects? One tendency is to react negatively because of the extra effort and schedule time required to fix defects. Finding too many defects can also lead to alarm bells over the level of quality. I feel that since the team lead or manager essentially represents the whole team, their reaction should correspond to the perspective of the entire team.

Team-Based Attitudes

So what should the attitude of the team as a whole be to discovering defects? To properly answer this question we need to know what the team's objective is. I am going to assume it is to build working software that is being used and meeting users' needs. The existence of defects is clearly bad since they threaten this objective. But what about the discovery of defects? Discovering a defect means the team gains more information about the state of the software which it will typically use to improve the software by fixing the defect, and which the team can also use as feedback to improve.

Discovered defects exist prior to being found, but the team does not know about them until the time of discovery. This means that the team should experience simultaneous conflicting reactions: happy that the defect was discovered, yet unhappy that the defect exists.

Individual Attitudes

So what should the attitude of the various individuals on a team be towards defects? Should it be based on their role? I believe that in an ideal team every individual will understand and adopt the common objectives of the team. This means that everyone's attitude towards defects should ideally be the same, no matter what the role.

As I have observed, in practice attitudes tend to be quite far from this ideal state. People maintain their own personal objectives and viewpoint in addition to or instead of the team's. Often they do not appreciate the distinction between discovering defects and the existence of defects. To correct this I believe team members need to be clear on the team's objectives and understand how the existence and discovery of defects impacts these objectives. I hope this article will help in that regard.

The ability to work independently and the amount of assistance provided to others both correlate negatively with task difficulty and correlate positively with the level of contribution to the team. This similarity of relationship allows us to combine both the independence and assistance measures into what I call "net team contribution". Similar in concept to a financial balance sheet, net team contribution is calculated as contribution assets - personal achievements and the help provided to others - minus contribution liabilities – the help that others had to provide.

I explained in my prior article that there are two thresholds of task difficulty: the level of difficulty at which you start to require assistance, and the level of difficulty at which the task is so excessively difficult for you that it is completely beyond your capabilities. Relating these thresholds to net team contribution results in four zones of contribution. The graph below provides a visual representation showing net team contribution as a function of task difficulty.

The four contribution zones are as follows:

1. Provide Assistance Zone: The task is easy for you to complete. You can easily see the way through obstacles faced by others and can effectively help them with their issues. Working primarily on such tasks yourself probably is not the best use of your time.
2. Independent Work Zone: the task is just easy enough that you can work on it independently with minimal assistance, but it is still somewhat challenging.
3. Help Required Zone: the task is difficult for you and you require some assistance to complete it. This zone starts at the first threshold of difficulty of requiring assistance.
4. Negative Contribution Zone: the task is very difficult for you. You require so much assistance from others on the task that they are essentially doing it for you. It is more cost-effective for others to simply complete the task themselves. This zone starts before reaching the second threshold of excessive difficulty.

Understanding these contribution zones and the underlying relationship between contribution and difficulty is helpful in ensuring a team is running smoothly. Is someone who has previously worked largely independently now struggling with a task? It is probably beyond their threshold of ease, so be sure to provide some assistance. If a developer is completely stuck and at a loss for how to proceed, the task may be completely beyond their abilities, in which case reassign it. When looking at the set of tasks to be tackled by the team within a single iteration, ensure there is a balance of complexity. Too few complex tasks leaves the more capable members under-utilized. Too many complex tasks is especially dangerous: it will result in the more capable members being too burdened by tasks near their level of ability to effectively provide the assistance required by the more junior members, while the juniors will be largely unable to make effective progress due to the complexity.

Defining Capability

As I researched and reflected on this topic, I came to realize that the central core of the problem consisted of defining what capability means for software developers. Wiktionary defines capability as "the power or ability to generate an outcome". What is the desired outcome for developers?

The first answer that came to mind for me was "creating high-quality software", but on further reflection I realized this was too limited. Developers work as part of a team on a project to develop a piece of software. (I believe this is generally true if you include teams of one person - the developer working by themselves - and include extremely informal projects such as open source software development efforts with no explicitly-defined objectives, scope, budget, or end date.) It is the team outcome based on the project success criteria that matters. Based on the lean philosophy of optimizing the whole system instead of individual components, we need to consider the developer's contribution to the team / project rather than just their efforts in isolation. So how about defining the desired outcome as contributing to the success of the team and project? The problem now is that this is too general. It applies to every role on the team and does not differentiate how a developer contributes versus a tester, business analyst, or architect. The solution is to merge in my initial answer of "creating software" while considering the team context. Developers who mentor other developers and do code reviews are not directly creating software but are still make significant contributions to the team’s ability to create software.

My definition of capability for software developers therefore is the ability to contribute to the success of the team and project through creating software and helping other developers create software.

Evaluating Capability

This definition serves as a good starting point conceptually, but it is not enough on its own to provide clear guidance on how to evaluate developers. I did not want a long list of detailed criteria to use for an evaluation – just a few simple measures that logically derive from the definition.

The first measure is the ability to work independently to produce software. Independently means with a minimum of extra assistance. It does not mean working separated from the team. For example, I believe that all production code should be reviewed by a second developer. Having code reviewed does not affect the measure of working independently. In contrast, having poor quality code that the reviewer has to spend extra time reviewing and re-reviewing after fixes would reflect negatively on the measure.

One way of evaluating this is to determine how much support the developer needs from other team member in terms of the various team roles. Does the developer understand the business priorities and stay focused on the tasks for the most important functionality, or does the team lead or project manager need to spend extra time monitoring this and providing guidance? Can the developer create a functional design for a set of requirements that also meets all the non-functional requirements, or do they need significant help from the architect? Can they trouble-shoot problems, or do they need help from other developers?

The second measure is the magnitude (size/scope) and degree of complexity or difficulty of the work that can be easily performed independently. How hard or complex a task can the developer tackle without getting bogged down or stuck? Can they only handle small, clearly-defined tasks, or can they work on complex algorithms and large modules of an application with ease? This measure may seem similar to the first – both relate to working independently – but it is distinct. I think of this measure as assessing solely a developer's technical ability, while the first measure is broader. Most developers have two thresholds of complexity/magnitude: the first is the point when they need assistance to complete the work, and the second is the point when the task is completely beyond their capabilities.

The third measure is the level of quality of the developer's work. Quality is more than just a low defect count. Quality includes meeting non-functional requirements such as usability, maintainability, and performance in addition to functional correctness. Quality is also not limited solely to the software produced by the developer. Quality should be assessed for all a developer's work including activities like reviewing code, estimating tasks, and writing documentation. I like to use the term craftsmanship to describe this broad definition of quality. Others might prefer the term 'professionalism'. The reason I use the term 'quality' is because in my experience people hold widely varying definitions of the other terms, while definitions of 'quality' tend to be more similar. So asking people to assess developers in terms of quality has proven more useful than using these other, vaguer terms.

The fourth, and last, measure is the amount of assistance the developer provides to the rest of the team. Do they mentor more junior developers? Do they help diagnose a tricky defect? Do they provide advice on using some library? This measure is really assessing two different aspects: the first is the developer's willingness to help, and the second is the developer's ability to help. This second aspect is closely related to the first and second measures. A developer's overall level of ability with respect to the task determines whether they will need assistance, barely get by on their own, or easily do their work and have the capacity to provide assistance to others.

Summary

Capability for software developers is the ability to contribute to the success of the team and project through creating software and helping other developers create software. Use the following four questions to assess a developer’s capability:

1. How well do they work independently without requiring the assistance of others?
2. How difficult a task in terms of complexity or scope can they handle easily?
3. What level of quality is their work at?
4. How much assistance do they provide to the rest of the team?

You might argue that the answer to this question depends on the criticality of the software you are producing. Software like the control software for the space shuttle or software to control medical devices is literally life-critical: if the software fails, people can die. The majority of software, however, is far less critical. Business software, in particular, is often financially-critical (failure of the software leads to loss of money) rather than life-critical. So let me ask a related question. Would your trust your financial assets to your code? How much would you wager that your code is correct?

This question might still make you uncomfortable. If you are at all experienced as a software developer, I expect you know that everyone, no matter how experienced, introduces defects in the code they write. What matters in terms of correctness is the code that is shipped or released into production, and the quality level of this code depends on your team's overall software development process, not just your personal efforts. So the question could be applied instead to your team: would you trust your life or your financial assets to the software you deploy into production. (If you are working on the online banking / investment software that I use, I hope you do trust your personal assets to the software you write :)

Notwithstanding the efforts of your team, you personally need to be confident in the correctness of your code before you pass it on to others to review or test. Passing on code that you are not confident in is in essence passing on code that you suspect is wrong. Can you do this and call yourself a professional software developer? This is why I feel it is important to understand and be able to justify the correctness of every line of code you write. You ideally should be 100% sure that it is correct.

In the engineering profession engineers are legally required to stamp and sign the final version of engineering blueprints, documents and reports as a professional guarantee that they are correct. The signing engineer is held personally responsible for failure: in serious cases engineers have received large fines and have had their professional status suspended or even terminated. The same legal strictures are not enforced for most software development, but if you want to call yourself a professional software developer you should feel that same sense of professional responsibility for the code you produce.

Even if the software you write is not life-critical, code is often reused, copied, or adapted. You just do not know where your code might end up. It is possible (although most probably very unlikely) that someone's life – maybe even your own – may end up depending on your code.

Would you trust your life to your code?

• My Vision for IT
• Our Mission as Software Developers
• Becoming a Champion of Continuous Improvement

I recently drafted new vision and mission statements for the professional side of my life. While these statements significantly reuse my past efforts, I have also incorporated different elements that reflect new understandings or shifts in my thinking. This recent process has emphasized for me that I will never have a "final" vision or mission - these statements need to evolve (continuously improve :) to continue to reflect who I am and want to be. More mundanely, I am not satisfied with the current form of the statements: I think they can be made more concise and fluid. Writing these statements feels more like writing poetry than writing prose, and I am not a poet.

I have never clearly understood the difference between vision and mission statements. Years of reading bland, uninspiring corporate statements has probably not helped. I originally was planning to only draft a mission statement, but I discovered as I proceeded that I had two versions: one more concise but abstract, and the other more specific, containing phrases important to me that did not fit into the first version. Both statements resonated with me, so the former became my vision statement and the latter my mission statement. As a result, my mission statement is an expansion of my vision statement that makes it more concrete and more actionable. I may not have followed the textbook definition of vision and mission statements, but that does not matter. What is important is that these statements are meaningful to me.

Without further ado, here are my new vision and mission statements.

My professional vision is to:

Create great software that makes a difference.
Pursue mastery in the field of software development.
Inspire others to do the same.

My professional mission is to:

Create and inspire others to create
working software that is being used and meeting users' needs
through the disciplined application
of effective software development practices
and to continuously improve and grow in my ability to do this.

This point was brought to my attention again a few weeks ago when I read the article 100 Interview Questions for Software Developers by Jurgen. I liked the article and have used some of the questions, but it got me thinking that software developers and other I.T. professionals deserve to have the same resource – interview questions to ask of employers. So below I list 100 questions you should look for answers to during the interview process. Some of the questions are specifically for software developers, but many are more broadly applicable to any professional knowledge-worker position.

Warning: Do not simply ask the interviewers these 100 questions in the first interview! Your first priority in an interview process is to convince the interviewers to hire you by selling yourself. The important but secondary priority is to determine that the company is a good fit. It does not matter how good a fit the company is if they will not hire you. (This reminds me of all the blog posts from people who interviewed for Google but did not get in.) So wait until the company is at least seriously interested, and better yet has extended an offer, before doing your due diligence and asking these questions. I would not recommend asking all of these questions directly of the interviewers, especially those from the human resources department, as they likely do not know what the specific working conditions are like and may sugar-coat the facts. I recommend instead talking directly to a few regular employees, preferably in a neutral setting outside of the office.

Without further ado here are the questions organized into categories.

Organization

1. What drives the organization? What do senior executives value? What is important to them?
2. What are the core values that make up the organization's culture? Has this been consistently supported by senior executives?
3. Is the organization financially strong and stable? Please provide your annual financial reports for the last three years. (This is available on-line for publicly-traded companies.)
4. What are the significant strengths, weaknesses, opportunities, and threats facing the organization over the next few years? What are the organization's strategic goals?
5. How does the department / team I will be joining relate to the overall organization? How does it support the organization's strategic goals? Is the department a cost or profit center? How is the department perceived politically?

Management

6. How often will my immediate supervisor meet with me one on one?
7. What is the management style of my immediate supervisor and their superior?
8. How do you deal with poorly performing employees?
9. What is your strategy for empowering employees?
10. How do you ensure you are delegating effectively rather than micro-managing?
11. How do you help ensure that employees are highly motivated?
12. How do you ensure that each employee is doing quality work?
13. How does management ensure that employees feel listened to?
14. How do you enhance the creativity of developers?
15. How approachable and receptive is management to suggestions and feedback?
16. How do you minimize interruptions for developers?
17. Do you treat people with respect and integrity? Provide an example.
18. How important is productivity of software developers to the organization? What do you do to maximize productivity?
19. Do you put as much if not more effort into retaining employees as you do recruiting? What is your retention strategy?
20. How do you promote a healthy work-life balance?
21. What metrics do you track and report on? Provide a report showing data from the last few months.

Teams

22. How are teams assembled? How are team members selected? What are the selection criteria?
23. How often will the team I am in meet as a group?
24. What do you expect will be my role on the team?
25. What are the experience levels (i.e. junior, intermediate, senior) and job roles of the other team members?
26. What is involved in moving to another team or changing work assignments?
27. Do teams have a sufficient diversity of skill beyond simply coding? What about ability in gathering requirements, architecture, usability design and testing, database design and administration, functional testing, and technical writing?
28. What types of team-building activities are done? How frequently?
29. Are teams empowered and self-organizing? Are teams able to choose and tailor a methodology to suit them and their work?
30. How much freedom and support is provided to mentor and consult with colleagues, superiors, and customers?
31. Describe the clients, customers and end users I will be working with or for. How reasonable and pleasant are they?

Work Assignments

32. What kind of work assignments will I be given? What will be my day-to-day responsibilities?
33. What opportunities will there be to work with new, interesting technologies?
34. How do you plan to provide me with challenging work that makes optimal use of my abilities while providing a supportive environment?
35. Are developers required to do administrative or non-value-add tasks that could be done more cost effectively by others?

Work Environment

36. Will I be situated in an office with a door?
37. Is the work environment quiet with no distracting noises like intercoms, call center staff, ventilation systems, or traffic?
38. Are living, green plants in abundance in the office?
39. Are high quality chairs provided?
40. Is the office setting (chair, desk, keyboard, and monitor) ergonomically friendly? Can I adjust the height of everything to fit my needs?
41. Do you supply at least two large monitors as a standard configuration for software developers?
42. Are software developers provided with high-powered workstations? How often are they upgraded?
43. Does the office setting support collaboration with coworkers? This includes at least one extra chair, the ability for two people to sit in front of the computer (i.e. pair programming), and a white board fixed onto a stable surface with room for at least three people to stand in front of it.
44. Will I be provided with an ergonomic keyboard and mouse to my specifications? Or can I purchase my own and expense it with no questions asked?
45. Will I have the freedom to install the tools I want on my workstation?
46. What is the process and lead time to get a new tool, workstation, or server purchased and installed? How much bureaucracy and delay is involved?

Project Management

47. Do projects have realistic schedules, resources, and scope that are actively managed and adjusted? How much freedom and control does the project manager / team have to change these three factors?
48. How do you deal with a project that is behind schedule?
49. How do you manage requests to change the scope or requirements of a project?
50. What tools and practices are used to manage project schedules?
51. Who estimates the time or effort required to do development work?
52. How is the expenditure of effort tracked? What tools are used for time entry and tracking progress?
53. What is the duration of iterations and releases?

Development Practices

54. What development methodologies do you use? Describe how they are put into practice.
55. How closely does development activities align with the philosophy & principles of Agile and Lean?
56. What languages, libraries, and frameworks are commonly used or mandated?
57. What developer tools (especially IDE) are provided or mandated?

What do you do for:

58. Version Control?
59. Unit Testing?
60. Code Reviews?
61. System & Integration Testing?
62. Client / Customer / End User Collaboration?
63. Requirements / Design Specifications?
64. Design Reviews?
65. Defect Tracking?
66. Build Automation?
67. Continuous Integration?
68. Usability Testing?

Continuous Improvement

69. What continuous improvement activities are performed on a regular basis?
70. How often are retrospectives / lessons learned meetings held?
71. How aggressively do you minimize bureaucracy and non-value-add activities? Can you provide an example of improving in this regard in the last six months?
72. What is your process for handling suggestions and ideas from employees? How many suggestions per employee on average were received in the last year? How many were acted on?

Professional Development

73. Do you provide opportunities for developers to receive feedback and learn from having their software running in production?
74. What opportunities will I get to work with or mentor under expert world class software developers, architects, and managers?
75. How much paid training do you provide to each employee per year? What kind of training is it? Can employees choose or recommend the training they take?

Performance Evaluation

76. What kinds of opportunities for growth and advancement are possible? Describe the options for technical career paths that do not involve management.
77. How do you make decisions regarding promotions?
78. What approach is used for providing timely, effective feedback on performance? How are performance evaluations carried out?
79. What do you look for in an ideal employee?

Working Hours

80. What are the official number of hours worked per week?
81. How many hours per week on average have your software developers worked over the last three months?
82. Do you allow or expect mandatory overtime? What do you consider an unacceptable amount of overtime (both mandatory and voluntary)?
83. Do you provide flexible working hours? What limits are there?

Compensation and Benefits

84. Do you provide a competitive salary? What is your definition of competitive?
85. How do you ensure that the salary of long-term employees stays competitive, especially in a hot job market? Do you respect your long-term employees enough to raise their salaries in such situations without waiting for them to ask for raises?
86. How do you compensate for overtime?
87. Do you pay your software developers according to their level of productivity? Why or why not?
88. How many weeks per year of vacation do you offer?
89. How flexible are you concerning how banked vacation can be used? Can it be saved from year to year? Are there any restrictions on taking vacation?
90. What is your policy concerning raises? How regularly do you give raises? Do you consider a yearly increase in salary equal to the local inflation rate to be a raise?
91. How do you reward exceptional performance? What do you consider exceptional performance and how do you identify it?
92. Do you provide share options, profit sharing, retirement savings contributions, or pension? If so, what are the details of the plan(s)?
93. What medical benefits do you provide? Do you cover dental work or eyeglasses? Do you cover health preventative measures such as exercise programs, vitamins, or preventative medical exams?
94. What is your policy regarding sick days?
95. Do you allow and support people in working from home? Up to what percentage of the time?
96. Will travel be expected? If so, how frequently, for how long, to where? What is the policy on travel expenses?
97. What other benefits or perks do you provide?

Contribution to Community

98. How do you participate in and contribute to the local and global I.T. / software development community?
99. What open source software do you support? What form does this support take?

Wrap-up Questions

100. Who are you competing with locally for recruiting software developers? Who are you losing developers to?
101. Bonus Question: Please provide three references consisting of employees I can talk to. The references should include a senior software developer and a technical lead.

The vast majority of Internet resources for job interviews focus on questions to ask employees, but I did find a few relevant articles that were helpful in producing this list of questions:

• The Joel Test from Joel On Software
• C2's Developer's Bill of Rights
• Jeff Atwood's Programmer's Bill of Rights
• http://www.career.vt.edu/Jobsearc/interview/AskQues.htm
• http://www.pohly.com/interview-2.html

Working Software

Being Used

Meeting Users' Needs

This statement is deliberately formatted into three lines. Each line holds a specific meaning for me.

Working Software

This is fundamentally what software development is about. The software we produce needs to work. You may think this is too obvious a point. Over the last few years, however, I have witnessed (but fortunately never been part of) several software development projects that ended in failure because the software simply did not work – typically due to too many defects or performance issues.

It is no coincidence that one of the values of the Agile Manifesto is "Working Software over Comprehensive Documentation". I purposely chose the phrase "Working Software" in reference to this value. Some of the failed projects I witnessed had hundreds of pages of carefully written, reviewed, and signed-off documentation. But these documents become essentially worthless because the software did not work.

The mission to produce working software should motivate us both to produce quality code and to continually develop our abilities as software developers to improve in our ability to deliver working software. If this does not resonate with you, then I think you should carefully examine whether software development is the right career for you.

I find it very rewarding to finish a section of code, see the green JUnit bar or the user interface, and know that the software works. While this is a necessary first step – the foundation of what we do – there is much more to my mission. Once software works, the next step for it is...

Being Used

I mentioned above that application documentation for software that does not work is essentially worthless. Similarly, working software that is not being used has basically no value. You may disagree with this statement so I will offer another viewpoint: software that is being used is producing value. Unused software is not providing value, although it may have the potential to do so.

Why do I care about producing value? When I use the term "value" I do not mean financial benefit or revenue. In this context I define value to mean providing or being of benefit to people – contributing to their well-being.

Some developers may be satisfied with just producing working software even if it is not used. If given the choice, however, I think most developers would prefer to see their software being used – not just by themselves but by others. I personally derive an immense amount of satisfaction from seeing software I produced being used by actual users. My mission, therefore, is not just to produce working software but to ensure it ends up being used.

Having software be used is no guarantee that it is providing the maximum value possible to others, especially for enterprise software that users often have no choice about using. In order to maximize value, software must not only be used but must be...

Meeting Users' Needs

How often have you used software that has repeatedly annoyed or upset you? Perhaps it has an illogical user interface or performs poorly. Perhaps it does not quite do what you need it to. You might use the software and get your task done, but it was not a pleasant or easy experience. How rewarding is it as a software developer to have your software being used but it causing the users to suffer?

To prevent this we must ensure that the software meets the needs of the users. What are the users really trying to accomplish with the software? I explicitly used the word "need" instead of "want". Users are typically quick to list "wants" that are not true needs. Delivering "wants" typically results in either unused software or unsatisfied users. Needs go deeper, ideally tapping into the mission that the users are seeking to accomplish with the software.

The Process of Creation

I went through many revisions of my mission statement before settling on the version presented in this article. I want to discuss some of the process and reasoning behind my mission to help you create your own.

Early in the process I arrived at the three phrase format with the progression between phases. This appealed to me on several levels. I liked the poetic style based loosely on Haiku. I am not into poetry normally, but expressing my mission in such a style represents the expression of my creative side, and not just my logical side, in the development of software. The progression between phases reminded me of Maslow's hierarchy of needs, with working software representing a survival need and the other phases loosely corresponding to esteem and self-actualization needs.

My first version using the three phase format was biased strongly towards enterprise software development, which I specialize in. This first version was: "Working Software, In Production, Meeting Business Needs". The two phrases "Working Software, In Production" are especially appropriate for enterprise maintenance teams since it also speaks to the necessity of keeping the software operational and incident-free in the production environment.

As I evolved this statement into a more general form, I struggled with the phrases "Being Used" and "Meeting Users' Needs". I worried initially that the "Being Used" phrase was redundant and could be eliminated. Further reflection, though, made me realize that the phrase "Meeting Users' Needs" is a little ambiguous on its own: is it referring only to writing software that meets users' needs, or is it referring to users using the software and having it meet their needs? I mean the latter, but it is all too easy as software developers to focus on just writing the software. Thus the importance of the phrase "Being Used" in explicitly stating that the software must be released and make its way into the hands of users. This is especially relevant in an enterprise environment with many hurdles to getting software into active use.

There are two points I tried to fit into my statement but ended up leaving out. The first was the notion of quality. I wanted to express the idea of taking pride as professionals in producing quality software. I did not want to use the word "quality" directly, however, due to its potential association with quality assurance and related aspects such as certifications and formal processes that I did not want reflected in my statement. Perhaps the simplest definition of quality is "fitness for use", and I feel that all three phrases of my mission link nicely into this definition.

The second point I wanted to bring into my statement was the ideal that software should delight users. "Meeting Users' Needs" taken to the highest level should delight users, but this seems like a bit of a stretch. One option I considered but rejected was to change the third phrase to be "Delighting Users".

Conclusion

My ultimate goal as a software developer is to make a positive contribution in the lives of others by helping them achieve their goals through the software I create. My mission represents the steps involved in achieving this goal:

Working Software

Being Used

Meeting Users' Needs

I recent read the book First, Break All The Rules: What The Worlds Greatest Managers Do Differently which provides some great insights into this question. The book's content is based on in-depth interviews of over 80,000 managers that sought to determine what the top-performing managers across different industries and companies do differently than the majority. One point that was not surprising is that the greatest managers focus on achieving excellence within their teams - they are not content with merely average performance. But the strategies that these managers use in the pursuit of excellence do differ from what conventional wisdom suggests.

Excellence is not achieved by studying and avoiding failure

"Conventional wisdom asserts that good is the opposite of bad, that if you want to understand excellence, you should investigate failure and then invert it. ... Managers are far more articulate about service failure than they are about service success, and many still define excellence as 'zero defects'." (page 102. All quotes from "First, Break All the Rules")

"You cannot learn very much about excellence from studying failure. Of all the infinite number of ways to perform a certain task, most of them are wrong. There are only a few right ways. Unfortuntely, you don't come any closer to identifying those right ways by eliminating the wrong ways. Excellence is not the opposite of failure. It is just different. It has its own configuration, which sometimes includes behaviors that look surprisingly similar to the behaviors of your strugglers." (page 157)

Studying defect-ridden code may help you recognize design and coding approaches that cause defects, but this provides limited benefit if any in teaching you how to produce solid code. Furthermore, achieving zero defects in your code or in your software product is not a sufficient condition for excellence. Preventing and eliminating defects is important, and learning how to do so will make you a better developer. But there is much more to developing great software than correctly-behaving code: Is the code understandable? Easy to extend and alter? Easy to install or promote to production? Easy to diagnose problems in? Easy for users to use? Does it do what the users want and need it to? Looking at poor-quality or even average code will seldom reveal how to produce great software that can answer all these questions in the affirmative.

Learn excellence by studying the best

"The best way to investigate excellence is simply to spend a great deal of time with your top performers." (page 159) This statement is targetted at managers, who need to determine what factors contribute to excellence in order to be able to promote and recruit it. But the concept is equally applicable to software developers with no supervisory responsibility. In order for you as a developer to grow towards excellence, you need exposure to it. Studying great software developers and great software is one way of gaining that exposure.

If you are inexperienced, you face a chicken-and-egg problem of needing to first identify greatness in order to learn from it. I recommend starting with widely-recognized sources such as books, blogs of well-known developers and consultants, training courses, conferences, and open-source software as a source of code to study. You can also try to find one or more experienced developers within your organization to act as a mentor. The quality of such resources will vary, but over time as you learn and gain experience you will be able to better identify excellence.

The difficult part of this process is that mere exposure to excellence is not enough. You must reflect on what you are seeing in order to extract those crucial insights into the nature of excellence, and determine how you can apply them. One example of this from my own experience is from a number of years ago when I was trying to better understand how top developers do design and coding. I picked up the book Refactoring: Improving the Design of Existing Code in order to learn about refactoring, but while reading it gained some important insights into how the author approaches design. In fact, I found that to be the most valuable aspect of the book.

Another example is from a presentation I heard from Bob Beck, one of the core set of developers for the OpenBSD operating system. OpenBSD is best known for its focus on security, and I was able to gain some insights into the processes used by the core developers to achieve this. One key process is their regular use of code audits across the entire code base which are triggered when a defect or potential security hole is found somewhere in the code due to a bad coding construct (such as incorrect use of a C library function). The construct is first identified by root cause analysis of the problem, and then the entire code base is inspected to eliminate any other occurrences. More details on this process are available at http://www.openbsd.org/security.html.

Excellence takes talent

"Skills, knowledge, and talents are distinct elements of a person's performance. The distinction among the three is that skills and knowledge can easily be taught [or learned], whereas talents cannot. ... Skills are the how-to's of a role. ... Your knowledge is simply 'what you are aware of'. There are two kinds of knowledge: factual knowledge - things you know; and experiential knowledge - understandings you have picked up along the way." (page 83)

"Talents are different phenomena altogether. Talents are the four-lane highways in your mind, those that carve your recurring patterns of thought, feeling, or behavior." (page 84)

People can achieve average performance without talent, but true excellence requires talent. Talent is not, however, a binary have-it-or-not phenomena. There are a multitude of talents, and different roles require a different mix of them. One of the key points I took from the book is that everyone is talented - everyone has a particular mix of talents - and great managers excel at putting their people into the role best suited for their talents.

Even within software development, there are a number of roles requiring different talents. Or another way to look at it is that people have different talents which require different roles. One person may like to have their work clearly defined and prefer to start with a clear requirements or design specification. Another person might be careful and methodical, making them well-suited for doing code reviews or testing. Another person might be visual in nature and like designing or creating user interfaces or web sites.

The key for each of us is to identify our talents and make sure that the roles we take on fit with those talents. One way to determine this is to recognize when you are working on tasks that are a struggle, or are painful, or are de-motivating for you to do. These are potential signs that this type of work does not mesh with your talents.

Excellence takes experience

Across "diverse professions, it takes between ten and eighteen years before world-class competency is reached." (page 185). Even in someone with the perfect blend of talents, it takes time to amass the skills, factual knowledge, and most importantly experiential knowledge that are necessary for excelling at a role.

Many companies and even entire industries, however, pressure people to move up the organizational chart. Fancier titles, bigger perks, and probably most importantly larger salaries are all magnets attracting people up the corporate ladder. This not only prevents people from building sufficient experience for expertise in their original role, but also runs the risk of moving people out of a role for which they have the right talents, and moving them up into a role for which they are not talented. The net result: a formerly excellent employee becomes only an average or poor performer. This is a common problem in I.T., where star developers are promoted into team leads, project managers, or architects that require a significantly different set of talents, skills, and knowledge. I discussed this particular issue recently in my article To Code or Not To Code. This general problem has been identified a long time ago as the Peter Principle: people are promoted to their level of incompetence.

The book offers several suggestions at a corporate level for combating this promotion pressure. One idea is defining levels of achievement within a role - such as junior, intermediate, and senior software developer, so that promotions can happen without changing the nature of the role. A second idea is to offer wide, overlaping pay scales, so that an excellent senior developer, for example, would make significantly more than an in-experienced first-level manager.

Achieving Excellence

A summary of the steps for achieving excellence are as follows:

1. Find a role that matches your talents.
2. Develop your skills and knowledge for the role by studying the best.
3. Spend the years gaining the necessary experience.

I have been thinking about this general topic for a while, as reflected in two of my recent articles titled How Much Do You Code? and Are You Doing Enough Coding?. These articles have focused more on the amount of coding one does as a software developer, and point out that the more senior the developer, the less coding they tend to do. Rob's article, however, focuses on the separate (but related) issue of senior developers moving into non-development roles. I think there are three major forces pushing developers in this direction:

1. Promotion from management. The top performers within a team are often the most likely to be promoted to lead the team, even if they and the corporation are better off if they remain developers. This is especially a problem in hierarchical organizations with no technical career path.
2. Desire to fix problems. As Rob pointed out, you may feel obliged to take on a leadership role in order to help your team or save your project. A contributing factor is the oft-mistaken belief that the new role will not take all of your time and that you will still have time to code.
3. Desire for new challenges. If you are feeling stale in your current role then advancing into a more senior position is often the most obvious choice. It is not, however, always the best choice.

The correct answer to whether to continue to code or not depends entirely on you and your motivations. I recommend choosing the role that is most rewarding to you on a daily basis, and not choose a role based solely on its seniority, prestige, or salary level. Many developers end up unhappy in non-coding positions because they allowed external forces to push them away from coding. Unfortunately, it can be difficult to determine how much you will enjoy a role until you try it. And once you try a non-coding role, it can be difficult to move back to coding. This is when learning from the experiences of others can help. So here are some of mine.

I personally love coding – the act of creation, as Rob pointed out – and always have since I was young. I did my first coding as a kid on a Vic-20. So becoming a software developer was the obvious career for me. Early in my career I was offered and accepted the opportunity to become a team lead of a small team. I found that I could spend a little less than half my time coding. The other time was spent on administrative or project management activities. The exact percentage varied from week to week: there were some weeks with almost no coding, and other weeks with more. Even when I was involved with the code, a portion of this time was spent doing reviews and mentoring junior developers. The team size varied from three to seven subordinates. As the team grew, the less time I had to code. After a few years and the successful release of a new piece of software, I knew it was time for a change, partly to take on new challenges, and partly to do more coding.

I joined the architecture team within the same company and became involved in a project to build a new application framework. I was coding again full time together with some excellent experienced developers. Those were good times. Within six months, I was offered the architect team lead position, which I accepted partly because it had very limited administrative duties, so I was still able to devote a majority of my time to coding. I did become involved with some non-coding duties, such as a training initiative regarding the use of automated unit testing and mentoring, but I did not mind because I found both activities rewarding, though not without their frustrations. After a few years it was again time to move on.

I switched companies, joining CGI. I was going to be a development lead on a project, but CGI failed to win the bid. Instead, I joined a development project as a regular developer. I had no non-coding responsibilities, and the project was in the construction phase, so I got to do some of the most intensive coding of my career – probably 95% of my time. But like most development projects, it soon ended, and I moved onto a maintenance team as a senior developer. This was my first time in a pure maintenance role, and I discovered that there is definitely less time spent coding due to other responsibilities such as monitoring the operational production system and managing the process by which software changes were released into production. However, I found the role to be an incredible learning experience – check out some of my articles I have written as a result.

A few years later I was offered another team lead position. By this point in my career, however, I knew that I needed to code at least a certain percentage of my time. The offered position was for a fairly large team with many administrative duties, which I knew would offer no time at all for coding, so I turned the position down. Instead, my role in my existing team has gradually transformed into an architect role, partly out of a desire to fix problems, and partly out of a desire for new challenges. This has led to a reduction in the amount of coding I do. I still get to do some, and I am mostly enjoying the challenges associated with the new role. But I am being careful to avoid moving any higher up as an architect. As an application architect in my existing role, I am still fairly close to the code. I know other application architects who are no longer involved with code, and once you become an enterprise architect that is guaranteed.

There is nothing intrinsically wrong with becoming an architect, team lead, or manager, but there is nothing intrinsically right about it either. The choice of whether to code or not is best based on your motivations. What do you want to do?