For my solution I wanted something that behaved very similarly to the WinForms NumericUpdown control.

Some of the specifications:

1. Allows user to set Value, MaxValue, MinValue, Increment, and LargeIncrement.
2. Text directly entered is limited to numbers
3. Pasted text is not intercepted, but when the control has lost focus it will be validated and reset to the previous value if necessary
4. Two buttons, for increment and decrement
5. Holding down the buttons with the mouse causes the number to increment continuously
6. Up and down increment and decrement by Interval
7. Page Up and Page Down increment and decrement by LargeInterval
8. This version only supports integers

Creating the control

To begin, create a new WPF project and add a new User Control called NumericEntryControl. This will create a pair of .cs and .xaml files.

In the XAML file, change the <Grid> root element to be a <DockPanel>.

<UserControl 

    x:Class="NumericEntryDemo.NumericEntryControl"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 

    xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 

    mc:Ignorable="d"

    xmlns:my="clr-namespace:NumericEntryDemo" Width="200" Height="26">

    <DockPanel>

    </DockPanel>

</UserControl>

Before we add the controls, let’s add some properties to our user control to hold the values the controls will use. These are dependency properties in order to take advantage of all the WPF goodness like data binding and animation. Let’s also add standard .Net property wrappers.

public partial class NumericEntryControl : UserControl

{

    public static readonly DependencyProperty ValueProperty = 

        DependencyProperty.Register("Value",

            typeof(Int32), typeof(NumericEntryControl),

            new PropertyMetadata(0));

    public static readonly DependencyProperty MaxValueProperty = 

        DependencyProperty.Register("MaxValue",

            typeof(Int32), typeof(NumericEntryControl),

            new PropertyMetadata(100));

    public static readonly DependencyProperty MinValueProperty = 

        DependencyProperty.Register("MinValue",

            typeof(Int32), typeof(NumericEntryControl),

            new PropertyMetadata(0));

    public static readonly DependencyProperty IncrementProperty = 

        DependencyProperty.Register("Increment", 

            typeof(Int32), typeof(NumericEntryControl),

            new PropertyMetadata(1));

    public static readonly DependencyProperty LargeIncrementProperty = 

        DependencyProperty.Register("LargeIncrement",

            typeof(Int32), typeof(NumericEntryControl),

            new PropertyMetadata(5));    

    public Int32 Value

    {

        get

        {

            return (Int32)GetValue(ValueProperty);

        }

        set

        {

            SetValue(ValueProperty, value);

        }

    }

    public Int32 MaxValue

    {

        get

        {

            return (Int32)GetValue(MaxValueProperty);

        }

        set

        {

            SetValue(MaxValueProperty, value);

        }

    }

    public Int32 MinValue

    {

        get

        {

            return (Int32)GetValue(MinValueProperty);

        }

        set

        {

            SetValue(MinValueProperty, value);

        }

    }

    public Int32 Increment

    {

        get

        {

            return (Int32)GetValue(IncrementProperty);

        }

        set

        {

            SetValue(IncrementProperty, value);

        }

    }

    public Int32 LargeIncrement

    {

        get

        {

            return (Int32)GetValue(LargeIncrementProperty);

        }

        set

        {

            SetValue(LargeIncrementProperty, value);

        }

    }

}

Creating an incrementing TextBox

Add a TextBox inside the <DockPanel> and bind its text to the value we created in our control:

<DockPanel d:LayoutOverrides="Width">

    <TextBox 

        x:Name="_textbox" 

        Margin="2,0" 

        Text="{Binding Value, 

            Mode=TwoWay, 

            RelativeSource={RelativeSource FindAncestor,

                AncestorLevel=1, 

                AncestorType={x:Type my:NumericEntryControl}}, 

            UpdateSourceTrigger=PropertyChanged}" 

        HorizontalAlignment="Stretch" 

        HorizontalContentAlignment="Right" 

        VerticalContentAlignment="Center" />

</DockPanel>

This will create a TextBox that sizes itself with its parent (a feature I wanted, but is not strictly necessary) and  its text will be bound to the Value in our UserControl.

Handling text input

It used to be that you pointed with a mouse and entered text with a keyboard. However, it is common now to enter text with a stylus, gestures, or some future method not invented yet. Thankfully, WPF supports generic text input handling so you don’t have to concern yourself with the specific hardware.

public NumericEntryControl()

{

   InitializeComponent();

   _textbox.PreviewTextInput += 

        new TextCompositionEventHandler(_textbox_PreviewTextInput);

}

void _textbox_PreviewTextInput(object sender, 

                   TextCompositionEventArgs e)

{

    if (!IsNumericInput(e.Text))

    {

        e.Handled = true;

        return;

    }

}

private bool IsNumericInput(string text)

{

    foreach (char c in text)

    {

        if (!char.IsDigit(c))

        {

            return false;

        }

    }

    return true;

}

This prevents anything except numbers from being entered, whether via character recognition or keyboard. It does not, however, prevent the user from pasting non-numeric text into the box. We’ll handle that later.

Validating Text input

It’s problematic to validate and correct user input as they are entering it. For example, if you set the MaxValue to 100, then every time you enter 1000, it jumps to 100, it can be jarring. It’s a similar situation with text pasted into the control. What the NumericUpDown control does is handle these sort of situations when the control loses focus.

To prepare for this, when the control gains focus, we need to save the last valid value so we have something to restore to.

When the control loses focus, we need to first verify that it is a number and if so, clip it to the bounds of our MinValue and MaxValue. If anything fails, set it back to the previous value.

public partial class NumericEntryControl : UserControl

{

    private int _previousValue = 0;

    public NumericEntryControl()

    {

        InitializeComponent();

        _textbox.PreviewTextInput += 

            new TextCompositionEventHandler(

                _textbox_PreviewTextInput);

        _textbox.GotFocus += 

            new RoutedEventHandler(_textbox_GotFocus);

        _textbox.LostFocus += 

            new RoutedEventHandler(_textbox_LostFocus);

    }

    void _textbox_GotFocus(object sender, RoutedEventArgs e)

    {

        _previousValue = Value;

    }

    void _textbox_LostFocus(object sender, RoutedEventArgs e)

    {

        int newValue = 0;

        if (Int32.TryParse(_textbox.Text, out newValue))

        {

            if (newValue > MaxValue)

            {

                newValue = MaxValue;

            }

            else if (newValue < MinValue)

            {

                newValue = MinValue;

            }                

        }

        else

        {

            newValue = _previousValue;

        }

        _textbox.Text = newValue.ToString();

    }

}

Handle arrow keys

Just because WPF can handle text input from a variety of sources in a hardware-agnostic way doesn’t mean we should ignore the particular strengths of the keyboard. Specifically, we should handle the up and down arrows.

public NumericEntryControl()

