Time

The first key is to make time to write. Ideally this should be a decent period of time each day during which you are undisturbed and at peak mental capacity.

The minimum period of time that I find effective is usually around 15 - 30 minutes. This is because it sometimes takes time to get into a good flow of writing. The maximum period of time that I find effective ranged from 45 minutes to 1.5 hours. This maximum is based on how well I can maintain my flow of writing and my motivation / discipline. If I get stuck, especially on a new section for which I do not have a clear outline, I tend to stop and let it percolate in the back of my mind. The longer the writing session goes, the more likely I am to run out of steam (motivation / discipline) - e.g. by getting distracted by email or my RSS reader. I find that practically this means that I am generally unable to continue writing for more than 1.5 hours.

So how do I find the time to write? I get up early each morning, before the rest of my family, and use the time to write. I sometimes write in the evening, but I find I often do not have the mental energy for this after a long day at work. So I tend to save the evenings for other activities, such as exercising, and dedicate the mornings to writing. Successfully doing this day after day takes motivation and discipline.

Motivation

The second aspect of my system is maintaining a high level of motivation. I have found that if I am not motivated to write regarding a particular topic or section then my progress is usually quite slow and I am easily distracted.

One way I keep my motivation high is extremely simple: I primarily choose topics that I am motivated to write about. When a new idea comes along, motivation to write about it is usually quite high initially and decays over time. So the ideal is to start writing about such ideas immediately. Other times I am wrestling with a topic at work or researching it on my own and gain some insights that I feel like sharing.

My motivation in these cases is linked to the goal of helping others learn and grow, which is part of my professional vision. In some cases, as I have started writing about an idea, I realized that I only had a sentence or two of meaningful content, which by my standards is not enough to share via an article. This typically rapidly deflates my motivation, and I move on to a different idea.

This concept of linking the act of writing to the achievement of a larger, more personally-meaningful goal is another valuable technique for boosting motivation. In the last year I have started to tackle some larger projects (which is one reason for the decrease in my posting frequency), and I find that having this linkage is extremely powerful in maintaining motivation over the long term. Having this motivation helps in dedicating the time to write.

Motivation is powerful, but it tends to fluctuate. When motivation fades, discipline is needed to maintain consistency of purpose.

Discipline

The final key to my system of writing is discipline - consistently applying deliberately-designed techniques and practices that help me write. Discipline has also helped me discover these methods through ongoing reflection and improvement on what is working versus what is not

A large part of discipline is consistency, which helps build up productive practices into positive habits. One example is my practice of getting up early each morning to write - I do this every morning, weekends as well as workdays.

I have found that there is an initial hurdle to overcome when sitting down to write, especially if I am struggling with a section. This difficulty often caused me to switch to email or the web as a distraction from which I tended not to emerge, resulting in me making no progress for that block of time. One practice I have developed to overcome this is to have a firm plan in mind the night before of what specifically I am going to write the next morning. As I get up in the morning, I immediately begin recalling my plan as a way to help prime my mind for action. Not only does this help me stay focused, but I also find it reduces the start-up time necessary to get into the flow, thus allowing me to be productive with even a short block of time.

Outlines are another practice I regularly use, even for short pieces of writing such as this article. These outlines are often quite informal, focusing on the main points I plan to write about. The purpose is not to identify all the content, or how it is organized - I often add more points that come to mind as I write, or restructure as the material comes together. Instead, I use outlines to help eliminate one of the causes of getting stuck - not knowing what content to write about. (It is still possible, unfortunately, to get stuck regarding how to write the content.) Outlines are also helpful in dividing the writing into sections: each section acts as a mini-milestone that I can aim to complete during a writing session, thus helping me remain motivated to write.

I have a technique for maintaining the flow while writing and minimizing distractions that involves the use of 'todo' labels. The general idea is that when I identify something to do or consider that falls outside my current focus, I document it with a 'todo' prefix. This keeps it preserved for later action, which helps to get it out of my mind now. Here are some common examples of how I employ this technique:

• When I want to link to an article on my website or elsewhere, I leave a 'todo'. Finding the link is often quite quick, but I do this to avoid distractions.
• When I have an idea for a piece of content for a future, unwritten section, I jot down a brief note with a 'todo' in that section, then return to what I was writing.
• When I get quite stuck on a particular paragraph or section, I leave a 'todo' comment and switch to another area. This is especially common when I have a long list of points outlined: I start writing the points for which I have the most motivation, leaving 'todo' flags on ones I skip. I then use the momentum I have built writing these more motivating points combined with the promise of almost being done them all to return to these few remaining points and grind them out.
• When I have an outline consisting of sections, like this article does, I start by writing down the section headings with 'todo' labels on each. This serves as a road-map for me to follow while writing. It also helps me see the overall structure of what I am writing.

