Redgwell, I presume?

The life and times of a kiwi geek


leave a comment »


Written by redgwell

May 8, 2011 at 8:33 pm

Posted in Random drivel

The I.T. Expert

leave a comment »

In I.T., I’ve found that there is the concept of “The Expert”.

The Expert is a powerful title to behold, and is rarely bestowed upon the worthy…

The Expert is born when a manager learns that you know something about a particular topic which the manager knows nothing about. For example, Manager Bob hears about a new design pattern called “The Super Widget Pattern”. Developer Tim has also heard about it, and even read a blog post about this new design pattern. Manager Bob learns that Developer Tim knows something about the new design pattern, and bestowes “The Expert” title upon him.

Once you have earned The Expert title, you have the final say on anything to do with your topic. Nobody can override your decisions, and no one can exceed your expertise.

Of course, reading a single blog post doesn’t make you an expert; this is the heart of the trouble.
From this point on, The Expert can go in two directions.

The Humble Expert will attempt to refute their expertise on the topic, and after realising that no one is listening, will learn as much as they can about the topic so that they might approach a real expert status. The Humble expert is usually totally benign, and can often help to boost a team’s proficiency.

The Arrogant Expert will embrace their newfound power, and profess to know everything there is to know about the topic. To the ignorant, this can be difficult to spot. After all, they are an expert so they must know what they are talking about. To the learned, The Arrogant Expert will quickly reveal their true colours; filling the minds of those unfortunate souls caught in their embrace with whatever lie sounds plausible at the time.

The most troubling part of The Arrogant Expert is that they are a force that is difficult to stop. They are like a snowball of bullshit rolling down a cow filled meadow, quickly gaining momentum and layer upon layer of dung.

The only way to stop this is to stand up to The Arrogant Expert when their peers and supporters are present. You need to beat them down with truth, fact, and reason. This may need to be repeated on several occasions, so rinse and repeat as necessary.

You may be asking what can you do to stop this injustice? The first thing is to be aware of The Expert. The second is to realise that almost no one is an expert; we just have varying degrees of understanding.

Written by redgwell

December 2, 2010 at 7:25 am

Things you should ask in an interview…

leave a comment »

Before starting a new job, there are several questions that need to be answered before you opt for a 6 month sentence in a potential warzone:

1 – What are the specifications of the standard developer machines?

There is nothing worse than not being able to do your job because you haven’t got the right tools. You wouldn’t want an architect to design a house for you using a 10c ruler on the back of a napkin, or a builder to build the house with plastic tools.

The same goes for developing enterprise level software. Often, companies have the impression that developers always want the latest gadgets for the sake of having them.
This couldn’t be further from the truth. As a web developer, I often find myself with at least two instances of visual studio open, firefox, ie, and chrome. Throw outlook, word, and obligatory company virus scanner into that mix, and you’ve got yourself a very demanding work environment.

Multiple screens should be compulsory – it comes down to a matter of productivity.

2 – What is the code like that I’ll be working on?
Words like ‘legacy’, ‘challenging’, and ‘our lead developer has left and we need someone to replace them’ should ring alarm bells.
Don’t get me wrong; porting code from older legacy systems, and generally improving things is what (most?) developers are all about. Good developers are perfectionists – kludgy code is the kind of thing that keeps them awake at night, and so they lavish any opportunity to tidy up the mess and get things into a state of zen-like cleanliness.
But hiring a flashy new developer to try and polish your turd-like code is going to make your developer very bored. Give them the opportunity to properly improve things, and you will find that things will run much more smoothly, with fewer bug reports, and quicker turn around of new features.

3 – Run me through the typical SDLC
Every company seems to pride themselves on their ‘amazing and efficient SDLC’. I’ve worked for very few that have it right.
Getting requirements while you are bug fixing a release is far from ideal. Requirements need to be determined up front before the build begins. The business needs should never be led to believe that something can be ‘quickly added in at the last minute’, because the overhead of doing this is orders of magnitude higher than doing it properly.
In addition, every iteration should factor in time to refactor code to ensure it is properly maintained. Without this crucial step, the software that a company is spending millions of dollars on will very quickly start costing more than it’s every going to make.

4 – Where will I be sitting?
This is something that often is overlooked, but seating developers in amongst BA’s or sales people is going to see your developer efficiency plumet. Developers need to be in their own quiet space, with other developers. My ideal experience was three developers in an office where the door could be closed. My worst experience was sitting in a sea of cubicals next to a customer service/salesperson taking incoming calls all day (think “Corporate accounts payable, Nina speaking. Just a moment…”).

This might all seem a bit over the top – but remember, when you accept a job somewhere, you are there for a long time, and these are the kinds of things that will prevent you going insane!

Written by redgwell

November 3, 2010 at 8:28 am

Java or .Net?

leave a comment »

Written by redgwell

July 6, 2010 at 9:36 pm

Nine families from around the world and their weekly food consumption

leave a comment »

Written by redgwell

July 3, 2010 at 10:43 pm