{

    ...

    _textbox.PreviewKeyDown += 

        new KeyEventHandler(_textbox_PreviewKeyDown);

}

void _textbox_PreviewKeyDown(object sender, KeyEventArgs e)

{

    switch (e.Key)

    {

        case Key.Up:

            IncrementValue();

            break;

        case Key.Down:

            DecrementValue();

            break;

        case Key.PageUp:

            Value = Math.Min(Value + LargeIncrement, MaxValue);

            break;

        case Key.PageDown:

            Value = Math.Max(Value - LargeIncrement, MinValue);

            break;

        default:

            //do nothing

            break;

    }

}

private void IncrementValue()

{

    Value = Math.Min(Value + Increment, MaxValue);

}

private void DecrementValue()

{

    Value = Math.Max(Value - Increment, MinValue);

}

IncrementValue() and DecrementValue() are pulled out as their own method because they’re used in the button-handling code as well (see below).

The code so far is a perfectly usable textbox that accepts only numbers and can be incremented using the keyboard. Typically, however, we also need to support the mouse, and for that we need buttons (unless you want to do something exotic like programs like Photoshop and Lightroom do, where text boxes have support for incrementing gestures—that’s another article).

A button you can hold down

Adding buttons to increment once per click is pretty easy, but we really want to be able to hold down the buttons and have the TextBox increment. Let’s start by adding the XAML for the buttons:

<UserControl 

    x:Class="NumericEntryDemo.NumericEntryControl"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 

    xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 

    mc:Ignorable="d"

    xmlns:my="clr-namespace:NumericEntryDemo" 

    Width="200" Height="26"

    >

    <DockPanel d:LayoutOverrides="Width">

        <Button x:Name="buttonDecrement" 

                DockPanel.Dock="Left"

                Content="-" 

                Width="{Binding ActualHeight, 

                    ElementName=buttonDecrement, Mode=Default}" 

                Height="{Binding ActualHeight, 

                    ElementName=_textbox, Mode=Default}"/>

        <Button x:Name="buttonIncrement" 

                DockPanel.Dock="Right" 

                Content="+" 

                Width="{Binding ActualHeight, 

                    ElementName=buttonDecrement, Mode=Default}" 

                Height="{Binding ActualHeight, 

                    ElementName=_textbox, Mode=Default}"/>

        <TextBox 

            x:Name="_textbox" 

            Margin="2,0" 

            Text="{Binding Value, 

                Mode=TwoWay, 

                RelativeSource={RelativeSource FindAncestor,

                    AncestorLevel=1, 

                    AncestorType={x:Type my:NumericEntryControl}}, 

                UpdateSourceTrigger=PropertyChanged}" 

            HorizontalAlignment="Stretch" 

            HorizontalContentAlignment="Right" 

            VerticalContentAlignment="Center" />

    </DockPanel>

</UserControl>

Note that the button Width property is  bound to its own ActualHeight property, and the Height property is bound to the TextBox’s ActualHeight. This has the effect of keeping the buttons square, the same height as the TextBox. It’s an effect I wanted, but you can easily dispose of it. With these buttons, our control finally takes shape:

How fast should we increment?

Before writing the code to do the incrementing as we hold the button down, it’s worth considering how fast the incrementing should occur. Ideally, we would want it to increment at about the same rate as if we were holding down the up key on the keyboard. The keyboard repeat rate is an operating system value that we can retrieve.

There are actually two values:

private static int _delayRate = 

    System.Windows.SystemParameters.KeyboardDelay;

private static int _repeatSpeed = 

    Math.Max(1, System.Windows.SystemParameters.KeyboardSpeed);

The delay rate is how long we should wait before starting the repetition, and is given in multiples of 250ms. Roughly speaking, humans can determine and control actions with lengths of time of about 200ms, so 250ms is a good value to start with. Any shorter and the repetition might start when it was not intended (say, if they just click the button instead of holding it down).

The keyboard speed is the number of times per second we should repeat—sort of. The value can be 0, so because of the way I use it below I want to sure it’s at least 1.

To allow us to hold the button down, we need to override the default mouse handling of a button which is to disable the standard LeftMouseButtonDown/Up messages. Instead, we need to handle the PreviewMouseLeftButtonDown message and its corresponding Up message.

When we handle the down message, we need to set a timer for the keyboard delay value. When we handle the timer’s tick, we need to increment (or decrement) and change the timer’s interval to the repeat speed. This repeat speed is calculated merely by dividing 1000ms (1s) by the rate per second. There may be better ways, but this gets pretty close to the rate experienced by the keyboard on my computer. Finally, when the mouse button is released we need to stop the timer. We also do a final increment, which will cover the case where the user clicks instead of holds.

We also need to capture the mouse in case the user moves it off the button—otherwise the timer will just keep incrementing forever.

Here’s the code:

private DispatcherTimer _timer = 

    new DispatcherTimer();

private static int _delayRate = 

    System.Windows.SystemParameters.KeyboardDelay;

private static int _repeatSpeed = 

    Math.Max(1, System.Windows.SystemParameters.KeyboardSpeed);

private bool _isIncrementing = false;

public NumericEntryControl()

{

    ...

    buttonIncrement.PreviewMouseLeftButtonDown += 

        new MouseButtonEventHandler(

            buttonIncrement_PreviewMouseLeftButtonDown);

    buttonIncrement.PreviewMouseLeftButtonUp += 

        new MouseButtonEventHandler(

            buttonIncrement_PreviewMouseLeftButtonUp);

    buttonDecrement.PreviewMouseLeftButtonDown += 

        new MouseButtonEventHandler(

            buttonDecrement_PreviewMouseLeftButtonDown);

    buttonDecrement.PreviewMouseLeftButtonUp += 

        new MouseButtonEventHandler(

            buttonDecrement_PreviewMouseLeftButtonUp);

    _timer.Tick += new EventHandler(_timer_Tick);

}

void buttonIncrement_PreviewMouseLeftButtonDown(

    object sender, MouseButtonEventArgs e)

{

    buttonIncrement.CaptureMouse();

    _timer.Interval = 

        TimeSpan.FromMilliseconds(_delayRate * 250);

    _timer.Start();

    _isIncrementing = true;

}

void buttonIncrement_PreviewMouseLeftButtonUp(

    object sender, MouseButtonEventArgs e)

{

    _timer.Stop();

    buttonIncrement.ReleaseMouseCapture();

    IncrementValue();

}

void buttonDecrement_PreviewMouseLeftButtonDown(

    object sender, MouseButtonEventArgs e)

{

    buttonDecrement.CaptureMouse();

    _timer.Interval = 

        TimeSpan.FromMilliseconds(_delayRate * 250);

    _timer.Start();

    _isIncrementing = false;

}