This is my system for writing - it may not work for you. But I do suggest at least experimenting with some of these techniques and practices if you have not tried them before. I encourage you to leave a comment describing what practices or techniques you have found helpful.

The constraints need to push us out of our comfort zone. We need to bump up against the constraints, repeatedly, in order to generate those learning opportunities. The constraints cannot be so harsh, however, that they prevent us from finding solutions that fit within them.

The nature of the constraint dictates the area in which the growth will occur. Twitter's constraint encourages conciseness and the ability to focus on the core message. Writing assessments in classes tend to set the opposite constraint of a minimum number of pages of content in order to encourage deeper exploration of a topic and more hours of practice in writing.

Thinking about this principle in the context of software development made me realize that the many different types of software are often differentiated by the major constraints they face:

Constraints can also be applied to processes or methodologies to provide learning opportunities. I have heard more than one ScrumMaster say they prefer one week iterations for teams new to scrum as a way of learning how to decompose functionality into the smallest possible increments. The concept of stretch goals is similar: set targets beyond the current capabilities of the team in order to push team members out of their comfort zone and seek innovative ways to meet those targets.

How can you use constraints to improve and grow? I encourage you to reflect on this and leave a comment sharing your thoughts.

Adopting Test Driven Development

The boldest idea I heard was in response to my question of how to encourage the adoption of test driven development (TDD). The answer consisted of this process:

1. Clearly communicate to the team the expectation that all production code will be produced with tests.
2. Wait and monitor code check-ins until you see code checked in without tests.
3. Delete this untested code and commit the change.
4. Communicate to the affected developer that you found some code that was not necessary because the tests still passed after removing it. Diabolical laughter optional :)

This sounds extreme, but the team I was talking to actually used this in the formative early stages of building their team and the use of TDD has become a standard practice on the team. I think applying this at the start of a project with a new team is the best timing and makes the most sense, but I may have to try it mid-project (my team, watch out :)

I also learned of a different approach to writing individual tests that basically involves starting at the end and working backwards. Start first with the asserts that specify the desired result, then write the execution of the method under test which covers how the result will be obtained, and then finally write the setup code which provides the necessary inputs. This approach is very much a pull approach (in the lean sense) - each step serves as the specification for what needs to be done in the next step. As such, it might be an easier approach for newcomers to unit testing.

Adopting Pair Programming

I asked about dealing with resistance to adopting pair programming, especially the tendency of pairs to collaborate jointly for only a short time before reverting to working separately, each at their own computer. The answer was to take away someones computer, which leaves them with no choice but to pair with someone else on the team.

Environment factors can also help or hinder pairing. The Calgary teams have their workstations set up to allow people to sit side-by-side in front of the same machine. I think this layout is very important for successful long-duration pairing, and I switched my own cubicle over to this layout a while ago. The Calgary teams, however, took this setup one step further and have a second keyboard and mouse for each of their workstations. This has several benefits in terms of encouraging pairing:

• It communicates visually the expectation that two people will work at this computer rather than one.
• It eliminates concerns over using another person's keyboard. The 'owner' of that workstation has their dedicated keyboard, with the second keyboard reserved for guests. Whether the concern is over germs or over intruding on someones property/space, having only one keyboard produces a reluctance on the part of the visitor to drive.
• A common problem in pairing is for the person who is not driving to become too passive. Providing a second keyboard gives them the opportunity to jump in at any point (even when the driver does not want to relinquish control), and having the keyboard waiting in front of them is a subtle reminder to remain actively involved.

Using Task Boards

All the teams use task boards consisting of cards in various columns on a whiteboard, wall, or even a window. My team has recently switched to using a task board and I really like it in terms of it visualizing the work in progress and serving as a hub for discussions, like in the daily scrum. Given my experience and its broad use in Calgary, I am going to more actively promote its use.

Every team seems to have variations in how the task boards are used, but there were some commonalities across the Calgary teams. All teams used large cards - about the size of half a normal 8.5 x 11 page. Compared to the small post-it-note-sized cards my team uses this is a lot more real estate. These cards are made from colored paper cut in half that allows different colors to be used for different types of activities (e.g. defects, stories, and tasks). One team printed out defect reports (from JIRA) on regular paper and folded them in half to attach them to the wall. Another team attached printed requirements (with tests) folded in half to user stories. The teams all had relatively few columns for their task board - usually not more than four consisting of "In Sprint", "In Progress", "In Testing", and "Done".

Professional Development

The Calgary teams have a very strong culture of professional development that manifests in a number of ways. The most visible manifestation is my seeing many recent software development or I.T. books scattered around the office, many of which are books on my reading list (I may have to do an office raid :).

What I consider the most significant manifestation of this culture is the existence of a professional development group for senior developers. This group holds a number of activities that include periodic presentations by members on technical topics, book reading groups to jointly go through particular books, and Friday noon viewings of videos relating to software development.

One of the technical leads had an interesting rationale for doing professional development: not doing it is essentially stealing from your clients in the future. If you spend five percent of your time doing professional development and improve by five percent per year, then you will break even after the first year and show a benefit in future years: your output will be higher than before, even after subtracting the five percent. So not doing professional development will leave your client shortchanged in the future. If you let that trend continue long enough, you will eventually lose your client.

Summary

I had a great time and enjoyed being challenged with new ideas and perspectives on software development. I believe that visiting other teams or companies and seeing first-hand how they do things is quite beneficial. I encourage you to look for opportunities to do this and I hope to do more of it in the future. Thanks CGI Calgary!

Some authors recommend focusing on improving your (or others) weaknesses. They generally believe that being well-rounded is important, and a common analogy is a chain of many links only being as strong as the weakest chain. The strongest case for this position I feel comes from the entrepreneur literature: for a business to be profitable, you not only need a good product or service, but you also need the marketing and sales to have sufficient sales, and the financial management to manage your cash flow and ensure profitability. A weakness in just one area can jeopardize your entire business.

Other authors recommend focusing on developing your strengths. A common argument is that building specific expertise generates the most value, and that it is easier to improve areas of natural ability than weaknesses. Areas of weakness can be delegated or outsourced to others. This recommendation corresponds with the general trend in the labor market of increased specialization.

As I have observed the performance of individuals and teams and dealt with employee performance problems, I have come to realize that this strength / weakness categorization is largely artificial and is not the best model.

I have instead adopted a model based on defining the minimum and optimal thresholds of competence for different aspects of a specific role. The minimum threshold defines the level under which a person will fail (have inadequate performance) in the given role. As your ability increases above the minimum threshold, your performance in the given role improves until you reach the optimal threshold. Beyond this point, increased ability will not improve performance. See the diagram below for a visual representation.

This model accounts for the phenomenon where people who have been doing well or even excelling in a particular position suddenly encounter difficulties when moved into a different position. The reason is that the new role demands a different set of thresholds for which the person falls below the minimum in one or more areas. The classic example is taking an exceptional software developer and promoting them to a manager. This person’s software development skills now exceed the optimal threshold required for a manager, whereas the communication and management minimum thresholds required as a manager are much higher.

The impact of what are traditionally considered strengths or weaknesses depends on the particular role. In some cases a personal weakness may still at a sufficient level to exceed the minimum threshold of competence. One example is having a fear of public speaking (which is apparently quite common). For the typical software developer position, the minimum threshold required for public speaking is very low – a developer just needs to be able to participate in team meetings and group discussions. So this weakness is not particularly relevant for the role. In other cases the team has mitigation strategies in place to address common weaknesses, thus lowering the minimum threshold required for certain roles. One example is developers performing manual testing. This is often not a strong ability for many developers due to the different mindsets required. So development teams incorporate dedicated testers to address this issue.

If personal strengths and weaknesses are misaligned with a role’s minimum and optimal thresholds, with a person being above the optimal and below the minimum in a number of areas, then this generally indicates that the person is in the wrong role.

Even personal strengths may fall below the minimum threshold of competence. This often indicates that the person has been given an assignment too difficult or challenging for their level of experience. One example is giving a good junior developer extremely complex functionality to implement from scratch without guidance. A senior developer could get the job done, but the junior lacks the knowledge and experience – their ability falls below the minimum threshold, despite being a strength for them personally.

A common mistake is to continue to focus on developing your strengths after you exceed the optimal threshold, due to a logical slippery slope. If you begin a new role with most areas below the optimal level, then you will naturally be motivated to improve your strengths and see a corresponding improvement in performance. This motivates you to continue to improve in these areas, even after they exceed the optimal threshold. Malcolm Gladwell in his book Outliers the Story of Success provides a specific example of this phenomena dealing with I.Q. Most people believe that being smart helps one succeed in most areas of life, and that having an even higher genius-level I.Q would be better. I admit to having shared this belief. The extensive research study discussed by Malcolm, however, clearly contradicts this by finding that individuals with genius-level I.Q. did no better in terms of career than those who are ‘only’ smart. So across many fields I.Q. does have an optimal threshold as well as a minimum.

Using this model of minimum and optimal thresholds of competence clears up the confusion in the literature on whether to focus on strengths and weaknesses. Ignore those labels and instead focus on how your abilities align with what the minimum and optimal thresholds are for a given role – either your current role or the role you desire.

Quantity of Practice Required

