Hacking Productivity

Quick intro: I’m Kevin Kemp. I’ve been a software developer for 7 years professionally, the last 5 months or so here at FNC. I want to write about my views on productivity.

One thing that’s awesome about being a software developer, is that there are many ways to increase productivity. That’s code for “low floor, high ceiling”. The human brain is very good at subconsciously leaning on its past experiences and hiding the complexity of every-day tasks. The list of things you have to know to accomplish even the simplest programming task is extensive. For example, you just put up a barebones html page? Well, first you had to understand HTML, obviously. But also, you had to learn how to use a text editing program, understand how web servers work, realize how URL resolution works and that a browser is a gateway for that, and understand how to use a browser (and the underlying OS, for that matter). During the process of writing the HTML page, probably none of that crossed your mind. You were probably thinking about your next page, because there was nothing there that your brain hasn’t already committed to memory and repeated a hundred times already. That productivity… your ability to ignore the simplicity of your current task and focus on something near the threshold of your knowledge… was born from your experience. But why did you choose to learn those tasks instead of others? It begs the question: how can I improve in the fastest way possible?

Well, the first tool you’ll need is an awareness of as many of the paths to improvement as you can get. Here is a non-exhaustive list:

General principles: SOLID, DRY, YAGNI, etc.
High level concepts: Which patterns combine to solve a given problem best? Which database best fits the data modeling, performance, and interop requirements for your project? Which development process is going to provide the best combination of productivity, value to clients, realistic estimations, and employee satisfaction? This is probably the aspect that’s most correlated with experience.
Tools: source control client, IDE, refactoring tools, plugins, text editor, various supplemental editors, database client, VPN client, IM client, email client, command line client, various browsers, image editor, screen-sharing software, video conferencing software, various system administration tools, decompilers, numerous web tools and associated accounts, merge tool
Languages: The concepts of how they differ and how to take advantage of that power.
Best Practices: Can apply to almost anything and doesn’t remain constant over time.
Libraries/Frameworks: What are the pros and cons of various competing libraries? Pros and cons of frameworks vs libraries?
APIs: Google is great, but having a strong memory of APIs will always help.
Continual learning: No matter how much you know, there will always be many more things that you don’t know. First, building a willingness to continually learn is important. Also, targeting the most pertinent information.
Soft skills: personal interaction, requirement gathering, asking the right questions, leadership, etc

Now that we have that out of the way, back to the question: “how can I get better in the fastest way possible?”. I’m sure you saw this coming… it depends. The law of diminishing returns plays a key role. Also, more general skills are more likely to be applicable in any given situation. I feel like the question might be impossible to answer in any meaningful way (and likely that I’m not qualified to answer it). Instead, it’s probably more helpful to point out a few situations I’ve encountered where the results were better than expected.

An Argument for Making Common Tasks as Painless as Possible

What I’ve noticed many times is that good developers often create bad code. Of course, the reasons are many… deadlines, lack of focus, you were concentrating on the other 20 aspects of the problem that you nailed, learning for the 80th time that you need to review your own code… the list goes on and on. I feel like there is something else that oftentimes comes into play though- developers that consciously realize the way they should do something, but instead decide to take a route that is quicker for them. The “for them” is important here. Quickness is a relative concept. If something is quick, humans are more likely to do it. We like doing things quickly. You can’t fight human nature. So what can we do? Make the right choice the quick choice.

The general principle can apply in many ways… it could be as simple as learning to type faster. Here is an example on how it applied to me: I have primarily developed web applications in C# and Javascript in the past 5 years. I typically use a combination of Visual Studio and SublimeText. I’m a big fan of a refactoring plugin for Visual Studio called ReSharper. Why? Because it’s very good at making the right choice and the quick choice the same choice. For example, I know the numerous benefits of the Single Responsibility Principle, but what goes on in my head when I need to implement new functionality is a cost-benefit analysis comparing options:

1. Create a new class whose only reason to change is a different way to do X, where X is the functionality I’m implementing.
2. Add functionality X to an existing somewhat-related class.

What we want to do here is lower the time component on the better option (1) so that you’re more likely to choose it. ReSharper will allow me to write a method and then highlight it, and select “extract class”.

The gap between the right choice and the quicker choice just got significantly smaller. It’s very tempting to look at ReSharper as a tool that just “helps you type” and discount the psychological aspects of how, in practice, it will result in better code. ReSharper “helps you type” in the same way that a vehicle “helps you travel”.

An Argument for Using a Keyboard as Often as Possible

Typing is easier than clicking. Humans just aren’t as effective at clicking. Even if we ignore that, switching between typing and clicking has a non-zero cost (not to mention annoyance factor). Given that we must type in order to develop software, it seems clear that using the keyboard for as much as possible has some potential to increase productivity. Just like the previous example, this isn’t just about saving a few seconds here and there. It’s about changing your decision process towards better outcomes. Here are a few steps you can take to get closer to full keyboard usage:

1. Learn your browser of choice’s shortcuts. Once you know how to do that, you can easily find out any other shortcut you need by googling them as you come across the need to use them. One tool I use here so that I can navigate without going to my mouse is Vimium, which is a browser plugin that has a few killer features:
   • click f to bring up a tooltip on every html element that has clickable behavior by default whose content is a series of characters that you can type in order to “click” it
     

   • click b to wildcard search through your bookmarks by name or URL
     

2. Put your keyboard in your lap.

3. Slide your seat away from your mouse and trackpad.

That’s it. By sliding away, you’ve increased the cost of using the mouse. Now your decision process will lean towards learning shortcuts instead of going to the enemy (the mouse). Feel free to take things as far as is reasonable. You can employ tools like ReSharper, CLI, OS shortcuts to launch programs, AutoHotkey, and numerous others to help. Personally, I feel significantly more productive using just my keyboard. You’ll find that tasks you used to think needed a mouse, simply don’t.

The Cost of Context Switching

Wikipedia defines context switching as “the process of storing and restoring the state (more specifically, the execution context) of a process or thread so that execution can be resumed from the same point at a later time”. Humans are bad at multitasking. When you multitask, you’re effectively lowering the degree of problem that you’re capable of solving.

So, how can we best minimize the amount of context switches we’re subjected to? It’s a broad question, but here are some instances of context switches that are fairly common: meetings, instant messages or phone calls that require some amount of thought, urgent emails, switching programming problems, and coworkers walking to your desk. Developers typically don’t have a lot of control over most of that list (although you should speak to the people who do have control), but here is one way that I’ve found that I can have an impact: meetings.

I try to limit the amount of meetings that I have on my calendar. One not-so-obvious way that I minimize my meeting time is by being more efficient at meetings. A primary cause for meetings is that a previous meeting was performed inefficiently. What does an efficient meeting look like? In my experience, it exhibits these traits:

• Has a clearly defined scope
• Attendance is limited to only people that are absolutely necessary (and no less)
• All attendees have the context they need to mentally prepare for the content of the meeting
• An unofficial mediator (which can be you) to deflect conversations that get off topic
• Produces a list of action items, when they will be done, and by whom
• Takes up no more time than is absolutely necessary

Make sure meeting invites give sufficient information for mental preparation. Be a mediator. Review action items at the end of the meeting. Do everything possible to prevent any need to follow up. Gently ask if the scope of attendees could be smaller.

Wrapup

Constant experimentation is the key to unlocking what works best for you. Always take time to reflect on how you can improve. When you try something new, reflect on why it worked well or didn’t. What you learn can be helpful in coming up with new strategies.