void buttonDecrement_PreviewMouseLeftButtonUp(

    object sender, MouseButtonEventArgs e)

{

    _timer.Stop();

    buttonDecrement.ReleaseMouseCapture();

    DecrementValue();

}

void _timer_Tick(object sender, EventArgs e)

{

    if (_isIncrementing)

    {

        IncrementValue();

    }

    else

    {

        DecrementValue();

    }

    _timer.Interval = 

        TimeSpan.FromMilliseconds(1000.0 / _repeatSpeed);

}

And voila! A NumericEntryControl that’s basic and easy-to-use for both keyboard and mouse.

Further improvements

This isn’t the last word in numeric entry controls, by any means. There are many ways to accomplish it, and this is one that worked well for me. There are a number of further enhancements you could do (and perhaps should do):

• More validation
• Ensure that MaxValue >= MinValue
• Set focus to the TextBox when the control gains focus (maybe)
• Define strokes to increment and decrement with a stylus
• The user can change the keyboard repeat rate through Control Panel. This program could be modified to listen for updates to this value.

There’s also another, really cool feature that I will add to this in a future post.

Download full source.

Found this article helpful? Want a resource of hundreds of similar, how-to tips? I’ve written a book that covers topics like this and more in C# 4. Check out C# 4.0 How-To!

My first book, C# 4.0 How-To is now shipping! If you like tips you can use, check it out!

From everything I’ve read, people who have suffered through the WPF learning curve have this to say, more or less:

yeah, it was really tough going for a few months. But now I can create awesome apps in a fraction of the time it would take with older technologies.

So with that in mind, I really do want to learn WPF. I have a number of C# references, weighty tomes that bend my shelves, but the main book I use is Programming WPFby Chris Sells and Ian Griffiths. I really like this book—it goes in deep. However, I realized that reading through it cover to cover and doing all the sample apps wasn’t going to work—it gets boring, no matter how good the book is. So here is my recommendation on how to learn WPF (and it probably applies to any programming technology):

1. Start reading the book, do the code, type stuff in, copy it, tweak it. Do this for as long as you can.
2. Once step 1 becomes boring, STOP. It is not productive to force yourself through the whole thing like this.
3. Find a sample project in your target technology. I used Family.Show. There are plenty out there.
4. Think of a project YOU find interesting that would be good in [WPF|other]. Start doing this. Even if you don’t know where to start at all.
5. While getting started, every step will be a challenge. Figure it out step-by-step, going back to the book and online resources.

You might be tempted to skip steps 1-2. I think this is a bad idea. You need at least some foundational understanding. Only when you can’t take it any more and you’re in danger of quitting, move on.

This has worked well for me in learning WPF. I decided to implement a game (if it ever gets into a polished state, I’ll share it).

Don’t underestimate the challenges in step 4, though. I had to think about how to even start, going back to the book numerous times, reading large sections. I looked up articles online about patterns and WPF, user controls, and more. Many seemingly-small steps in just displaying windows took hours to figure out. Figuring out data binding (really figuring it out in the context of my app) took hours. The point of doing your own project isn’t because it’s easier than following the book—it’s because it’s fun and you have more motivation to learn.

My first book, C# 4.0 How-To is now shipping! If you like tips you can use, check it out!

Here’s a brief run-down of my initial experience with it.

Installation

There is no installation file—everything is packaged into a zip. After running, I was greeted by a project selection screen, in which I created a new project and added some assemblies.

Analysis

Once you have all the assemblies you want to analyze selected, you can run the analysis, which generates both an HTML report with graphics, and an interactive report that you can use to drill down into almost any detail of your code. Indeed, it’s almost overwhelming the amount of detail present in this tool.

One graph you see almost immediately is Abstractness Vs. Instability.

This is a good high-level overview of your entire project at the assembly level. Basically, what this means is that assemblies that are too abstract and unstable are potentially useless and should be culled, while assemblies that are concrete and stable can be hard to maintain. Instability is defined in the help docs in terms of coupling (internal and external), while abstractness is the ratio of abstract types to total types in an assembly.

This is followed by the dependency graph:

After these graphics come lots of reports that dig into your code for all sorts of conditions.

For example, the first one in my report was “Quick summary of methods to refactor".” That seems pretty vague, until you learn how they determine this. All the reports in NDepend are built off of a SQL-like query language called CQL (Code Query Language). The syntax for this is extremely easy. The query and result for this report are:

With very little work on my part, I instantly have a checklist of items I need to look at to improve code quality and maintainability.

There are tons of other reports: methods that are too complex, methods that are poorly commented, have too many parameters, to many local variables, or classes with too many methods, etc. And of course, you can create your own (which I demonstrate below).

Interactive Visualization

All of these reports are put into the HTML report. But as I said, you can use the interactive visualizer to drill down further into your code.

The first thing you’re likely to see is a group of boxes looking like this:

These boxes show the relative sizes of your code from the assembly level down to the methods. Holding the mouse over a box will bring up more information about the method. You can also change the metric you’re measuring by—say to cyclomatic complexity.

Another view, perhaps the most useful of all is the CQL Queries view. In this, you can see the results from all of hundreds of code queries, as well as create your own. For instance, I can see all the types with poor cohesion in my codebase:

In this view, the CQL queries are selected in the bottom-right, and the results show up on the left. The metrics view highlights the affected methods.

Creating a query

Early in the development of my project, I named quite a few classes starting with a LB prefix. I’ve changed some of them, but I think there are still a few lying around and I want to change them as well. So I’ll create CQL query to return all the types that begin with “LB.”

   1: // <Name>Types beginning with LB</Name>

   2: WARN IF Count > 0 IN SELECT TYPES WHERE 

   3:  NameLike "LB" AND     

   4:  !IsGeneratedByCompiler AND 

   5:  !IsInFrameworkAssembly     

That’s it! You can see the results to the right. It’s ridiculously easy to create your own queries to examine nearly any aspect of your code. And that’s if the hundreds of included queries don’t do it for you. In many ways, the queries are similar to the analysis FxCop does, but I think CQL seems generally more powerful (while lacking some of the cool things FxCop has).

VS and Reflector Add-ins

NDepend has a couple of extras that enable integration of Visual Studio (2005 and 2008) and NDepend and Reflector. When you right-click on an item in VS, you will have some additional options available:

Clicking on the submenu gives you options to directly run queries in NDepend. Very cool stuff.

Summary and where to get more info

If you are at all interested in code metrics, and how good your code is behaving, how maintainable it is, you need this tool. It’s now going to be a standard part of my toolbox for evaluating the quality of my code and what parts need attention.

If you’re using NDepend for personal and non-commercial reasons, you can download it for free. It doesn’t have all the features, but it has more than enough. Professional use does require a license.

One of the things I was particularly impressed with was the amount of help content available. There are tons of tutorials for every part of the program.