The research is surprisingly consistent on the quantity of high-quality practice necessary: approximately 10,000 hours. This amount of practice seems to take a minimum of about 10 years to achieve which works out to a rate of 20 hours of practice per week, or about 4 hours per day excluding weekends. It is interesting that this rate of 4 hours per day corresponds to what the research says is the apparent maximum amount of quality practice that can be performed each day. The activity being practiced can be performed for longer, but improvements due to practice do not occur. The reason for this limitation is mental: deliberate practice requires high levels of concerted mental effort that can only be maintained for a limited duration, and a period of sleep is needed during which the brain consolidates the learning that occurred during the day. These limitations explain the 10 year minimum duration: you cannot double the amount of practice you do per day and cut the total duration in half.

Key Elements of High-Quality Practice

It is quite common to see workers with more than 10 years of experience who are nowhere near being an expert. This is because simply performing an activity is not the same as deliberately practicing an activity, although the difference may not always be visible to laypeople. Many people just go through the motions in their work, repeating what they have learned and done before, and thus fail to continue to improve. I have heard this described as having one year of experience repeated for nine years. This explains, therefore, why there is no correlation between the years of 'experience' a developer has and their ability to write code.

So if our goal is to become experts, how do we ensure that we are engaged in high-quality practice rather than just repetitively performing the activity? Here are some key elements of high-quality practice:

• Practice must be specifically designed to improve performance for an individual. The practice must push or stretch the individual beyond their current abilities, outside their comfort zone, but not too hard that it causes anxiety and complete failure.
  

  Each practice session should focus on one (or more) specific elements of performance. The more precise your goal(s) for the session, the better the quality of your practice. You need to seek out what you are not good at. Clearly identifying this yourself can be difficult for a number of reasons. Your ego tends to cause you to fail to notice areas of weakness. You might simply lack knowledge about specific areas. And for areas of performance you know about, it may be difficult for you to evaluate your performance compared to the level of an expert. The guidance of a coach or mentor is therefore extremely helpful. In the realm of sports, even experts like Tiger Woods have coaches to help them improve.

  In business, unlike sports, access to coaches and mentors is much more limited, if not completely non-existent. So as software developers we need to be more creative in finding ways to obtain guidance. One option is to engage in as much pair programming as possible with as wide a variety of developers as possible. You will not always be paired with an expert, but with a wide variety you will encounter situations where your partner reveals some aspect of development you were unaware and can learn from. Another option is to seek out material – blogs, articles, and books – produced by respected developers about coding & design and study their material carefully to absorb their approach to software development. One example of this is Robert C. Martin’s book Clean Code which provides step-by-step transformations of code into a cleaner form. He also provides on his website a presentation and even a video demonstrating the process of doing test-driven development.

• Practice activities must be easily repeatable. To reach expert level requires putting in lots of repetition during practice. The number of repetitions performed by experts during individual practice sessions and over the lifespan of their career can be mind-boggling to laypeople.

  Repetition is especially important for those aspects of a field that normally occur less frequently. If a specific aspect is normally only encountered once a year and you never practice it then you will function essentially as a beginner each time you encounter it.

  A good example of this in the field of software development is performing the actions leading up to the release of the software: integration / stabilization of the software, acceptance testing, and final packaging / deployment. Traditionally under a waterfall methodology this is done once in the last phase of the project. Modern Agile development methods instead mandate more frequent releases, with some potentially being practice releases that are not actually provided to real users. Activities such as code integration or acceptance testing that were traditionally done once prior to a release are done much more frequently as part of each iteration.

• Practice must include feedback regarding the quality of the performance: what was done perfectly versus what can be improved. The more specific the feedback, the easier it is to adjust your actions and tailor future practice sessions to address deficiencies. Feedback should be available immediately, without delay, as part of the practice session.

  One of the best ways of obtaining feedback is through a coach or mentor who can evaluate your performance and make recommendations for improvement. Without such a resource there are still ways of gaining feedback. One approach is to find problems done by an expert, solve them yourself, and then compare your solution to the expert's. Another approach is to regularly set aside time to reflect on your performance and identify specific improvements.

  Obtaining sufficient feedback soon enough is challenging in the field of software development. Many modern development practices are deliberately designed to maximum the feedback developers receive. Test driven development provides immediate feedback regarding the correctness of the code. Pair programming provides immediate feedback regarding the readability and maintainability of the code. Root cause analysis of defects helps identify specific mistakes that practice can address.

• Deliberate practice is mentally highly demanding. This is a consequence of pushing beyond your comfort zone. If you are able to do an activity on auto-pilot, without really thinking, then it is too easy. To grow and improve requires you to be sufficiently challenged.

  Research suggests that one’s ability to sustain mental concentration and focus is the main governing factor determining the amount of effective practice that can be performed. The limit seems to be about 4 to 5 hours per day, divided into sessions of no more than 1 to 1.5 hours in duration. (I find it interesting that this maximum session duration for deliberate practice is the same as the recommended maximum duration for code review sessions, which is no surprise given that both activities require a high level of focus and concentration.) It would be interesting to know what kind of rest and recuperation between practice sessions is recommended, but I have not seen this discussed.

