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.

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

If you are good at what you do, like a challenging yet supportive work environment, and live in Edmonton or are willing to move, then please contact me at bv-cgiwork 'at' basilv 'dot' com. CGI prefers to hire referrals of employees, so if I refer you to HR you will have a much better chance than if you just applied online.

Contact me at bv-cgiwork 'at' basilv 'dot' com to apply.

Disclaimer: I do receive a bonus from CGI for people I refer that are hired.

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?

For myself, I can think of several reasons why I code. The primary reason is enjoyment: I find the act of creating working software quite often rewarding, and as a result I am highly motivated to code. There are admittedly times when coding is frustrating and painful, like when trying to track down an intermittent defect. There are also times when coding is tedious - I can see the block of code I am trying to create in my head, but have to laboriously type it all into my IDE. Despite this, overall I find coding more enjoyable than other typical work activities such as writing documentation, design reviews, or meetings.

The type of coding I do also influences the level of enjoyment. Developing a complex new system in my language of expertise (Java) ranks quite highly. Doing simple defect fixes, fixing a problem in badly-written code, or working in a more 'primitive' language / programming environment ranks much lower on the enjoyment scale.

Another reason I code is that it lets me use and further develop my software development skills. As a senior software developer I have spent years honing my ability to create software, so it feels weird when these skills are not called upon at work. Furthermore, I still want to improve and grow my coding skills despite taking on architect responsibilities.

These reasons combined together influence whether I feel that I am coding enough. I have spend periods of time doing limited coding but not minding because I was still doing enjoyable work, usually involving architecture or design that still required technical 'thinking' and software development skills, so my overall motivation remained high. There are other times when I become twitchy to code - most recently when I was overwhelmed with meetings over a period of several weeks. Sometimes when this happens I turn to personal coding projects at home to get my 'fix' of coding.

Understanding how much you want to code requires that you understand your motivational factors and your career goals, which is valuable for everyone to know. So ask yourself the question: Are you doing enough coding?

• Your position. Are you a junior developer, a senior developer, or a team lead? In my experience, senior people often have less time for coding because of time spent providing assistance to junior resources and providing input on higher-level topics like project direction, architecture, or design. Very junior people, especially those fresh out of school, are often given a greater share of the mundane, non-coding tasks like user support, updating documentation. Development team leads, even of small teams, must spend time managing and coordinating the activities of the team. Intermediate developers and juniors with a few years of experience generally get the most coding done.
• The kinds of projects you are working on. A typical development project to create a new application will involve a lot more coding than maintenance of an existing suite of operational applications. This may be one reason that many developers prefer to be on development projects rather than maintenance.
• The phase your work is in. Whether you are working on a major new application or on a small enhancement to an existing application, there are periods when non-coding activities will predominate, such as when gathering requirements, clarifying the solution, testing and fixing defects, or producing documentation. In my experience, there is a natural fluctuation in the amount of coding - some weeks or months you get a lot of coding in, and other weeks or months almost none.
• The organizational culture. Every workplace has a certain amount of weekly overhead activities, such as time sheets, weekly or daily team meetings, performance reviews, etc. Places with more process or more required documentation typically mean less time spent coding.

The period of time when I was doing the most coding was on a project to create a new application, during the construction phase. The waterfall methodology was being used, and the design phase had been completed. The team was quite small, with only one junior resource, so we were able to spend the majority of our time coding new features. I spent over 90% of my work week coding. Currently, in contrast, I am doing very little coding - probably under 20% - due to my role as architect or technical lead on a number of projects.

How much coding are you doing?