I’m going to keep playing with this and I’m sure I’ll mention some more things as I discover them. For now, NDepend is very cool—it’s actually fun to play with, and it gives you good information for what to work on.

Links:

• NDepend homepage
• NDepend metrics explanation

I’ve been working on a project using Visual Studio Tools for Office 2008 (VSTO) and at one point I needed to get the colors for categories in Outlook 2007. There are actually 3 colors, and they are returned as uint’s–why the .Net wrappers don’t convert to colors for you, I don’t know (to avoid linking to System.Drawing?).

The important thing is to convert them into the friendly System.Drawing.Color objects I know and love. For this task, there exists a handy ColorTranslator class. There is a FromOle method that does the exact chore you need. Here’s a sample of my code:

   1: private void GetCategoryColors()

   2: {

   3:     foreach (OutlookLib.Category category in

   4:         Application.ActiveExplorer().Session.Categories)

   5:     {

   6:         CategoryColor color = new CategoryColor(

   7:             ColorTranslator.FromOle((Int32)category.CategoryGradientTopColor),

   8:             ColorTranslator.FromOle((Int32)category.CategoryGradientBottomColor),

   9:             ColorTranslator.FromOle((Int32)category.CategoryBorderColor));

  10:         _categoryCollection[category.Name] = color;

  11:     }

  12: }

I’ve also seen reports that it could be an error while running IE7 in Protected Mode. There’s a thread in the Microsoft forums about this.

Good luck.

If you are following the instructions to build log4cxx 0.10 in Visual Studio 2005, and you have the Windows Platform SDK v6.0 installed, you may get errors compiling multicast.c in the apr project.

I found the solution, and it’s pretty easy. Open up multicast.c and edit the lines:

136: #if MCAST_JOIN_SOURCE_GROUP

148: #if MCAST_JOIN_SOURCE_GROUP

to be, instead:

136: #if defined(group_source_req)

148: #if defined(group_source_req)

e voilà! now it compiles.

This release of Virtual PC 2007 SP1 provides updates to existing features and introduces support for the following:

• Windows Vista with Service Pack 1 (SP1) Business, Ultimate, and Enterprise operating systems as a host operating system

• Windows Vista with SP1 Business, Ultimate, and Enterprise as a guest operating system

• Windows Server 2008 Standard as a guest operating system

• Windows XP with Service Pack 3 as both a guest and host operating system

• Read The Virtual PC Guy’s Weblog
• If you need, say, two virtual machines, one with Windows Vista and one with Windows Vista SP1, install Vista onto a new machine, then copy the machine files and install SP1 on one copy–much faster than installing Vista twice.
• Need a screen shot of what’s in the virtual machine? Look at the Edit menu and choose “Select All” then “Copy”–a bitmap of the VM window will be on the clipboard. (This is how I got the capture of my BASIC graphics output from a previous post).

Problem: Visual Studio 2005 solutions no longer open when you double-click them in Windows Vista. In fact, when you double-click nothing happens.

Solution: Change them to open with Visual Studio 2005 directly instead of the vslauncher.exe (which opens up the solution with the correct version of Visual Studio if you have more than one).

Caveat: Only makes sense if  you use only Visual Studio 2005.

How-to:

1. Right-click on a solution file.
2. Choose “Open With…”
3. Choose “Browse…”
4. Browse to file “C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe” (or wherever you installed Visual Studio)
5. Click “Open” button
6. Check “Always use the selected program to open this kind of file”

Now your solutions will load Visual Studio, bring up the UAC prompt, and it all works great.

Found via here and here.

Enter SyncMyCal. It’s easy, it’s cheap (only $25), and you can try for free. I rarely have duplicated events, and I don’t have to think about it ever–it just WORKS.

How it works: SyncMyCal synchronizes an Outlook calendar with a Google calendar. First I created a Google calendar, then I set up SyncMyCal on both work and home computers. I set the home computer to take priority in conflicts, but at work I set the Google calendar to take priority over Outlook–this way there’s a hierarchy of priority that helps to prevent unresolvable conflicts and duplicates.

I bought it days before Google released their Outlook sync tool, but SyncMyCal can do a lot more and I don’t regret the purchase one bit.

The latest version also syncs contacts, but I haven’t used that yet.

My first book, C# 4.0 How-To is now shipping! If you like tips you can use, check it out!

Definition

Any discussion of time-wasting is profitless unless you define what wasting time is. My definition is:

Wasting time is doing anything that does not contribute to my goals.

That is a very broad definition, but it is very useful. It presupposes a goal-oriented mind set and I don’t want to get too far down that path here. If you’re really interested in a goal-focused system, I highly encourage you to read The 7 Habits of Highly Effective People, which is a principles-based approach to effectiveness and goal-setting is a huge part of it.

Whatever your personal system, much of the corporate world and building software specifically revolves around goals (aka “milestones”, “targets”).

This definition includes taking breaks and eating lunch, but let’s not be silly–we’re not talking about that and I’m not going to water down the definition nor am I going to spend pages talking pointlessly about exceptions to it. We’re all intelligent people here and can understand the important principles.

Many Small Goals Are Better Than One Large One

Software development processes have been undergoing evolution since the beginning and lately the whole agile process seems to be taking over. Whatever the process, many companies are finding more success in breaking down large projects into tiny goal-driven chunks, sometimes lasting as little as a week.

This same principles can be applied to ourselves at both large and fine-grained levels. It is definitely good and desirable to have the overall vision of our project in mind, but  this doesn’t often help us get the work done. Some of my most productive days are when I break down a huge task into tiny subtasks and set a goal for each one (“I will have this done by 11am today, then I will wrap up this other small one by 4pm.”)

An example: I’m currently writing some code to move a huge amount of data around in our production database. We’re going to be rolling out a major update that requires some fundamental changes to how things operate. This task is so large and daunting that I get a headache just thinking about it and so I could put it off, just spinning my wheels until I decide to face the inevitable. Instead, I’ve broken it into several smaller tasks that are each easily managed and understood.

(In my example, the After column actually contains about 30 items, depending on how far I want to break it down…it could be more.)

Now, instead of being overwhelmed by the complexity of a large task (and thus doing nothing), I can easily handle each of the sub-steps efficiently. I’ve changed a two-week task into many hour-long tasks.

The psychological effect of  too-hard/too-complex/too-much is devastating. You can’t handle something like that–no one can, and so you won’t–you’ll just end up wasting time fretting about it. Break it up for your sanity and happiness, as well as productivity.

Motivation is Crucial

Often, a key to not wasting time is having sufficient motivation. Motivation can come in all sorts of ways–the key is to figure out what motivates you and then set yourself up to succeed by using that motivation as a carrot to pull you forward. It can be a good idea to share your motivations with managers so they understand what drives you.

Motivation can often begin with picking good goals. If your goals are unrealistic, you are almost guaranteed to fail in some way. Despair feeds on itself and will sink your productivity and cause you to engage in anything but work. Not only will you avoid the drudgery of work, but you won’t take steps to improve yourself or change the situation. This cycle must be broken immediately.

If your projects are just not that interesting this can be a challenge. Everybody has tasks they don’t particularly like, but if the majority of your time is spent doing stuff you get no pleasure out of, you are doing a huge disservice to yourself and your future. Eventually, you’ll become wasted and useless to both yourself and your employer. Fix the situation–get a new project, get a new job, find side projects to do that you do enjoy as rewards for getting through the drudgery–anything to avoid becoming the shell of a person you once were.

Maybe you don’t necessarily need a new job right now–maybe you just need to fix the situation at your current job, get some enjoyable hobbies at home, spend more time with the family. The needed changes aren’t always drastic–but figure them out so you don’t spend every day wallowing in a mire not doing anything useful.

Eliminate Distractions Now

I don’t think I’ve answered my office phone in about a year. Not that many people call it in the first place, e-mail being highly-preferred around here, but I like to say I stand on principle. You can read a lot about creating the right environment for highly-skilled software developers in the fabulous book Peopleware: Productive Projects and Teams.

I’ve also stuck to the practice of keeping my e-mail inbox cleared. I delete almost everything I receive unless I need to store it for later or act on it.

In my entry about working an 8-hour day, I talked about various time-wasting activities that I’ve observed, such as  wandering the halls, micro-managing, too many words, poor inbox management skills, and more.

The goal of eliminating distractions is not to completely choke off any aspect of fun, diversion, and other social aspects of working in an office–those are good things. The goal is eliminate the things that don’t help us in our jobs and that aren’t really all that enjoyable to us anyway, all things considered.

One way of eliminating your distractions is to go out of your way ahead of time to manage them so they don’t come up later. Some ideas:

• If you need somebody to do a task, anticipate questions, concerns, or problems they may have. Try to address these in an e-mail or in person (or both) quickly so that the person can expect it and won’t come to you later with problems.
• Shut  the office door, turn off the phone, close e-mail. Don’t let people find a way to distract you.
• Shut down your feed-reader, disable pop-up notifications from it. Set aside time during the day to review feeds and news.
• Have a clean desk. Keep only things you’re actively working on visible.
• Set a schedule or a signal to your peers and supervisors of times when you are busy and should not be bothered. Be assertive and enforce it.
• Focus on one project at a time. Everybody has a million things to do.

Plan Weekly, Daily, Hourly

Finally, bringing it around full circle back to goals: plan as much as you can to the extent it makes sense. That’s a weasel sentence, I know, but there’s no way around it. In general, though, I think we could all do with more planning.

Effective planning combines all the above principles into a coherent framework for your work week.

Every week, you have certain meetings, tasks to be completed, issues to be researched, people to be spoken to.

Every day, a certain subset of those must be done.

Every hour, you must pick a task to work on.

My plan is to take 10-20 minutes every day to plan the day’s activities, set min-goals, while at the same time strategizing to eliminate distractions. Every Monday morning I take an additional 10-20 minutes to review and set the major goals for the week, ensure meetings are scheduled, projects are given the correct priority, I know my tasks and responsibilities, and that I have enough dead-time left unscheduled because things always come up (we operate quickly-growing 24/7/365 services–there’s no avoiding issues).

Every time you finish a task, there should be another one waiting, whether you decide to tackle it right away or take a break and do something else. As long as you have a plan, it’s ok.

There are tons of other resources out there–I’ll just link to some in the forums of Steve Pavlina.

Now I should stop wasting time and get back to work…

My first book, C# 4.0 How-To is now shipping! If you like tips you can use, check it out!

Quite easy:

1. Click on Insert Tags
2. In the Tag Provider combo, scroll to the bottom where it says (Customize Providers…) and select that. It brings up another dialog.
3. Click Add…
4. Here’s what I entered for my site:

HTML Template: <a href=”http://www.philosophicalgeek.com/tag/{tag-encoded}” title=”{tag}” rel=”tag”>{tag}</a>

Now you can select Simple Tags as your tag provider.

One of the things I decided when I started working was that I was not going to be one of those guys who worked 12 hours a day for a company (if I ever become an entrepreneur, all bets are off since I’m working for myself). So far, I’ve been pretty successful, and I’ve noticed a few things that may help others. Some of these are more observations than practices.

1. Understand reality: Work Load

The first thing to realize is that the amount of work to do will always exceed the time available. This is why effective management is important. If you are being ineffectively managed, it may be difficult to force a change in some of the following areas.

Just because there is always more work to do, this is no reason to kill yourself trying to get it all done. Or even overexert yourself (except in rare instances). Don’t misunderstand: I’m not saying you have an excuse to slack. Giving all of your time and attention to your employer/projects/job is the baseline here. I am saying that just because you have a lot of work is not a valid reason to work 12 hour days.

Unless you enjoy it…in which case you’re reading the wrong article. If you’re a workaholic, sacrificing your health, family, and free time to get ahead, knock yourself out. You can stop reading now.

There are always special circumstances, though. If you operate in an environment that runs 24/7 services and Something Bad happens–well, then you need to fix it if takes you 24 hours. Hopefully, you’ll get corresponding time off in return. If it’s the last week before release of a project and a major bug comes up–get it done.

I’m talking about normal days, normal work.

If you are working 12 hour days and you don’t like it, then change. No excuses. Change the job or change jobs.

2. Don’t waste time

I knew someone who always complained about having so much work to do, working 60-70 hour weeks, always been pressured, etc. I know he did have quite a bit of pressure to do a number of things, but I eventually stopped feeling empathy for him because I constantly saw him talking to so many people (friends, not direct co-workers) during work.

If you’re so busy working long hours, why do you waste so much time? Why is it that the people who complain loudest about being overworked mostly create the situation themselves?

Don’t wander the halls looking for distractions–chances are you’ll find them.

There is a balance to strike here between enjoyable work environment, having friends, being part of a team, and actually getting things done. There is also something to be said for the difficulty of concentrating on challenging topics for a long time at a stretch. Breaks are definitely needed.

There are trade offs to everything. If you spend an hour or two every day reading blogs instead of working on your projects, you’ll pay for it in time later. If this is a trade off you’re willing to make, so be it, but make sure you understand your priorities and the consequences of your decisions.

I know someone else who used 100 words to say something when 4 would do. This made meetings long, tortuous affairs (unless strong ground-rules were created, endorsed, and enforced). Even simple questions were avoided because nobody wanted to sit there and endure a longer-than necessary answer about the history of the universe. Don’t waste people’s times, and don’t stand for people wasting yours.

Be wise, what can I say more?