Conclusion

To become an expert requires approximately 10,000 hours of high-quality deliberate practice, which must consist of training activities designed to improve performance, lots of repetition, specific and immediate feedback, and sustained high levels of mental effort.
This is simple to state but is definitely not an easy endeavor to do, which explains why in every field there are so few experts and why the majority are at much lower levels of performance. Yet if becoming an expert is your goal, then this is the path you need to take.

]]> http://www.basilv.com/psd/blog/2010/how-to-become-an-expert-developer/feed 0 http://www.basilv.com/psd/blog/2009/adopting-test-driven-development http://www.basilv.com/psd/blog/2009/adopting-test-driven-development#comments Tue, 17 Nov 2009 23:22:28 +0000 Basil Vandegriend http://www.basilv.com/psd/?p=453 I have always been keen on using automated unit tests since I first heard about them almost a decade ago. I have known about test driven development (TDD) for almost as long but the practice of writing tests first before writing production code never really clicked for me when I first tried it years ago. Since then I have evolved my approach of writing tests, but still almost always after I write the production code.

Recently I was prompted by multiple sources to give TDD a try, the most prominent and vocal of which was Robert C Martin, who stated that he believed TDD to be one of the most significant new software development practices he had adopted in his 30 years of experience. I found particularly compelling his comparison of TDD for software development to the medical practice of sterile operating rooms.

Based on these strong recommendations, I decided that I needed to give test driven development another try.

Preparation

I resolved to not just haphazardly try TDD like I did before, but to adopt it as a development practice for a period of time as a continuous improvement experiment. I deliberately went with a more disciplined approach. Based on my knowledge of personal development and continuous improvement, I knew that the change would be difficult, especially at first. So I prepared for the change via the following steps:

• I reflected on the difficulties I would face in adopting TDD. I expected to struggle with two issues. The first was the drop in productivity due to getting familiar with doing TDD – I would be spending a greater percentage of my time thinking about my process of coding as it related to TDD, rather than the code I was writing. The second was the natural tendency to revert back to my established pattern of behavior. This reflection ensured I would have more realistic expectations when I started using TDD.
• I refreshed my knowledge of the details of doing TDD that go beyond the core idea of writing tests before code. My favorite reference was Robert C. Martin’s three rules of test driven development which are:
  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
• I wrote a note to do TDD and stuck it to the front of my keyboard were it would always be visible to me. It served as both an affirmation and a reminder.

Having finished my preparation, it was time to actually start doing test-driven development.

Adoption

My initial start with TDD was easy: I started my next coding task by writing a test rather than production code. If only it stayed so simple :)

At first the shift in process was difficult as I had to consciously remember to write the test first, and then write only a portion of the production code necessary to get it to pass. My productivity felt a lot lower (I have no idea whether it was significantly worse or only a little). But I had expected this and used discipline to force myself to continue with TDD.

One of the hurdles I faced was how strictly to follow the three rules of TDD - particularly rule number three. I had always been uncomfortable with the idea of writing temporary or intermediate production code that would get the current test to pass, but that I knew was not the final form and that I would need to change. An example is implementing an algorithm to return a fixed value (say zero or null) rather than implement the actual logic. I decided to take a pragmatic approach and allow myself to deviate from the three rules on occasion, when following the rules seemed too onerous or difficult. I did not want blind adherence to the rules to cause me to completely give up on TDD. I expected that over time as my familiarity with TDD grew, I would be able to become stricter in adhering to the rules.

As expected I suffered setbacks along the way. I started a development task by writing most of a method of production code before realizing that I had no failing test. In another case I had a failing test but then churned out the entire production method, including all the special cases, well after that test would pass. I took these setbacks in stride – I considered them a normal outcome of adopting a new behavior, rather than personal failures, and simply returned to doing TDD once I became aware of my departure.

After about a week, doing TDD became less of a struggle. After about three weeks (the typical minimum duration to establish a new habit) TDD began to feel more natural. By this point I had clarified for myself the benefits and limitations of TDD and had integrated it into my development process. I have a lot more to say about this which I will save for a follow-up post. As a quick summary, I find TDD to be a valuable practice that I intend to continue to use.

Conclusion

