Guess I’ll go for ‘Now’.

I recently finished my latest web project. It’s an MD5 hash generator. It’s nothing fancy – just a quick and dirty MD5. But if you need something one way hashed, it will do the trick for you.

I need to build some links so it will rank on GOOG. I also need to add some ads so it will make me some $$.

If you’re a sw developer, please don’t store passwords in plain text. MD5 is one method many people employ to avoid this. It’s not the best, but it’s one of the most common.

1) Begin with a clear goal.

Software developers often work from vague specifications. We’re used to it. It doesn’t surprise us. We’re also used to reworking the products of vague requirements.

In software development, ‘firming up the spec’ is one step that’s going to happen. The question is when. It can happen on purpose at the beginning of the project. This rarely happens. When it does, it usually leads to a smooth implementation with a good final product. Let’s call this scenario ‘focused execution.’

It can happen incidentally during the course of the project. This is more likely. This usually leads to some rework, some wasted effort, but an acceptable product. Often the product can be improved in the future. Let’s call this scenario ‘incremental improvement.’

It can also happen at the end of the project. This can go two ways. One is, “We should have done x. After all that effort, it’s finally clear what we should do. Great – let’s do it.” The result is lots of wasted effort, lots of rework, but often a good (but late) product. Let’s call this scenario ‘do-over.’ It’s fairly common in the software business.

The other way ‘firming up the spec’ can happen at the end of the project is, “We should have done x. Too late. Let’s just give up on the whole thing.” This is also common. It happens all the time in undisciplined software shops. After all that time and effort, it’s finally clear what everyone wants. And it’s too late. Let’s call this scenario ‘regret’.

The same is true in life. If you invest the effort to clarify your goals (focused execution), you can avoid the wasted effort of do-overs and the pain of regret. Note: this doesn’t mean you won’t make some adjustments as you learn more (i.e. incremental improvement). In life as in software development, things seldom work exactly as planned. But generally speaking, the clearer and earlier you make your goal, the better your result will be.

2) Setup your environment.

For a long time, when I began a project, my inclination was to just start with no planning or preparation. I didn’t like configuring my editor, arranging my files, setting my OS settings, etc. I would often use whatever tools were installed by default (think notepad editor).

I used to do the same thing on physical projects. Instead of taking the time to get out a ladder, I’d spend twice that time installing a light from a too-short chair. Instead of retrieving a real screwdriver, I’d labor away with my swiss army knife, jabbing my hands every few seconds. All that to avoid a few minutes to retrieve the right tools. That was foolish.

I no longer do that. Now, I’ll take the time to acquire and configure good tools and arrange my work space. The productivity gains far outweigh the time invested in setting up. Work is easier and more enjoyable that way, too.

3) Tighten your feedback loop.

Software development is heavy on experimentation. So is life. There is a lot of ‘test – observe – correct – repeat’. You need to know if what you’re doing is getting you closer to your goal. The sooner you can enter this loop, the sooner you can begin correcting course where necessary. The tighter you can get this loop, the faster your work will go.

I’ve worked on projects where (largely for security reasons, but also for bureaucracy reasons) this debug loop was painfully slow. There were many barriers that inhibited me from testing my work quickly. This created a big gap between the ‘correct’ and ‘test’ items in my loop. That gap makes it difficult to create momentum toward the goal.

That’s no way to work. Now, whenever possible I write a pushbutton script (basically a program that tests my work and tells me whether it’s correct) to test my work for me. This way, I know almost immediately whether my changes produced the desired effects. I might complete 20 debug loops per hour this way.

Life is like that also. If your goal is to improve your health, you might begin by switching your exercise from walking to swimming. Or maybe you replace your morning cereal with a protein shake. Or maybe you go to bed 1 hour earlier. Regardless, if you have to wait months between appointments for a doctor to tell you how it’s working, it’s going to be a long process of experimenting to find an optimal solution for you.

Instead of waiting for your doctor for feedback, what if you bought a fat caliper and measured your body fat percent periodically? Or maybe you could track your resting heart rate? Whatever metric you’re trying to optimize, the shorter your feedback loop, the sooner you can correct where necessary.

