Hints for Self Management

In spite of the micromanagement horror stories that regularly appear on the whole IT is very self-managed.  Unfortunately, most of emerge from the university with little more than “Introduction to Management”.  Until the schools start addressing that shortfall here’s a crash course.

Peter Drucker in his classic work The Practice of Management identifies 5 key areas of management*.  Here is that list (minor modifications) with thoughts on application to self-management.

1) Set Objectives

Software systems typically start out a mess—and get worse over time.  One of the reasons is that so much is done for the short term with little long-term focus.  Force yourself out of that mold.  Look ahead 3 to 5 years.  Use designs that anticipate needs for change.  Refactor and fix old code.  Think long horizons.  Daily objectives are fine—but it’s better to think of accomplishments in 3 to 6 month time segments.


2) Organize

If you work in a typical corporate IT shop, you are probably equipped with some sort of automated to-do list.  (They go under a dozen names—ticket system, request system, etc.)  It is tempting to think that the system alone will organize your work.  While useful, it certainly will not organize.

First, users don’t report everything.  At best the system will contain only a slice of your user’s real needs.  Furthermore, if you have much of a backlog, much of that slice may be out of date.  Simply pulling the highest priority request does not mean you’re fulfilling the user’s real needs.  If at all possible, get to know the users and what they are trying to accomplish personally.  Then pick what you work on accordingly.  Every minute spent understanding the world from their perspective will pay back in hours.


Once I spent weeks coding a piece of functionality.  After a few days I began to wonder if it really made sense—but it was requested so I proceeded.  I finished it up and demoed it to the primary user.  She looked up and me and said “You aren’t going to like this”.  Yes—you guessed it–two weeks work, completely thrown out.


In addition to incompleteness, automated systems come up with a random ordering of requests are not technologically related.  (Even if categorized—the categories are the users, not yours)  Technological schizophrenia results in high context switching costs and high costs from lack of learning–you never work at anything long enough to learn it deeply enough to do a quality job.  User requests must be groups into technically logical units and worked on in concert.  However, this must be compatible with the user’s goals—another reason to take the time to get to know the user community and their goals.


3) Motivate and Communicate

Software developers are notoriously poor at documentation.  One of the main problems is so much documentation is so formal.  Formal documentation is no fun to write and rapidly gets out of date.  I’ve found that informal in-code documentation and wiki sites are far more effective. 

When writing documentation—think big picture.  What does this system do?  What does this class do? Etc.  If (when) your code gets into the hands of another programmer they can always figure out the details (by reading your code), but they won’t know the reasons behind your design decisions.  Understanding how a system was shaped can really help in making decisions to modify/extend a system.  In short—don’t document code: document design.


4) Measure/Evaluation

All the great software developers are I know are pretty brutal self evaluators.    We are probably too good at self evaluating and undermine our own (and others) confidence.   Keep in mind mistakes and errors are statistically random.  Some days are going to be worse than others.  If you aren’t creating a few errors—you probably aren’t writing much code.  J

5) Personal Development

Read, read, read.  I spend my lunches reading blogs like Joel Spolsky’s at http://www.joelonsoftware.com.  Get involved in local user’s groups.  For example–my hometown’s .Net user’s group (http://www.chadnug.org).  Sometimes bosses will even let you cut back on work time to attend meetings.  J


*The Practice of Management  Page 333, 334

** For a great series on (real—not self) management in Software see Joel Spolsky articles starting with: http://www.joelonsoftware.com/items/2006/08/08.html


One Response to “Hints for Self Management”

  1. Top Posts « WordPress.com Says:

    […] Programmer: Manage Yourself In spite of the micromanagement horror stories that regularly appear on the whole IT is very self-managed.  […] […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: