I'm going away on a skiing trip for a couple of days. Apart from the much-welcomed physical training it involves, getting out of town provides an excellent time to read. Into the bag goes, among others, John Grisham's Pelican Brief (many say it's from the worse end of his production, but we'll see), Writing Secure Code (2nd ed.) by Michael Howard and David LeBlanc. Oh, and of course, there's also the EOS 20D and a bit of photography literature - it's a good time to practice taking some nature shots.
The weather forecast says it's going to be a nice -10 degrees through the rest of the week, with perhaps slight snowfall and a few sunny days. In five hours, I'll be on my way to pure whiteness. Oh, I love Finnish winter. Have fun meanwhile :-)
Douglas Reilly recently posted an article called The value of experienced coders discussing the merits of experience and the short-sighted approach of pushing experienced developers either to sales or management. A rather interesting read, and luckily quite a bit shorter than my usual recommendations :-)
Not that I'd be close to even 40 yet, but the article did get me thinking. What is the career future for an aging software developer? Will the young necessarily replace him? How should the old fart make sure he gets to keep his job and stays valuable? Is he eventually forced to choose between his profession and glory?
I've had the pleasure of meeting some real professionals from various fields, ranging from metalworks and farming to coding and legal profession. None of the people whose skills I admire most work as managers or in sales - they're simply solid operators - might I say artisans - in their own field. It's a real shame if the software industry wastes this experience and potential in the search for short-term gains.
Even if it's evident by nature, I'll say it again: The industry needs to focus on building more diverse career paths. The industry needs the weight of experience to keep this thing in balance. While the youngest among us provide unparalleled energy, motivation and ideas, they are far too uncertain of themselves and their role in the world to build good and long-lasting products.
The announcement of IE7 took me by surprise. Ok, we have no tangible promises on features and "betas during the summer" isn't much said, but still - it's a Redmondian move on the browser field, first significant one after several years of sleeping.
The comments on the IE team blog entry speak volumes. Standards compliance and tabbed browsing seem to be the top requests - no surprises there. Microsoft itself only talks about security, which makes me wonder if it's just going to be IE6 SP3 with a nice name.
On the other hand, if Microsoft doesn't show its innovation muscle now, it will have a very hard time proving itself in the future. The patience of the cutting-edge web users (and developers) is growing thin. At any rate, IE7 should be a good addition to the field - it's very unlikely to be worse than IE6, and it will quite likely mean considerable improvement for those users unwilling or unable to switch browsers.
At best, IE7 will bring us something really new. I wouldn't rule out that possibility either, even in spite of the tight schedule Microsoft has put themselves into. They have surprised me before. Firefox and Opera have had competition in the marketing field, but Microsoft's passiveness has taken a lot away from the evolutionary progress of browsers. Perhaps this will change now? Prodding Microsoft to do this release seems to be one of Firefox's chief achievements so far.
While I've been exploring in the unit testing world for quite some time already, the recent weeks have been another great push in this direction. The techniques and patterns for unit testing are relatively easy to comprehend. My real challenge is business integration and managing the developer-driven part of the testing process: The ways to teach people on it, the ways to measure the success of it, the ways of making test automation a useful tool right from the start.
In my quest for truth, Alberto Savoia's The Developer Testing Paradox has been a great read. It's long and heavy, but very well written. It'll take you half an hour to read and digest, but trust me: it's one of the more useful half-hours you've spent recently. This applies even to those people who aren't unit test nuts - it's still a good idea to understand this emerging facet of software development.
To lighten up the Monday, here's a funny blog post by J. Michael Palermo: .NET - A Love Story. Anyone with decent OOP vocabulary can understand most of it :-)
I've been toying with Whidbey quite a lot lately. One thing I didn't fully appreciate from reading the spec at first was partial classes. Sure, the concept of being able to divide a class in several files is great, but the full realization of its practical benefits kept me waiting until I designed my first complex form with VS.NET 2005.
#region Using directives
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Windows.Forms;
#endregion
namespace MyClient
{
partial class MainForm : Form
{
public MainForm()
{
InitializeComponent();
}
}
}
This is what I get when I pick "View code" for the form. Where are the control declarations? Where's that InitializeComponent() method maintained by the form designer? That's right, they're somewhere I can't see, and that's right where they belong. In practice, they're in MainForm.Designer.cs, which is totally maintained by the designer, as opposed to my MainForm.cs, which is totally maintained by me (except for VS.NET adding event handler stubs when I request so).
If I had had this little facet of separation at my disposal for the last few years, I would've been a much happier man. Not to say the current (2003) Form designer model doesn't work, but it's certainly clumsy and error-prone. The borders of machine-generated code and human creation are always weak spots. Now we're one step further from confusing the designed form and the integrated logic. An excellent innovation, that.
PS. I've done quite a lot recently, even though you can't tell by reading the blog. "Test-Driven Development in Microsoft .NET" is among the titles I've recently read - and heartily recommend. More on that soon, I hope.