Being Professional

What is the secret to writing awesome software?

As an industry we're very good at gravitating to new techniques, new tools, even new languages as we aspire to write even better software. And it's pretty hard to argue against the results that are obtained by some - even if those results are sometimes harder for others to reproduce.

If you haven't read it already, go and read Scott Hanselman's post Everything's broken and nobody's upset". Do it now, I'll wait for you.

Like many of you, my initial reaction to Scott's post was to nod my head in understanding, with examples of my own frustrations hovering at the edges of my awareness.

Staying on top of the never ending tsunami of email can be a significant challenge at the best of times, let alone when you work in an organisation that treats email as it's very lifeblood.

Inspired in part by a comment made by a friend, I though it might be useful for me to detail the techniques I've been using to stay productive and avoid burial by email. These techniques have been pulled from a wide variety of sources over the course of several years and are not presented as a prescriptive "You should do this" but rather as "I found these helpful - perhaps there's something here you can use".

Here's a puzzle for you all ...

Assume you're working with a complex system that's highly important for the business, one that is mission critical for some of the staff, where they are dependent of the system so they can do their jobs every day.

Further, lets assume the system has just been restarted after a major meltdown and you're investigating the cause of that failure.

When you think you've identified the sequence of actions that caused the system to go down, when you have a plausible theory of the crash that matches known information, what do you do next?

It's pretty traditional in some quarters to do a retrospective end of year post, recapping the highlights of a blog or community.

But, I've never been a great follower of fashion. Instead, let's focus on what's important for the year ahead, and on how can we improve as professional software developers so that 2012 is more successful, enjoyable, productive and rewarding than 2011.

After my recent presentation at the recent Tech Ed conference in Auckland, I've spent a little time reflecting on the feedback received and identifying some lessons learnt. I thought that blogging these might prove useful for others as they work towards their conference debut.

I have long considered the repository pattern to be a foundational design pattern for database connected systems. Recently, however, I've started to reconsider this opinion. Read on to find out why.

I saw a couple of disturbing statistics about software testing in the keynote at the recent New Zealand Application Lifecycle Management conference.

• The best techniques for defect detection only identify around 75% of all defects.
• The average detection rate is around 45% of all defects.

If there was a single technique that identified 97% of all defects, I'm sure we'd all be learning it tomorrow. But, when there is no "silver bullet" technique, what do we do?

Scott Hanselman has a great list of Interview Questions for Senior Software Engineers.

Some of my favourites from the list include:

• Who are the Gang of Four? Why should you care?
• Describe a pattern that is not the Factory Pattern? How is it used and when?
• You have just been put in charge of a legacy code project with maintainability problems. What kind of things would you look to improve to get the project on a stable footing?

I saw a blog comment today that illustrates a pervasive problem in our industry:

The problem is, how much longer are you willing to invest on them and NOT forcing us to learn again something new ...

The exact source isn't relevant, because this is a widespread attitude.

A recent post on Paul Randals blog lists the top 10 mistakes people make when attending a course:

1. Take a phone call during class
2. Sit at the back and do email/surf and then ask questions
3. Persist with a tangential rat-hole
4. Bring your smelly lunch into the classroom
5. Come to a class where you don't understand the language it's being taught in
6. Come to a class without the required experience and knowledge
7. Don't take notes
8. Ask questions to try to make it look like you know more than the instructor
9. Argue that the instructor is wrong
10. Come to class looking for "the answer"

Go read the entire list. Are you guilty of doing any of these? Do you want to change?

I'm having such a great time dealing with lazy code. Check out these gems I've found just today ...

var periodError 
    = string.Format(
        "The Survey Return does not contain a valid Reporting Period");

Why format something that with no parameters? I changed the code to this:

var periodError 
    = "The Survey Return does not contain a valid Reporting Period";

It's interesting to see how different people react to the idea of process improvement. Most people fall into one of two camps - I'll term these the Conservatives and the Radicals.

[img_assist|nid=259|title=|desc=|link=none|align=center|width=512|height=249]

Conservatives don't see any need for change at all: "That's just the way we do things around here, we get the job done, and I've got work to do anyway." They put no effort into process improvement, and therefore realise no improvements. They never make things worse - but they never make them better either.

Saw something interesting at church the other morning, as the speaker was preparing her message.

A set of PowerPoint slides, for display alongside the message itself had been saved on a USB key, and needed to be loaded on to the A/V computer used during the service. However, when the key was inserted, it didn't appear under My Computer, making it kinda difficult to access the files.

The immediate response of the person driving the computer was to dive into the control panel, clicking things at random, looking for something wrong.

It appears there are those who think it's perfectly Ok to steal Roy Osherove's latest book, "The Art of Unit Testing".

Seems a bit rich to me - after three years of hard work, surely Roy deserves the small recompense he gets for each copy sold.

I wonder how many of those who cheerfully stole his work would be just as happy to have three years of their hard work stolen by people too lazy or too cheap to pay.

Just read an interesting article which included this comment:

There is also a belief that older programmers "lose the edge." That belief is mistaken in my opinion; older programmers may not burn as much midnight oil as younger ones, but that's not because they are old, but because they get the job done without having to stay up past midnight.
(Michi Henning, "API Design Matters", Communications of the ACM May 2009 Volume 52, Number 5)

Something to aspire to, perhaps ...

Well over 10 years ago I learned of the so called Four stages of competence.

In short, these four stages identify the progression of skill adoption:
[img_assist|nid=238|title=|desc=|link=none|align=center|width=512|height=174]

Someone with Unconscious Incompetence doesn't even know that they don't know.

Someone who is Consciously Incompetent has some idea of what he doesn't know.

Someone who is Consciously Competent can get the job done, but has to work at it.

Leon Bambrick has an interesting post 8 ways to be a better programmer in 6 minutes. Even if you don’t agree with Leon’s tips, they’re interesting, and thought provoking.

In the same spirit, here’s some more tips for you … though some of these might take more than 6 minutes to do.

Learn the Keys

Jay Fields has a recent post “The Cost of Net Negative Producing Programmers”, in which he laments the high impact of NNPPs and the lack of any industry structure that encourages them to leave the field.

I find it reasonably depressing to find that, in many ways, I agree with his argument.

Worse, I’d go so far as to suggest that a similar problem exists in other parts of the ICT industry.

Some examples from my own experience …

A friend emailed me an interesting quote:

"... what little evidence we have about programmer productivity points to a productivity distribution that's skewed with a long tail of incompetence"

-- Larry O'Brien

However uncomfortable it might make you, I believe there's a certain amount of truth in this quote.

Over on 43 Folders, Merlin Mann has posted a thought provoking article Attention & Ambiguity: The Non-Paradox of Creative Work

Go read it. I'll wait here.

Merlin has written about a important distinction, one that is critical to all creative endeavours - and I include Software Development as a profoundly creative endeavour.

I was reading today about the so-called "awesome bar" included in the upcoming release of Firefox 3 and was struck by the observation that many commentators seem to be simply complaining about change.

Dealing with constant (and accelerating) change is part and parcel of working in the IT industry.

I was listening today to a recent Hanselminutes podcast, where Scott Hanselman and Carl Franklin were discussing the Joy of Development.

A friend recently asked me what podcasts I listen to on a regular basis - and I figured to share the list here as well.

Spec# is a C# based language from Microsoft Research. It extends the language by adding comprehensive support for Contract Based Programming, with new keywords such as assume, require and expose.

There's one thing that really really bugs me about Agile development ... well, ok, there are several things, but today I'm focusing on just one ... and that's the thinking around YAGNI.

In case you're not familiar with the acronym, it stands for You Ain't Gonna Need It.