The Two Keys to Programming Productivity

Occasionally other developers with whom I work will comment on my productivity. For example a couple of weeks ago, after working hard one day and delivering an urgently needed service to the team the next morning, one developer said in standup, "You're an animal. You wrote that in one day and it would have taken me two weeks to do that." I’m a little embarrassed by such comments and have often thought about what makes me or any programmer productive, so today I enjoyed reading parts of Neal Ford's book The Productive Programmer and wanted to share some thoughts on programmer productivity.

I loved the forward by David Bock of CodeSherpas. He writes, "The individual productivity of programmers varies widely in our industry. What most of us might be able to get done in a week, some are able to get done in a day. Why is that? The short answer concerns mastery of the tools developers have at their disposal. The long answer is about the real awareness of the tools' capabilities and mastery of the thought process for using them. The truth lies somewhere between a methodology and a philosophy, and that is what Neal captures in this book."

Ford suggests there are four productivity principles for programmers.

  1. Acceleration: speeding things up. Keyboard shortcuts, searching and navigation.
  2. Focus: eliminating distractions and clutter, both physical and mental.
  3. Automation: getting your computer to do more. Put your computer to work.
  4. Canonicality: doing things once in one place. Also known as DRY or Don't Repeat Yourself.

These are all good and important. For me the most important item in Ford's list is number two: focus. And I would add one more: conditioning. Focus and conditioning are the two most important keys to successfully improving your programming productivity.

Programming Productivity Key #1 – Focus

Start by eliminating mental and physical distractions. Remove the clutter from your mind and your desk, but most importantly, eliminate the distractions caused by environmental disruption. Find or create a quiet place where you can focus on the task at hand, where you can put your entire mental energy into what you are doing. Distractions are a HUGE productivity destroyer.

Cubicles are of the Devil. They may be great for a sales team or reporters who thrive on eavesdropping, but chit chat does not get code written. Cubicles foster incomplete and sporadic communication that becomes a crutch for broken requirements and shoddy analysis resulting in an unsearchable and unsellable body of knowledge persisted only in the fragile collective of a distributed and disconnected human neural network that often cannot survive the loss of one or two key nodes.

Ford suggests instituting "quiet time" where, for example, there are no meetings or email or talk during two two-hour periods each day. He claims to have tried this in one of the consulting offices where he worked and the organization found that they got more done in those four hours than was getting done in the entire day before implementing the "quiet time." This is not surprising to me at all. Ford writes, "It is tragic that office environments so hamper productivity that employees have to game the system to get work done."

While I have the luxury of working from a home office at the moment, I have worked in a number of cubicle environments in the past and probably will in the future. The most common technique I see other developers using to create their own "quiet time" is the use of a very expensive pair of noise canceling headphones piping in whatever tunes or white noise that developer finds most conductive to focusing on the task at hand. Do whatever you have to do to achieve focus.
 

Programming Productivity Key #2 – Conditioning

To play at the top of your game, you have to condition. You have to practice. You have to study. You have to prepare your body but most importantly your mind to execute. And you have to condition your attitude. You have to be excited to write code. You have to get a thrill out of making it work and work well. You have to condition your mind to expect excellence and then work to achieve that.

In conditioning, there are mechanics you must learn. Spend time studying and using your IDE's keyboard shortcuts. Regularly study and practice using the base class libraries of your platform so you don't end up wasting time writing code that a solid community or well heeled development team has already written and tested heavily for you.

More importantly, spend time reading about and learning new techniques and technologies from open source projects to gather at least a passing understanding of the problem they solve and how you might use them even if you choose not to do so. Pay attention to the patterns, the naming and organizational patterns, the logical patterns and the problem solving patterns that you find in these projects. Even if you do not use them, you will be storing up mental muscle memory that will serve you well when you need a way to solve a new problem in your own projects.

Most importantly, learn from your own work. Repeat your successes, taking patterns from your past and improving on them. Avoid your failures, being honest with yourself about what did not work in your last project and finding ways to avoid or even invert the mistakes of the past, turning them into strong successes.

Conditioning is not about solving a problem for a specific project in which you're working now. It's about preparing your mind to be at its most productive when faced with programming problems you've never seen before. It's about creating mental muscle memory that will kick into overdrive as you solve the problems you have already faced, the code spilling out of your brain through your fingers and into the keyboard.