3. Don’t micro-manage

The topic of micro-management is something that could take up other blog posts and books dedicated to the subject, but I just want to focus on aspects of it related to time.

This is an inverse of wasting time on trivialities. I once had another boss who spent unbelievable amounts of time responding to every trivial e-mail (and he insisted on being CC’d on every topic of course) and he also complained about working extremely long weeks. And he worked all weekend. He checked on the status of things constantly and was usually the first to spot potential problems. (There were other reasons for this, too: he was usually a main point-of-contact for customers and he had more domain knowledge of everything we were doing). He was very, very smart and usually not wrong, but he did spend a lot of time doing things that were arguably someone else’s job. We never felt invested in these aspects of work, though, because he just did them.

If you find yourself with your fingers in every aspect of your organization, you have a problem, and need to take some time out for consideration:

• Why do you feel the need to be connected to everything going on? Is it because you have to feel in control, or do you not trust others to do a good job?
• Do you not trust your employees? If not, why not? Do they really do a bad job?
• If they do a bad job, why? Are they fundamentally lazy, unqualified, dumb? If so, why are they still working there? Why are you paying them and doing their job anyway?
• Would better training help?
• Maybe expectations aren’t clear. Instead of you picking up the slack, review the expectations you have for them and go over deficiencies. Make them responsible and give them ownership. Don’t undermine their jobs by taking it away. Check on them in the future to make sure things are improved, but don’t involve yourself day-to-day.
• Is it necessary to involve yourself in every discussion or can you just ignore until it reaches a level you need to get into? Resist the urge to comment on things you weren’t asked about.

If nothing else, micro-management always breeds resentment.

4. Set boundaries

I have tried to make it clear to my bosses over the years that when I’m working on a task, I am not to be bothered on a whim. When I’m concentrating, don’t bug me. This is a somewhat loose rule for me, because it really depends on what I’m working on. However, it is more true than not.

The context switching that can happen with interruptions is dangerous for productivity. Eric Gunnerson wrote about “flow state” years ago. Flow state is a zone you get in where your brain is completely engaged–you’re firing on all cylinders, fully committed and involved–pick your metaphor. It’s hard to get into and easy to leave.

I have a nice pair of Bose QuietComfort 2 Noise Cancelling Headphones. These are essential for me now. The whole topic of listening to music while programming is a separate one, with some debate, but I find it usually beneficial. Sometimes I put them on to block sound without listening to music. This also minimizes casual interruptions. I rarely listen to music while trying to create a new solution for something–only when I’m coding something I understand.

Also make sure to enforce a work/life boundary. I have made it clear in my job that I am not be called unless it’s an emergency that needs to be fixed RIGHT NOW. I ignore IMs and e-mails (unless I’m in the mood to answer something, or it’s trivial, or I know it would make somebody happy to know the answer to). If there’s a critical problem, I’ll get a phone call.

I also communicate vacations and just how far out of reach of civilization I will be well ahead of time.

5. Limit Meetings

There is an abundance of resources out there for effective meeting management. I’m more in favor of limiting the occurrences of meetings in the first place. How well you can do this depends a lot on your organization and the projects you’re working on.

Pointless meetings are a waste of everyone’s time. They can be demoralizing, energy-sucking vortexes. Recovering from a bad meeting can take further attention away from actually getting things done.

In my case, we have mercifully few meetings–only when the entire team needs to give input, we need to brainstorm about a tricky problem, or general status updates (yearly or quarterly).

Much of what goes on in meetings can be substituted by effective individual planning, e-mail, issue tracking, or planning better in the first place.

6. Know your tasks

Spinning your wheels is death. Don’t be wasting your time unconsciously (If I’m going to waste time, I’d rather do it consciously with Desktop Tower Defense).

If you’re stuck on a task, get help, change gears, do something else. Make sure you have a process to detect when you and others are stuck so that you don’t waste time.

Always know what you’re supposed to be working on. In addition to have issue-tracking software, make sure priorities are communicated clearly and often. Once you finish something, you should know what the next task is, whether  you do it then or not. Whenever I have a problem of knowing my priorities, I ask my manager. It’s his responsibility to know and set them. I don’t have to worry about it.

There is usually a list of “nice-to-haves” that you can work on once high-priority stuff is done. Don’t let that list get lost, but track it the same way you do regular issues.

7. Effective Information Management

This means all sorts of data: e-mail, documents, data, scheduling, task lists. Simplify, automate, streamline. I won’t go into specific techniques–you can find them elsewhere.

Just a few simple points that I use:

• Don’t read what you don’t need to
• Don’t respond when you don’t need to
• File away or delete ASAP

It’s easy to get buried in information these days–and consequently it’s easy to think it’s at all important. Don’t fall into that trap.

8. External Motivations

A little obvious, this one, but important to ponder. None of this will work if you don’t have strong outside motivations. You have to really enjoy being outside of work–and I don’t think the satisfaction of doing nothing is enough. You’ll get bored of that eventually. Sitting in front of a TV every night “unwinding” for three hours is not a motivational experience (quite the opposite, usually).

Hobbies, projects, sports, exercise, cooking, family, church, books, culture, service are all part of life and should be enjoyed.

I usually schedule my evenings to some degree–whether it’s working out,  moving ahead on personal programming projects, building my latest LEGO model, watching a movie with Leticia, or reading a book–I’ve got a long list of things I enjoy doing. If I don’t follow the schedule exactly, or can’t fit everything in, I don’t sweat it–as long as I’m enjoying myself, that’s what matters.

Work isn’t everything–in fact, it isn’t even the greatest part of anything. Be well-rounded.

* Exceptions

Unfortunately, not every job can be forced into a neat 8-hour work day. My wife, for example, works for a news wire service. She works 8-hour days most of the time, but quite often she ends up staying late to take care of things. Unfortunately, when your job depends so much on other people, it can be a bit hard to plan days, and it’s very possible that work comes up right when you leave, or there is too much work to fit in in a day. However, this is unsustainable in the long run. Either more efficient processes have to be introduced, the work load decreased, or more people hired.

A word or two about politeness as well: it’s difficult in some environments to enforce better behaviors without being considered rude, grouchy, or holier-than-thou. Sometimes firmness has to give way to politeness. The carrot usually works better than the stick anyway in the long term.

The code was calling something like:

CSize sz = m_btAdjustColors.GetDC()->GetTextExtent(sCaption);

It seems correct, but these script languages are throwing it for a loop–the measured size is much smaller than it should be. The GetTextExtent documentation doesn’t shed any explicit light on this subject, but may hint at it.

The solution? DrawText. There is a flag you can pass to tell it to calculate the rectangle needed instead of drawing.

CRect rect(0,0,0,0);

m_btAdjustColors.GetDC()->DrawText(sCaption, &rect, DT_CALCRECT);