If you have not tried TDD, I strongly recommend you experiment with adopting it as a development practice. Looking beyond just TDD, one of the points of this article is to encourage you to always be thinking about your capabilities as a software developer and continuously seek to improve.

]]> http://www.basilv.com/psd/blog/2009/adopting-test-driven-development/feed 1 http://www.basilv.com/psd/blog/2009/evolving-my-vision-and-mission http://www.basilv.com/psd/blog/2009/evolving-my-vision-and-mission#comments Tue, 16 Jun 2009 03:06:34 +0000 Basil Vandegriend http://www.basilv.com/psd/?p=413 If you are a regular reader you may have noticed that I use guiding statements like a vision or mission to motivate and inspire myself and clarify my future direction. The following articles contain some of my past efforts:
• 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.

]]> http://www.basilv.com/psd/blog/2009/evolving-my-vision-and-mission/feed 2 http://www.basilv.com/psd/blog/2009/using-rotations-to-develop-expertise http://www.basilv.com/psd/blog/2009/using-rotations-to-develop-expertise#comments Fri, 17 Apr 2009 08:39:55 +0000 Basil Vandegriend http://www.basilv.com/psd/?p=358 This article continues on from my prior article Improving Computer Science Degrees for Software Developers on the topic of better methods of developing expertise as software developers in the work place. The original inspiration for these articles is the post Master Craftsman Teams by Robert C. Martin in which he proposed a formalized development path based on the apprentice – journeyman – master craftsman model used by the trades. The specific inspiration for this article is use of rotations in the field of medicine in training medical students, interns, and residents. Trainees spend a fixed period of time working in a particular specialization (e.g. neurology) or unit (e.g. intensive care), after which they rotate into a new assignment.

Benefits of Rotations

The use of rotations provides two key benefits:

1. Rapid learning: People learn most rapidly when placed into new, unfamiliar situations, as opposed to being in the same environment year after year. The initial ramp-up period for new team members often corresponds to the period of increased learning, after which it tapers down. The use of rotations essentially maintains this ramp-up state to realize this enhanced learning on a more ongoing basis.
2. Breadth of experience: Rotation assignments are specifically selected to provide a broad range of experience in the field. This helps trainees determine what they would like to specialize in, and once specialized helps them work more effectively with other specializations. Breadth of experience helps develop that "big picture" understanding of the field and provides better appreciation for how each specialization contributes to it.

While software development is quite a different field from medicine, I believe that the use of rotations is just as beneficial to developing expertise as developers. One example is spending time maintaining or enhancing a preexisting code base tends to teach the importance of having cleanly design and easily understood code – in other words maintainability. Another more general example is developing that breadth of experience tends to provide a better appreciation of the importance of context in determining what development technologies, practices, and methodologies to apply.

Required Rotations

What kinds of rotations would be beneficial for developers? Listed below are the key assignments that I feel every developer should experience:

• Production Support: Keep an operational system running. This develops your ability to diagnose and fix problems. It teaches you about all the bizarre events that can happen in a real system that never seem to happen in testing. I personally found it humbling to watch systems I thought were solid get hammered and fail in ways I never expected. You will learn the value of many non-functional requirements such as reliability, performance, scalability, manageability, and supportability (e.g. good logging).
• Maintenance: Make enhancements and fixes to an existing code base in active use. You should do this both for a system you originally developed and one you have not. This teaches the importance of good design and readable code – i.e. maintainability.
• End-User Support: Directly dealing with user inquiries and problems. This is enlightening in numerous ways: it provides you with a better understanding of what users value, how they react, their level of understanding of I.T., and what they like and do not like in the software they are using.
• New Development: Develop a piece of software going through all the stages of the software development life cycle: inception, requirements, design, coding, testing, release, and maintenance. Going through the entire cycle gives you a deeper understanding of the big picture. More importantly, you will have the opportunity to benefit from feedback in later stages regarding earlier stages: e.g. coding indicates requirements were poorly understood by all, or testing reveals a design defect.

Optional Rotations

There are many other possible rotations across the full breadth of the field of software development. A large (but not complete) list of these assignments is provided below, organized into categories.

• Assignments in different types of software development organizations:
  • Product-focused
  • Service-focused (e.g. consulting)
  • Internal I.T.
• Assignments in different organizational cultures:
  • Bureaucratic
  • Entrepreneurial (e.g. a start-up)
  • Lean
• Assignments using different development methodologies:
  • Agile (process-light)
  • RUP (process-heavy)
  • Waterfall
  • Chaotic
• Assignments working on different types of software systems:
  • Web applications
  • Enterprise systems (e.g. messaging, batch processing, integration of systems)
  • Desktop
  • Mobile
  • Games
  • Software development tools (e.g. compilers, IDEs)
  • Software infrastructure (e.g. operating systems, databases, networking)
  • Scientific (e.g. simulations)
  • Mission critical (e.g. medical, aviation)
• Assignments involving different software development skills:
  • Web design (html, CSS)
  • User interface design
  • Database design
  • Database administration
  • Data conversion
  • Web services
  • Batch processing

Obviously you cannot gain experience in all of the items listed above. The point is to think about where you want to take your career as a software developer and then choose assignments that provide sufficient breadth while avoiding irrelevant assignments.

