Factors of Programmer Productivity

Three observations:

• A few months ago, there was a curious article doing the rounds: Programmers who use spaces to indent their code are paid 9% more compared to programmers who use tabs. This result held, even after controlling various factors, such as: the programming language, numbers of years of experience, country etc. Now, let’s observe what is going on here.
• Anecdotally, we have all seen programmers who are orders of magnitude more effective than others in achieving their tasks; this sets up a virtuous positive feedback loop, where the effective programmers are recognized and rewarded, and that, in turn, makes them more focused towards work. Instead, how can we create a tide that lifts all boats, big or small?
• Given the similar numbers of years of experience, there is, at times, a 5x difference in salaries between programmers, even programmers with similar academic backgrounds. What is the cause of these income disparities that seems to start even within the first few years of one’s career?
  An analogy: Let’s say you were asked to estimate how long a specific car trip, say from Siruseri to Ennore, would have taken. What are the different levels in which you would think about doing the estimation?
• At the first level, you would want to know the car model itself: what is its maximum speed, which in turn depends upon its power, weight, design etc. This is the level at which you would observe its capability and in finding its potential speed.
  • But that would hardly give you enough information about the time taken for the trip. Such information would rely on the routes available, the traffic conditions on those routes, which itself would depend upon the day of the week and time of the day, the state of the roads, and signals on the way. You are now assessing the conditions of the trip and estimating the achievable average speed.
  • But even that would not be enough information. You would also need to know how well the driver is familiar with the route; whether s/he was able to avoid dead-ends, diversions, and wrong turns. Now you are factoring in the effectiveness of the drive.

We will use this analogy to see how we can be better programmers: with better capabilities, with more conducive environments, and with more effectiveness in delivering value.

Potential Productivity

A car’s theoretical maximum speed depends upon a variety of factors, such as: engine power, automobile weight, aerodynamic design etc. Similarly, as programmers we can use a simple model for our potential productivity:

potential_productivity = f1(attitude, knowledge, intelligence)

Attitude covers a whole lot of attributes, such as: ability to focus, self-confidence, capability for hard work, attention to detail, self-motivation, being unfazed by failures etc. Knowledge covers both technical knowledge: computer science basics, programming languages, etc. as well as, domain knowledge and soft skills such as: ability to work in a team, and written and oral communication skills. Intelligence covers problem solving skills, the ability to think outside the box, troubleshooting smarts as well as, things like quick comprehension.

The analogy of attitude, knowledge and intelligence (of a programmer) to engine power, weight and design (of a car) works well in the aspect that it is the attitude that is the base automotive power, which is then enabled and transformed by other features to achieve the theoretical maximum speed. It continues to work, if we assume that the car’s design is in our hands – we can work and improve the design; all attributes that makes a good programmer – attitude, knowledge and intelligence – are trainable, given a growth mindset.

We, at Hexaware, are committed to making our employees improve and realize their best potential. Towards that, we have made, and continue to make, huge investments in the learning and development of both technical, interpersonal and attitudinal skills. This includes e-learning courses in HexaVarsity (Hexaware’s Learning University) for soft and hard skills, sponsored certification for technical and process skills, conducting hackathons and coding competitions, which aid innovation and collaboration. We are also looking at sponsoring MOOC courses for our employees, which brings in the best-in-class courses from world-renowned universities, to the L&D curriculum of Hexaware. We can also look at peer mentoring programs, as an example, where people from completely different groups can work in pairs, to identify and improve their base potential.

Realized Productivity

The theoretical maximum speed of a car has little effect on the actual experience in city traffic. A sleek Bugatti, which can do 400 kmph or an ancient clunker, which struggles at 40 kmph, ends up doing only 25 kmph in the city roads.

Similarly, the realized productivity of a programmer can be amplified or tempered by the environment s/he works in: the project environment, the office environment and home environment.

realized_productivity = f2(potential_productivity,
project_environment, office_environment, home_environment)

In case of project (or team) environments, the usual potholes and speed breakers, which hamper their productivity are:

• rigid and stratified structures;
• unclear goals and responsibilities;
• Non-value-adding processes and a bureaucratic mindset.

The good news that is, with agile processes and flat team structures, most of these are on the way out. We value people over processes, collaboration over contracts, trust over micromanagement; and we should take a hatchet to all processes, meetings (especially recurring meetings) and documentation that are not directly aligned to one of the most important agile principles: “Working software is the primary measure of progress”. Whenever you hear, or use, phrases like ‘operating model’ or ‘governance structure’, do a double check: are we adding artificial complexity unnecessarily to a process that is essentially human-centric?

Other ways teams can maximize their productivity by implementing one or more of:

• Do-Not-Disturb hours of the day;
• No-Meeting days of the week;
• Standard, battle-tested tools and technologies e.g.;
• Build pipelines with style checks, unit tests etc.

There are also several tricks people use to maximize office productivity. I myself have used industry-strength noise blocking earmuffs in open plan offices. I also have seen people use flags which when up indicate ‘do not disturb’ and when turned down means ‘open for interruptions’ (those of you who are Barbeque Nation aficionados will know that mechanism). Cloud-based infrastructure also helps office productivity by reducing the dependency on support groups for quick experiments. Enterprise messaging systems can be a boon for collaboration, when used appropriately.

In general, the office and team environments can realize the potential aggregate productivity by:

• Setting clear goals and responsibilities for the team members.
• Measuring people by holistic contribution and impact and not some narrow metric, like LoC.
• Enabling programmers to experiment, fail and retry with impunity.
• Establishing an atmosphere of trust and dependability.
• Letting the employees manage the resources and time, rather than imposing a rigid layer on control and monitoring.

Goal-oriented productivity

In the end, realized productivity, or efficiency, is like the on-road speed of a vehicle; a good number is no guarantee that will enable you to reach the destination. For that, we also need to ensure that our car is moving in the right direction, not going into dead-ends often and not ending up in circles that we do not end up burning out all our fuel before we reach the destination, and we do not end up in an accident.

goal_oriented_productivity = f3(realized_productivity, effectiveness)

Efficiency means doing things in a fast and optimal manner; and effectiveness means ensuring that the things we do are indeed the right things to meet the objectives. Both are important to achieve overall goal-oriented productivity. Effectiveness means being pragmatic in what we can achieve, knowing what corners we can cut and what we ought not to, and the ability to prioritize correctly – pick the right combination of both easy things to show progress and hard things to front-load risk.

We should all be working towards building an organization that is staffed by efficient and effective programmers. The Architecture Review Board is a move in that direction: the aim here is to reduce the artificial complexity and keep the project teams focused towards efficient and effective delivery.

(rewards, remuneration) = f4(goal_oriented_productivity)

Re the tabs vs spaces war, here is the background. Tabs are one ascii character, but are visually rendered as per the application/editor that you use to view the source. There is no standard on how many spaces are rendered as indent for a tab character (rightly, in my opinion). Whereas; obviously, spaces are always rendered with one space indent.

Here is my hypothesis on it: The use of tabs or spaces is a symptom; the underlying cause is the type of programmer that one is. Here, there are four different classes of programmers.

• Tab User #1: Those who are idealists, who argue that form and content must be kept separate; they use tabs always and bemoan the fact that not all applications/editors, and programmers, handle the separation of concerns correctly. (Lack of pragmatism -> Less effective)
• Tab User #2: Those who have never bothered about tabs vs spaces, and have always used tabs habitually for indentation. (Lack of attention-to-detail -> Less efficient)
• Space User #1: Those who are followers of the practice, followed by the existing codebase, typically space, especially when that rule is enforced by a build pipeline using linters and style checkers. (Part of productive teams -> More efficient)
• Space User #2: Those who are pragmatic and use spaces since that is the only way we can get consistency today. (Pragmatism and Attention to detail -> More effective and efficient)

 I think that hypothesis explains why formatting with spaces is correlated with more pay. The best of both worlds is to use an IDE that lets you type tab to indent, but replaces the tab character with a (configurable) number of spaces under the hood. Most IDEs have that inbuilt feature nowadays.

The following picture summarizes the ideas above regarding the productivity hierarchy, and the initiatives being taken in the organization in general, and by the CTO org in particular, to establish a culture of high productivity within Hexaware.