It’s important to initialize the rectangle to zeroes because, as the docs say, it only modifies the right and bottom members of the rectangle.

1. Read books. There are tons of books about programming–probably most of them are useless, but there are many, many gems that can greatly influence your abilities.

I still find that it’s easier and faster to find information about many topics in familiar books than to find similarly valuable information online. Read all your books to get to this point.

Books are also valuable from theory, architecture, design point of view. There just aren’t that many places on the web to get high-quality, authoritative instruction in this.

My first book, C# 4.0 How-To is now shipping! If you like tips you can use, check it out!

2. Read Code. This is something I was late to. I didn’t start reading a lot of significant code until after I had a few years of professional programming experience. I would be a better programmer if I had started earlier. I try to read some source code every week (not related to work, not my own, etc.) from an open source project. Start with programs that you use and are interested in. I started with Paint.Net and it solidified a lot of .Net program design technique for me.

Reading other people’s code shows you different ways of doing things than you might have thought of on your own.

3. Write Code - Lots of it. Fundamentally, the best way to learn something is to do it. You can’t fully internalize something until you’ve written it. This starts with something as simple as copying the code examples from tutorials and books. That’s copying by hand, not cut&paste. There’s a difference. The idea is internalize and think, not blindly copy. Look up new API calls as you go. Tweak things.

Most importantly, develop your own projects–whether they’re simple games, participation in an open source project, or a simple plug-in to a program you use.

Try to use new technologies, new techniques, new designs–do things differently. Do things better in this project than in previous ones.

This is really the core point–if you want to be a better developer than develop.

4. Talk to other developers – about specific problems you have, as well as the latest tech news from [Apple|Microsoft|Google|Other]. This not only helps you feel part of a team or a community, but exposes you to a wide variety of different ideas.

Different types of projects require different designs, coding techniques, processes and thinking.

If you work in a small team (like I do) and you don’t have access to many other people, go find some at a local user group meeting. If nothing else, participate in online forums (you’ll have to look harder for an intelligent discussion).

5. Teach others. Similar to just reading code versus writing it, teaching other people can do wonders for forcing you to learn a topic in depth.

The very idea that you’re going to have to teach a topic to someone else should force you to learn something with a far better understanding than you might otherwise. You can face questions.

If you can’t explain a concept to a 6 year-old, you don’t fully understand it. – Albert Einstein

Teaching situations are myriad: one-on-one with your office-mate, water-cooler meetings, informal weekly gatherings, learning lunches, classrooms, seminars, and more.

How about setting up a once-a-week 30 minute informal discussion among like-minded developers? Each week, someone picks a topic they want to know more about and teaches it to the others, instigating a conversation. If you knew were going to teach the group about synchronization objects, don’t you think you’d want to understand the ins and outs of critical section implementation?

6. Listen to podcasts

If you’ve got time where your brain isn’t otherwise occupied, subscribe to podcasts. My current favorite programming-related one is .Net Rocks. They also do a video screen cast called dnrTV.

These will help you keep up on the latest and greatest technologies. You can’t learn everything and podcasts are a good way to get shallow, broad knowledge about a variety of topics, from which you can do your own deep investigations.

If there are other, high-quality developer podcasts, I’d love to hear about them.

7. Read blogs

There are more blogs than people to read them, but some are extremely well-done. I’m not even going to post links to any–there are plenty of other resources out there for that. This is one of the best ways to connect to people who actually develop the software you love and use.

8. Learn a new language