Adopting Rotations

How can rotations for software developers be adopted? As much as I think it makes sense, I do not see the I.T. industry as a whole formally adopting rotations in a fashion similar to medicine. So what about at the level of an individual organization? Even fairly small companies usually have different teams or products for which rotations could be formally set up. I have seen companies doing this for undesirable work such as customer support or production support. Developers are rotated into such roles either for an entire iteration or for a certain percentage of days each month. But the focus of these rotations is typically on getting the undesirable work done rather than the increased learning.

In many companies I have seen a tendency for developers to get stuck into a particular role or team. Supervisors are reluctant to give up a trained, skilled resource to another team, even in a trade. Temporary assignments on another team are also fairly rare for the same reasons plus the common fear by the supervisor that the temporary situation ends up becoming permanent. So a developer who wants a change often needs to initiate it by changing jobs.

Since the industry as a whole as well as individual organizations cannot be relied upon to provide for rotations, I believe it becomes the responsibility of each individual software developer to seek out that breadth of experience. Formal rotations may be beyond our control, but we can explicitly seek out different assignments to provide that breadth of experience and accelerated learning.

I'm interested in hearing what you think. Do you agree with my list of required rotations? Are there any you would add or remove? Do you have examples of where you actually used rotations? Let me know by leaving a comment below.

]]> http://www.basilv.com/psd/blog/2009/using-rotations-to-develop-expertise/feed 1 http://www.basilv.com/psd/blog/2008/using-the-next-step-to-improve-your-focus-and-productivity http://www.basilv.com/psd/blog/2008/using-the-next-step-to-improve-your-focus-and-productivity#comments Tue, 30 Dec 2008 21:25:18 +0000 Basil Vandegriend http://www.basilv.com/psd/?p=223 I have discovered a powerful technique for improving my focus and productivity on work tasks that I call the Next Step. I have been consistently using this technique for a while now and I am quite pleased with its benefits.

How Does it Work?

The basic concept is simple: clearly identify the next task you should work on, write it down as your next step, and then work on it. Given a typically large set of tasks – what I like to refer to as to-dos from a to-do list – a lot of time can be wasted jumping back and forth between tasks and figuring out what to do next. This is especially true when you are inflicted with frequent interruptions, distractions, or breaks.

How you choose the activity for your next step is critical. While the decision should take into account multiple factors such as importance, urgency, and time available, I believe the primary factors that you should use are motivation and progress-ability. Which task are you most motivated or interested to work on next? For which activity do you have the clearest idea of what to do next in order to make progress? By emphasizing these two factors you maximize your productivity on each task: you are as motivated and as clear as possible as to what needs to be done. This is especially true when the tasks are all related to a single project, such as coding functionality for an application. In this case it matters far less what order the work is done in than the amount of progress you make each day.

Putting it into Practice

A key ingredient to implement this technique is a simple and fast method for recording tasks for a piece of work - what I like to call a to-do list. This is necessary because when you are working on your next step and identify an unrelated idea or issue, you need to write it down on this to-do list to get it out of your mind and avoid having it distract you from the task at hand.

I use different approaches to implementing the next step technique depending on the work I am doing.

When writing code in my IDE (Integrated Development Environment), I record to-dos as special code comments that the IDE filters and displays as a list. Instead of recording my next step in a similar fashion, however, I record my next step on a piece of paper on my desk. I use this low-tech solution for a few reasons. The next step is often not as fine-grained as individual to-dos, and may include several to-dos and multiple source code files. Writing it separately allows me to express it at whatever level of detail is appropriate. Using a separate piece of paper provides an area for me to jot down brief design notes, if necessary, as I work on the task and need to resolve design issues. When the task is complete I cross it off on the paper and write down a new one, perhaps flowing logically from the current task or perhaps pulled from my to-do list in the IDE.

When writing large documents in Microsoft Word or Open Office, I use a different approach. Before I write content, I start with some sort of outline – usually a partial outline that I expand and refine as I write. I represent the sections of the outline using headings within the document. Correctly using styles for the headings allows me to use features like the document map or outline view in Word to view the outline. I represent to-do tasks using the text "TODO" with a yellow highlight. For sections that I have not yet started or are incomplete I suffix the heading of the section with this to-do text in parentheses. This allows me to view the outline and see what sections still need to be written. When I choose an outstanding section as my next step, I prefix that heading with the text "NEXT STEP" with a red highlight. When I finish the content for that section, I cut and paste this text to the next section I have chosen.

Why It Works

This technique incorporates a number of elements that make it effective in several ways:

Improving Focus: Explicitly choosing and writing down your next step and providing external storage for any extraneous ideas that come up (your to-do list) helps orient your mind towards the task at hand and keep it free of distractions, which improves your ability to focus on it. I find this especially useful for tasks which I must do but have lower motivation for: my mind tries to suggest distractions to derail me, but my strong focus makes it easier to push through and get the work done.