Posted in Uncategorized

Beating back the bugs with a stick

leave a comment »

I was reading through an annotation of an episode of the stack overflow podcast when I found this great paragraph spoken by Joel Spolsky:

Y’know, when I first moved to New York, I’m walking down the street, and I was really a full-time programmer in those days, I mean, I just coded all day long… I’m walking down the street and a taxi comes careening through a red light, nearly runs me over… and I’m like, “What the hell? This taxi nearly ran me over!”

I start chasing it and banging on the taxi with my hand and start screaming at the taxi driver… and I realized that what was happening is I was having this mindset of “I saw a bug with the world and I wanna fix it”.  Like “The taxi driver tried to run me over, I’m going to yell at him so he doesn’t do that anymore.”

But there are millions of taxi drivers in New York, and you know what?  The entire population of taxi drivers in New York are all immigrants, and they turnover every 3 weeks on average.  So there is no way I’m going to educate all 14,000, or whatever, 28,000 legally licensed taxi drivers in New York not try to try to run me over, as if they could care less.

Because I banged on my taxi with my hand.  And I realized this was more something to do with me, that when you’re coding all day long, you are fighting an avalanche of code not doing what it’s supposed to do.  Either because you haven’t written it, or because the first time you write it it’s buggy, and the next 17 times it still has bugs, and eventually you get it a little bit closer.  And you’re just basically, like, sweeping back the sea with a stick…. beating back the sea with a stick?  What’s that expression?  You’re fighting this constant avalanche of “the world is wrong and I need to make it better”, and then you get out in the actual world, as a human being, and it’s hard to change that mindset.

It’s hard to forget that you’re not responsible for improving the traffic situation in Manhattan, and the safety of pedestrians.  You can’t do that.  You could make a whole job doing that, you could try to admonish a couple of taxi drivers once in a while…. But if you try to do that in your interpersonal relationships, in real life, if you try to behave the way you behave as a programmer, doing his or her job, if you behave that way with your family or friends, it’s highly inappropriate.  You have to be a lot more… you can’t debug every problem in the real world.  At some point you just have to stop and say, okay…

Beating back the ocean with a stick

Spending a lot of time coding puts us in a mindset of finding an issue, mentally building up a picture of several possible sources of the problem, and then coming up with a contingency to remedy the situation. When sitting in a meeting with a developer, and telling them about a bug, or even a new feature, you’ll often find them working through things in their mind (looking skywards), or jotting lists of stuff down on paper. What they are doing is attempting to solve the problem before they’ve even seen the code. Programmers are problem solving machines!

Recently, I realised the same thing that Joel is talking about here – that is there’s little point in carrying the ‘fixing bugs’ mindset forward in life, because you are unable to put a proverbial breakpoint on things that you see as wrong with the world.You can look at the problem, and figure out possible sources, but unfortunately, we don’t have access to the source code of the universe…

What ends up happening is that you end up being highly strung, since there truly is an avalanche of things that need fixing in our world, and it’s impossible to fix all of them let alone one or two. I think that as programmers, we need to often make a conscious effort to step back from the coding/bug fixing mentality in life, and just try and work around the bugs, rather than fixing them.

It’s a most satisfying and revitalisting realisation.

Written by redgwell

June 10, 2010 at 1:50 pm

Steps to setup IIS7 on W7 (and probably Vista)

leave a comment »

Every time I install Windows 7, I trawl the internet for solutions to a bunch of problems that I come across.

Here is the condensed list of steps to setup IIS7:

1) In Control Panel, go to “Programs and Features’, and select “Turn Windows Features on or off”

2) Select “Internet Information Services” (just the top level checkbox seems to be fine for now..), and “Microsoft .NET Framework 3.5.1” (both child nodes). Click OK, and let it do its thing.

3) Open “Internet Information Services (IIS) Manager” and expand the tree on the left until you have highlighted “Default Web Site”

4) On the right side under “Actions”, choose “Basic Settings…”. In there, you will be able to set the Physical Path to the web server. I set mine to my current website I’m working on.

5) For debugging, I find directory browsing useful. To turn this on, highlight “Default Web Site” and double click on the “Directory Browsing” icon in the central panel. On the right action panel, click “Enable”.

6) Navigate to Localhost in your web browser, and verify that there is something on the other end. You will probably have an error regarding a locked configuration area. Run the following command line script until your errors have gone and you have a directory listing showing:

%windir%\system32\inetsrv\appcmd.exe unlock config -section:system.webServer/{SECTION NAME}

where {SECTION NAME} is something like “modules”, or “handlers”…

7) If you are working with WCF services, then you will probably need to install the mime type handler. Use the following command to do this:


"C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" -i


"C:\Windows\Microsoft.NET\Framework64\v3.0\Windows Communication  Foundation\ServiceModelReg.exe" -i

That’s all the steps I have for now – I’ll add some more as I come across other configuration woes.

IIs6 was so much easier…..

Written by redgwell

April 19, 2010 at 5:16 pm

Posted in Administration