If all you’ve ever done is C(++,#)/Java there are a LOT of other ways to think about computer problems. Learning a new language will change the way you think. It’s not just a different syntax–it’s fundamentally rewiring the brain. Sure, all languages get compiled down to assembler in the end, but that doesn’t mean a high level abstraction isn’t valuable.

Functional, query, and aspect-oriented languages are starting to merge with C-based languages–are you ready?

9. Learn the anti-patterns

Aside from knowing what to do, learn what not to do. Read Dailywtf.com often and take the lessons to heart if you don’t already know.

It’s all well and good to understand proper OO design, coding style, and what you should be writing, but it’s easy to get into bad habits if you’re not careful. Learning to recognize bad ideas is vital when taking charge of a project.

Wikipedia has a thorough breakdown of many common anti-patterns,

10. Be Humble

Learning means:

• Replacing faulty knowledge with better knowledge
• Adding knowledge that you do not already have

There’s no way to learn until you admit you have some deficiencies. It all comes back to humility, doesn’t it? If you ever start thinking you know everything you need to, you’re in trouble. True learning is about hungrily seeking after knowledge and internalizing it. It takes lots effort. We all know this in theory, but we have to be constantly reminded.

My first book, C# 4.0 How-To is now shipping! If you like tips you can use, check it out!

Frank Kelly wrote up a good summary of some items. They’re simple, easy to understand, easy to follow, even for non-programmers.

In fact, I’m sending this link out to everyone in my group here at work.

Technorati Tags: testing,programming,bug reporting

I’ve simplified the code quite a bit in order to demonstrate the issue. Suppose I have a wrapper around an image (it has many more attributes):

   1: class Picture

   2: {

   3:     Image _image;

   4:     string _path;

   5: 

   6:     public Image Photo

   7:     {

   8:         get

   9:         {

  10:             if (_image==null && !string.IsNullOrEmpty(_path))

  11:             {

  12:                 _image = Bitmap.FromFile(_path);

  13:             }

  14:             return _image;

  15:         }

  16:     }

  17: 

  18: }

I had this and a view that loading about 2,700 of these into a customized ListView control at program startup. On a cold start (where none of the pictures were in the disk’s cache), it would take 27 seconds. Unacceptable.

What to do?

My first thought was to load the pictures asynchronously. I wrapped Bitmap.FromFile() into a function and called it asynchronously. When it was done, it fired an event that percolated up to the top.

Well, I spent about 30 minutes implementing that and ran it–horrible. The list showed up immediately, but it was unusable. The problem? Dumping 2,700 items into the ThreadPool queue is a problem. It doesn’t create 2,700 threads, but it causes enough problems to not be a viable option.

Asynchronicity is still the answer, though. But it’s at a different level. Instead of loading the individual images asynchronously, I skipped loading the images when creating the list control and instead launched a thread to load all the images and update them when done. The list loads in under a second, and the pictures show up little by little after that.

Measure, measure, measure. And pay attention.

Technorati Tags: code,asynchronous program model,c#

In my day job I work on a real-time messaging system that can have very, very little downtime. As the service grows and sees more traffic, the amount of downtime shrinks. We start to worry now if upgrades take longer than 5 minutes. (It’s almost to the point where we’ll need redundant systems in order to do maintenance).

To upgrade this software, I have to have an awful lot of confidence in the code changes made. Sometimes that confidence varies.

What to do to gain confidence:

1. Consistent process

Having a set of rules to follow is a fundamental requirement of good software engineering. I’m not going to discuss what the process should be, but you should have one that works well.

Why is this important?

Programmers like order. We like well-defined problems where we can see the end from the beginning. We don’t like haziness, indeterminism, or too many choices.

A process nails down the unknowns–it tells you very specifically what the next thing to do is. A good process leaves no room for doubt.

A good development, testing, and deployment process is the first step to building confidence in what you’re doing.

For my messaging system example, here’s a short summary of what our upgrade process is. We didn’t just come up with it–it evolved as our business grew and the requirements grew with it.

1. All unit and integration tests pass (we have about 2200 automated tests for this that can run in about 4 minutes)
2. We’ve run it on staging server for a few weeks with no issues.
3. All new features have been tested on the staging server
4. Formal change document has been submitted and approved.
5. Formal test results documented.
6. Previous version backed up.
7. Perform upgrade
8. Monitor system (including custom automated monitoring tools)

At any point, I know where we are in the process and what needs to be done next. Sure, there may be details within these steps that require thought and creativity, but the process guides it all and makes us more confident that we’re not performing ad-hoc operations.

2. Unit Testing

There are other types of testing, but it all starts at the unit level, with simple tests that exercise your code line by line, function by function, feature by feature. I recently wrote a few thoughts about unit testing. Unit testing is where you can see the overall wellness of your code–you want that green bar!

Without unit testing, how do you know the code you’re writing is doing what it should? do you just run it and push it through its paces? This is highly inefficient for most types of code. You’ll run out of steam before you start getting close to edge cases.

The fact is that automated unit tests are a baseline for confidence in your code. You need to be able demonstrate time and again that your code performs well.

This all presupposes that you are writing good unit tests. If you’re not sure, start studying. I don’t buy the arguments about lulling developers into a false sense of security–sure, that can happen, but having good developers who understand this is a prerequisite.

If you’re not unit testing–what is your basis for confidence in your code?

3. Code Coverage

Code coverage goes hand-in-hand with unit testing as a good way to automatically discover what areas of your program are in need of more testing. I’ve found that one of the biggest barriers to unit testing a large C++ application we have is that we have no way of easily measuring test coverage. If we had time, we could definitely to the analysis ourselves, or we could spend a lot of money to get a C++ instrumentation profiler, but these are slow and very tedious to use in my experience.

In .Net, use the tools to your advantage.

The psychological benefits of seeing 75-, 90-, 95-, even 100-percent coverage are immense. You know that every line of the program has at least been touched.

Of course, most code coverage tools analyze line coverage, not path coverage. Combine  complexity analysis with code coverage to determine which functionality should probably have better testing. There are plenty of free and commercial tools that will give you cyclomatic complexity, among other metrics.

Use other analysis tools like FxCop to make sure your other ducks are in a row. It can find easy-to-overlook problems like not validating arguments of public methods, which can then lead to more unit tests and more coverage to achieve.

4. Automation

Take yourself out of the equation as much as possible. The point of a process is to be repeatable–it’s like automating yourself. Not only should unit testing be automated (thankfully, most testing frameworks handle this easily), but so should coverage and quality analyses.

What about deployment? Automate it. Documentation generation? CD master creation? Web upload? E-mail notification? Automate them all. Production builds should be invoked with a single command.

Working on boring, repeatable code? Automate it with code-gen.

The bottom line is: Don’t waste your brain cells on stuff that is highly repeatable, especially when it is prone to mistakes.

5. Code Review

Last week, a rather serious bug was discovered in some of our software (not released yet, thankfully, but close). The bug was mine, and I knew exactly what the problem was, but instead of designing a solution by myself, I brought a co-worker into the discussion just to bounce ideas off of. He had great suggestions, and made me think of things I might not necessarily have thought of on my own. We both went over the code and came to a solution that was simple and acceptable to both of us. The confidence level was much higher with this than it would have been otherwise.

This story is repeated daily by programmers throughout the world. Code review is a practice based on the simple notion that there is no one person smart enough to get it correct the first time.

Even if you’re working alone, which I often do, it pays huge dividends to regularly review your code with an eye for finding trouble. If you see any weakness at all, don’t ignore it–fix it. If you’re reviewing your own code, it’s a good idea to wait a bit after the time you wrote it. This gives your brain a chance to forget a little bit about it. Then, if you find you can’t understand it anymore, it’s either too complicated, or (if it fundamentally really is complicated) you need better comments.

Reviewing with other people has more benefit, however. Not everybody thinks the same way about problems. People have different experience, different expertise and focus, and you can’t take advantage of that if you don’t let them teach you. Even if the other people have less expertise than you, it is still beneficial (assuming they have some basic competency that they can bring to the discussion).

Once you let other people tear into your code (nicely, I hope), your confidence can be higher because you can add the confidence other people have in it (once your problems are corrected, of course!)

6. Repeatable Experiences

In the end, one of the best ways to increase your confidence in yourself, your code, and your practices is to have the evidence of repeated experiences behind you. You’re always learning, and that learning contributes to improvements in processes, testing, and your personal coding practices. Once you learn what works, especially during tricky upgrades, you can go into the next trial with increased confidence that you’re doing something right.

Have any other ideas on increasing confidence? Leave them in the comments!

Technorati Tags: process,confidence,unit testing

Say you need to set a form’s cursor to the wait cursor while you accomplish something.

You would do something like this:

this.Cursor = Cursors.WaitCursor;

//do something

this.Cursor = Cursors.Default;

Of course, what if “do something” throws an exception? Then your cursor won’t be set back to the default.

So let’s wrap it in try-finally.

try

{

    this.Cursor = Cursors.WaitCursor;

    //do something

}

finally

{

    this.Cursor = Cursors.Default;

}

Better, but that’s a lot of wrapping around a simple operation. Notice, that the try-finally is exactly the pattern that using is. Why not wrap this functionality into a simple to use class that handles the cursor reset automatically?

internal class WaitCursor : IDisposable

{

    private Control _control = null;

    public WaitCursor(Control control)

    {

        _control = control;

        _control.Cursor = Cursors.WaitCursor;

    }

    public void Dispose()

    {

        _control.Cursor = Cursors.Default;

    }

}

And to use it in a form is simple:

using (new WaitCursor(this))

{

    //do work

}

Of course, you could easily add functionality like restoring the previous cursor instead of always the default, handling exceptions, make it thread-aware so it uses Invoke if necessary, better error-handling, etc.

Technorati Tags: C#,.net,Forms,Tip

Enter Reflector. It was trivial to poke into the .Net assemblies and see what the SerialPort class was doing under the covers and then use the correct Win32 functionality in our app.

There are also a ton of plugins available.

Technorati Tags: reflector,.net,c++,C#