Conclusion
No matter how fast or slow you are as a programmer, you can improve. If you improve your focus and put your body and mind through regular conditioning, you will improve. And as you improve, you'll get noticed. And as you get noticed, you'll get rewarded.

Visual Studio LightSwitch 2011 May Bridge the Gap

Microsoft announced recently that Visual Studio LightSwitch 2011 will be released on July 26. I’ve been watching the development of this product with keen interest for the last year or so. I’m looking forward to evaluating it more in-depth soon.

Building common line-of-business (LOB) applications in today’s enterprise development stacks can be too complex and too costly for today’s tight budgets. For this reason alone there are “literally millions” (exaggeration license: 02389-872.159-034) of LOB applications being created by non-programmer Office users. These “applications” most often get pushed around in Excel via Exchange. Many live in a hastily created Access database and shared clumsily and un-securely on a workgroup file server.

Still others are somewhat more sophisticated and are hosted on products such as QuickBase from Intuit. This latter category resolves many of the problems inherent in the emailed Excel spreadsheet and the Access fileshare such as security, reliability, common user interface, ease of use, etc. There are many more specialized web-based SaaS offerings that solve specific business problems. One notable vendor who led the way in this area is 37 signals.

But these solutions are not always enough to meet the needs of the business. There is a gap between these “entry-level” (ELOB) applications and what I will call primary line-of-business (PLOB) applications. The PLOB is a custom developed, sophisticated enterprise application with complex business rules, sometimes even more complex user interfaces, and far more complex data and integration requirements, upon which the business relies for its core service offering or mission critical systems.

Somewhere between ELOB and PLOB there has to be a middle ground. Let’s call it the mid-line-of-business (MLOB) application (FLA creator license: FOLK-LANG-MAKE-UPPR-WXYZ). There are plenty of “app generator” and scaffolding tools that claim to live in the MLOB space. I’ve never been too impressed with them. They always seem to lose their way in convention, diverging from business requirements too greatly to meet business needs.

So I am hopeful that LightSwitch will fill the MLOB gap. We’ll see. Time will tell. In any case, it should at least be fun to find out.

How to Manage Software Development

What the world needs is yet another blog post on how to manage software development, so why not write it myself I ask. Unable to find a good reason to stop here, I’ll give it a shot. If you continue to read, you and you alone will be responsible for anything you might learn.

There are books, graduate courses, and no end to rambling blogs, so I’ll shoot for brevity and clarity here in Part 1.

  1. Know Your Team
    Computers do not yet write software all that well by themselves, so you’re stuck managing the people. Your process or you dictate what they will work on and, by virtue of time constraints imposed, how they will work on it; this is the essence of management.
     
  2. Be Decisive and Take Action
    Collaboration is a meaningless waste of time unless it is followed by real decision and actions that lead to positive results. If you cannot make decisions and act upon them, you are a researcher; you are not a manager.
     
  3. Be Honest and Fair
    If you say one thing to your team on one day and deny having said it the next day, your team will lose confidence in you and rebuilding that trust may not be possible, so choose your words and promises carefully. And if you make a mistake, admit it readily and apologize where appropriate. Your team will see this as a mark of a true leader.
     
  4. Demand Accountability
    When you assert a process rule, enforce it. Hold team members accountable. Start with gentle reminders and further training but do not allow repeat offenders to skate without consequence. If you do, your process is not a process and it will fail.
     
  5. Eliminate Needless Meetings
    Developers generally hate meetings with good reason. Most meetings lack an agenda, lead to no discernable action items, and there is rarely a copy of the minutes minutes and action items distributed to attendees. Most software development requires long, uninterrupted periods of time to effectively solve problems and complete complex tasks. Useless meetings in the middle of the day can ruin a developer’s entire day, throwing his productivity into a spiral, so group meetings into a single day where possible to eliminate or reduce the disruptive effects.
     
  6. Review Everyone’s Work
    You may not understand the code, but having a developer walk you through the code, discussing the decisions made and showing off just a little will go a long way toward educating you and inspiring your developer. Review and discuss documentation, designs and test plans with interest. Spend the time to learn from and guide your team.
     
  7. Get Yourself Out of the Meetings Cyclone
    Decline a leadership training or management committee meeting from time to time in order to do some real managing. Remember, the word “manage” has its root in manus (hand). If you don’t put your hands on it, you can’t possibly manage it.
     
  8. Create and Shepherd Processes
    Everyone knows how to manage and can do so if you give them a process that establishes guidelines for what information should be considered, what decision making process should result, and how those decisions will become actions within the constructs of the process you have created.