Recovery From Disruptions: Having your next activity clearly identified in writing makes it much easier to resume work after a break or interruption.

Maximizing Productivity: Choosing your next step based on motivation and progress-ability maximizes your productivity on each task you work on.

Your Next Step

I challenge you, the reader, to immediately put this technique into action. For your current project or to-do list deliberately decide on your next step and write it down. Let me know via the comments below how this technique works for you and how you adapt it for your own use.

]]> http://www.basilv.com/psd/blog/2008/using-the-next-step-to-improve-your-focus-and-productivity/feed 2 http://www.basilv.com/psd/blog/2008/becoming-a-champion-of-continuous-improvement http://www.basilv.com/psd/blog/2008/becoming-a-champion-of-continuous-improvement#comments Mon, 17 Nov 2008 01:34:24 +0000 Basil Vandegriend http://www.basilv.com/psd/?p=202 I am pleased to announce that I am a Champion of Continuous Improvement.

The story of how I became such a champion starts a few months ago when I spent some time reflecting on my mission / purpose / vision as a professional software developer and architect. I was inspired to do so by two sources. The first was the book The Professional Service Firm50 by Tom Peters, which advises readers to create a cool job title for themselves that is motivating and inspiring. The second source was an online article by Steve Pavlina titled How to Discover Your Life Purpose in About 20 Minutes which provides a simple yet effective process for creating one's personal life purpose statement. This process involves brainstorming statements and then using your emotions and intuition (your heart) to evaluate and evolve them rather than logic (your mind).

I decided to use Steve's process to create a cool job title. (I also used Steve's process to draft a mission statement for myself.) Reproduced below is my brainstorming list – at least those items I actually wrote down – with some commentary.

1. Problem Solver: My starting point because lately when coworkers ask me what I do, I tell them I solve problems. I wear too many hats to be able to easily describe all my roles :)
2. Visionary
3. Leader
4. Do Things Better
5. Quality
6. Technical Growth Visionary: With this item I knew I was close to the core idea. Most of the remaining brainstorming ended up focusing on selecting the most meaningful words to capture this idea.
7. Improve
8. Coach
9. Guide
10. Professional Development
11. Change Provocateur
12. Change Agent
13. Technical Improvements Leader
14. Personal & Team Technical Growth Leader
15. Services
16. Software Development Services Leader
17. Champion of Continuously Improving Software Development Services: This is the last draft version before the final version. It seems like a big jump from the prior items since both the words "Champion" and "Continuously" are introduced for the first time. I suspect I did some mental brainstorming prior to this item that I never wrote down.

The final version of my cool job title is Champion of Continuous Improvement of Software Development Services. This is a bit of a mouthful so I tend to shorten it to "Champion of Continuous Improvement". The clause "of Software Development Services" is still important, however, since it provides a scope or boundary for my continuous improvement activities. I deliberately restrict myself to the realm of software development where I am most motivated and have significant expertise, and exclude activities such as service delivery management, program management, and infrastructure support. I have the word "Services" on the end to avoid restricting myself to only software development activities such as coding or debugging. I deliberately wanted to include related activities such as quality assurance, project management, and enterprise architecture.

Now that I had my unofficial title, I found myself strongly motivated to make it as official as possible. My first step was to print out the title in large font and post it outside my cubicle. I then added it to my short term career goals and discussed it with my manager. One interesting comment I received from more than coworker was that the sign was unnecessary in the sense that they already knew that was what I did. I found this encouraging since it meant my title aligned well with my past actions.

Speaking about past activities, I was already chairing a process improvement group and leading a technical practices review – or at least trying to. My efforts in these areas had stagnated somewhat, due largely to a lack of clarity about an effective way to move forward. With my new title, however, the path forward became much clearer and my motivation much stronger. I transformed the process improvement group into a continuous improvement group and at the first meeting discussed the topic of championing continuous improvement. The discussion was spirited and the topic seemed to resonate with the other senior technical resources at that meeting. This provided me a boost of confidence that I was on the right track.

Another key step I took was to discuss my new title with my manager. Together we brainstormed various ideas regarding the next steps I could take and I began implementing the most promising ones. I was fortunate to have such a supportive manager since management support was essential.

At this point in time my road ahead as a Champion of Continuous Improvement was clear to me, and I felt that I had earned the title by my actions, both before and after I came up with it.

That is my story of how I became a Champion of Continuous Improvement. I plan to write further about my experiences as champion, and would love to hear from you concerning your experiences with continuous improvement, both good and bad.

]]> http://www.basilv.com/psd/blog/2008/becoming-a-champion-of-continuous-improvement/feed 0