Note: this doesn’t mean that all feedback must be acted upon immediately. Some things take time to work. You may have to persist through a period of recalibration. That’s fine. The point is that by working in this tight loop you have the information to decide if a correction is in order.

4) Get started.

In software development, there are many distracting tasks that – while moderately productive – are not the best use of time. There’s always something else to do instead of actual work – something that gives the illusion of moving you closer to your goal. There’s another article to read about how to do whatever it is you’re trying to do. Or some email to process. Or some meeting to attend. There’s always that temptation to avoid starting.

The best engineers I know avoid this temptation. Every day they sit down and open their editors and get started.

Until you’ve begun, inertia is your enemy. If you want to achieve your goal, you must defeat that inertia every day by getting started. And every time you defeat it, it becomes easier to defeat it the next time. Soon, you’ve developed the habit of getting started. Also, after you get started inertia is working for you instead of against you. It’s easier to keep making progress than to stop. Inertia has become your ally.

Conclusion

Put all this together – clear goals, conducive working conditions, tight feedback loop, and positive inertia – and you will be a productivity machine.

Do you use Tortoise as your Subversion client? Does it complain about eol style every time you try to add a file to your repository?  I have a fix for you.

In your c:\documents and settings\[YourUsername]\Application Data\Subversion there should be a file named config.  Open it in a text editor.  There should be a section named [auto-props].  It’s probably toward the bottom.  In that section, add a line like this:

*.cs = svn:eol-style=native

where cs is your file extension.  You’ll want to do it for you file type (cpp, html, pas, h, whatever).  Save the file.  It should no longer hassle you about eol-style when adding files.  

Don’t do it for binary file types.  Also, understand why you shouldn’t.

This assumes a default installation.

Some time ago, I was building some modules for a Drupal project.  I wanted an easy way to control whether a particular module was displayed for a particular content item – a way of dynamically determining module visibility per page/post/whatever.  I searched high and low and couldn’t find anything, so I wrote it myself.  Some of you may be struggling the same way, so below is how I did it.

1. Activate the taxonomy module (it’s part of the core install and may already be enabled for you).
2. In the administration area, content management, taxonomy, create a new vocabulary.  Add a term to this vocabulary for each module for which you want to control visibility.  For example, if you’ve written modules DoIt and DoItAgain, I’d add terms ‘Do It’ and ‘Do It Again’ without the single quotes.
3. Choose the content type for which you want this vocabulary to be available.  Make the vocabulary a multiple select.
4. Download, install, and enable taxonomy hide module.
5. In the taxonomy hide module settings, choose the vocabulary you created above.  This will prevent those annoying term tags from displaying on your content.
6. Editing the content that should display your modules. You’ll have a multiple select list with all your taxonomy terms listed.  Choose the modules you want to display (i.e. ‘Do It’ and ‘Do It Again’) on each particular content item.
7. In your module code, add this method:
   /**
   Examines the taxonomy of the calling node to determine if a module should be displayed.
   *
   @param string $moduleLabel The taxonomic label the module requires for display.
   @return true if the node is labeled with $moduleLabel, false otherwise
   */
   function _ShouldDisplay($moduleLabel)
   {
     $shouldDisplay = false;
     if (arg(0) == 'node' && is_numeric(arg(1)))
     {
       //if the arguments are legit, load up the node
       $nid = arg(1);
       $node = node_load(array('nid' => $nid));

     $terms = taxonomy_node_get_terms($node);
    //examine the terms.  If find $moduleLabel, return true;
    foreach($terms as $t)
    {
      if ($t->name == $moduleLabel)
      {
        $shouldDisplay = true;
      }
    }
  }
  return $shouldDisplay;
}

8. In your module code, in the _block method, wrap all the output inside a conditional like this:
   if (_ShouldDisplay('Do It'))
{
  //all the output work here
}
   where ‘Do It’ is the taxonomy term you defined for this module above.
9. Save your module.
10. In the blocks screen, drag your block module to a region (left sidebar, content, footer, etc.)

Now, when a content item is requested, your module will check the taxonomy terms for that content item.  If your module’s term is listed in the terms, your module will display.  If not, it won’t.