Well, that’s enough for part one. More on the same topic later.

How One Meeting Can Blow A Programmer’s Whole Day

This morning I read a post by Seth Godin, a favorite of mine, which presented and discussed an essay written by Paul Graham of Y-Combinator called Maker’s Schedule, Manager’s Schedule.

I regret that this cogent essay and essayist have escaped my notice until now. It reveals what every programmer knows and has experienced with regard to meetings, and I’ve never found a better treatment of the subject.

It confirms with clarity that programming is a creative art, an act of creation or making. Such work cannot be effective and productive with multiple disruptive meetings every day. And sometimes it only takes one meeting, even a short one, to blow your whole day.

Why?

The content and contention in a single meeting can serve to distract a programmer to the point of rendering him effectively useless for the remainder of the day. This is true not only for the programmer but for anyone whose primary function is to make things of complexity.

Consider preventing the daily standup from becoming a meeting in which the resolution of identified impediments is attempted. And never allow the standup to devolve into an ad hoc project status review and planning meeting with the question, “When will you have X feature done?” being asked.

Consider piling all such meetings to which makers must be in attendance into one single day of the week, perhaps Friday or Monday to ensure the largest contiguous uninterrupted period for making, preferably in the late afternoon, so that we get every ounce of making from our makers that the company’s hard won cash can buy.

It’s more than something to think about. It’s something a manager could manage if the manager simply chose to do so, and it’s something a maker would appreciate more than can be expressed in written word.

Office Outlook Add-In Development

I’ve long been interested in building add-ins for Microsoft Office but every time I’ve started to dive into it, I’ve been repelled by the challenges of understanding the Office COM interfaces and dealing with multiple versions of Office, especially for Outlook add-ins.

All of that may be about to change. I just ran into Add-In-Express.com, a tool vendor that for whatever reason I’ve not come across until now. From what I’ve seen on their web site, I’m very impressed.

With a single VS 2010 project template, you can now create an Office add-in with wrapper support for multiple Office products and multiple versions all from one unified library.

image

They do not offer a 30-day trial, so this is a blatant attempt to convince them to give me a reviewer’s copy to install and experiment on.

My primary attraction to this toolset is that I’m not a fan of writing tedious routine plumbing code to deal with multiple versions of a product upon which my software will need to be used. This is also the primary reason I’ve avoided delving into Office add-in development beyond reaching that initial level of prohibitive frustration.

I’m particularly interested in the following feature sets and should I be granted an reviewer’s license or if not and I can scrounge up the scratch for a license, I will be putting these to the test in a rewrite and expansion of a time tracking tool that I wrote as a stand alone WinForms app about nine years ago.

Features to check out list:

  • Version neutrality—many of the users for whom I write software are institutionally stuck on old versions of Microsoft Office. They have no choice but I still need to deliver a solution to them.
  • Context sensitive toolbars and ribbons for Outlook—my primary target for an add-in host, every time I’ve read about or talked with developers who deal with writing their own multi-version plumbing, I walk away from the notion of writing the Outlook add-in I’m thinking of. I really want to see if this tool can help me overcome my fears.
  • Visual designers—one of the most exciting aspects that I want to explore in this product is the visual designers for the ribbon UI, toolbars, options and folders properties dialogs, and especially the form and view regions for Outlook.
  • Smart Tags designer—I am keenly interested in natural language processing and enhancing the utility of email by analyzing text for keywords and other language constructs and then providing context aware actions directly from the Smart Tag to allow the user to take an action that might otherwise require multiple steps from multiple applications.

If you have had any experience with this toolset, I’d like to hear from you. As soon as I’m able to get my hands on it, I will begin posting my experiences with the tool as well as deployable examples from my evaluation and experimentation.

Software Crashing

A project manager, a software architect and a programmer are on a plane heading to nowhere in particular.

Suddenly the pilots (testers of course) leave the cockpit, don the only parachutes, and jump out of the plane.

The project manager schedules an emergency landing planning meeting.

The software architect suggests the team follow a new process to avoid crashing.

The programmer disclaims responsibility and points out that automated landing was not in the requirements.

Which of these survive?

(scroll down for the answer)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

All of them. Apart from some scrapes and bruises for the testers, who take it like troopers as always, everyone is fine. The plane never left the ground. Are you kidding? No software takes off without crashing a few times first.

And sometimes, the plane really does take off. And that is why I do this.