Performance to Productivity to Results

Basic programming skills in the software engineering world are not going to take you very far. I still wonder why software engineering interviews focus on bit flipping, linked lists, walking a binary tree, and so on. Even slightly more advanced topics like design, polymorphism, and serializing data aren't all that helpful because it limits you to the 'what do you know'. These types of questions are all about raw memorization and some intellect, but do not capture the essence of what engineering is.

Engineering is about results. It is about crafting an idea into something. Raw performance (i.e. how fast or much code you write) tells us very little about how productive you are and certainly speaks nothing about your ability to deliver a complete tool, system, networking solution, database integration solution, or whatever. It tells us if you know the basics and if you can sling some code.

So the question becomes: what is the difference between performance and productivity? How do I increase my performance? Productivity? How can I get better results?

Performance
Performance in software development is measured differently by everyone and metrics are hard to come by. These are often related to some form of number like Lines-of-code-written, Bug fix-rate, number of files checked in during a day, or some other easily recorded numeric value. These are also very easy to inflate by adding functions that are never called, fixing easy bugs or making bugs and later fixing them, or by 'refactoring' code. If you don't think people cheat this way, nearly everyone does in the right circumstances (everyone I have worked with does, but maybe the reader does not).

Performance is most often related to the ability to "crank out code" and find cool solutions to atomic problems, i.e. problems that aren't strongly related to bigger problems.

Productivity
Productivity is a different measure entirely and is a far more useful way to measure someone's value to an organization. This is best illustrated in "integration" and "submission" where any piece of code, data, art, music, or whatever can easily be put into the final product. Productivity most often means tools, pipelines, and efforts at reducing code redundancy.

Productivity also means working with others. Rare indeed, is the lone programmer who manages productivity by himself/herself. This is where you recognize the usefulness of your boss who should be actively coordinating your efforts with other people, teams, and outside vendors. This is also where one gives up the idea that s/he is the "best programmer on the team" and embrace that s/he can learn something from nearly everyone. This is really where a person begins to add value to a company.

Measuring this human quality is no harder than measuring someone's ability to code. Simple questions of product lifecycle, useful management structures, and seeing how someone interacts during an interview often reveals the ability of that person to work on a team and to work toward a solution with others rather than trying to solve the whole thing himself/herself.

Results
The process of shipping a product is so different than actual product development, that it belongs in a separate category called finaling. This can mean some long hours, sleeping under your desk, and some intense debugging sessions. The pressure is on and people often ask themselves a few weeks into the process if they will ever see the sun again. I certainly have become a lot whiter during these sessions.

Putting an application in a shippable state means tracking every conceivable bug, integrating the latest version of the third-party library, and communicating with everyone on the project very regularly.

This phase is another area that is fairly easy to measure beforehand or during interviews. Simple questions like "tell me about a finaling disaster that you've seen" or "tell me what really worked on your last finaling experience" help to provide depth of experience. Other keys are how well a person prepares for finaling, does s/he know what a TSR (TRS) is (vendor requirements before submission or lot cheks), does s/he see the value of a zero defect rate, and so on.

Conclusion
These three factors are the key differences between junior, mid-level, and senior-level engineers. They amount to coding, integration, and finaling and deeply illustrate a person's ability to forecast, demonstrate, and recognize new needs before they arise. When looking to your staff and looking for leadership, this is often a good place to look. It's one thing to be able to tell people what to do and it's another thing to be able to recognize the train before it hits you. Senior people can do both.