Archive for the ‘General’ Category

How to get that role you want

Thursday, February 8th, 2007

This is one of those chicken and egg problems.  You are a nerd working on a team and you think that you’d all do well if there was someone responsible for the architecture (or design or builds or tests or…).  In fact, you think that you are the perfect candidate.  There isn’t a job opening.  Nobody has announced the need.  What do you do?

Should you talk to you boss and suggest that you starting doing it?  What if she says that she can see that such a role might be needed but that you don’t have any experience?  What if she says that your teammate Max would be better at the job and calls him into her office?

As you might guess I think that the best thing to do is to starting doing the job on the side.  It will probably mean extra work.  It will probably mean needing to convince co-workers that your ideas are worth it.  However, the best way to show that you can do something and that its needed is to do it.  Be careful not to be sneaky and be sure that you aren’t stepping on anyone’s toes too hard.  Unless you work in a toxic environment your efforts will be appreciated and rewarded even if you aren’t successful in changing you role.

Five things you didn’t know about me

Thursday, February 8th, 2007

Dwight Shih has tagged me with the surely dead (except for me) five things meme.

So in order to not be too curmudgeonly here I go:

  1. I’ve got two kids, a 5yo and a 13mo and a lovely & intelligent wife.
  2. I live in Canberra, Australia.
  3. I love cooking even more than I love nerdery and software development. That’s a lot.
  4. I’ve worked part-time for about five years now and I recommend it to anyone who can afford the cut in income. Especially if you are a parent - there is nothing like having a spare/bonus/free day every week to spend with your kids. That is until they start full-time school like one of my kids just has.
  5. My first job after I finished university was working for a startup working on an expert system shell in Prolog (and C). Much fun and hilarity ensued.

I take it I’m supposed to pass the meme onto some others so here goes - Justine and Iang your numbers are up.

The training course scam

Sunday, December 3rd, 2006

Software development training courses are a waste of time, money and effort and don’t equip people to do meaningful work. Supposedly they pass on new skills and knowledge to developers. In reality training courses are about:

  • padding resumes,
  • allowing managers and staff feel like they can tick the “staff development” box in a yearly evaluation form,
  • sucking money from companies,
  • giving people a 3-5 day break from work,
  • letting developers off the hook for not doing their own professional development, and
  • “rewarding” developers in a low-effort (for developers and managers) way.

In my experience as both a nerd and manager of nerds I’ve never attended a training course that has taught me anything that I hadn’t already known or that I couldn’t have learned in a fraction of the time with a little bit of effort. When I’ve sent developers on courses they often admit the same thing.

Lets look at some of the things wrong with training courses:

  1. Training courses are aimed at the lowest common denominator - this is why they are so mind-numbingly slow, otherwise the guy in your course who can’t turn on his computer will complain and the training company will lose money.
  2. Training courses are often inconveniently timed - how often is the right course run? Probably not when you need it.
  3. Training courses are often a poor match for the actual need at hand - ever seen a course about the replacement of a Java servlet application with a PHP-based blogging tool to provide a corporate intranet? Me neither. But I have seen plenty of kitchen sink courses with lots of irrelevant junk.
  4. Training courses are generally expensive. ’nuff said.
  5. Training courses have a short retention half-life - unless you teach yourself or put into genuine practice things you learn you will forget stuff. Quickly.

Instead developers should be given time and resources (the Internet, books, self-paced learning CD’s, mentoring and guidance, access to others, etc) and a goal relevant to their upcoming work and asked to teach themselves. Does this take more effort? Sure. Is it more effective? That’s the wrong question - it will actually be effective where training courses aren’t.

We all need to stop pretending and bite the bullet. Managers should create customised training plans for developers that provide a combination of on-the-job activities, self-paced learning and guidance from existing experts. Developers should expect that they need to apply effort. Its okay to ask for help to create your training plan but its up to you to do it. You are a professional and its your career. Sitting in a room with a bunch of other bored developers really isn’t going to do the trick is it?

Great quote

Thursday, October 12th, 2006

This is a great passage from Cryptonomicon by Neal Stephenson:

“Your younger nerd takes offense quickly when someone near him begins to utter declarative sentences, because he reads into it an assertion that he, the nerd, does not already know the information being imparted. But your older nerd has more self-confidence, and besides, understands that frequently people need to think out loud. And highly advanced nerds will furthermore understand that uttering declarative sentences whose contents are already known to all present is part of the social process of making conversation and therefore should not be construed as aggression under any circumstances.”

I don’t think the above is always true but there are a good number of our fellow nerds for whom this is pretty accurate.

The Silent Treatment

Thursday, August 17th, 2006

So you find yourself in your boss’s boss’s office. He’s sitting there in his nice suit and cufflinks smiling nicely. Its been about 5 seconds since you finished answering his question about that troublesome project you’re managing and he hasn’t said a word. Not one. Maybe you didn’t answer the question? Perhaps he’s annoyed at you? Maybe he didn’t understand? Perhaps you explained yourself so poorly that he’s stunned?

Probably not.

He’s probably just an arrogant jerk playing power games with you. You see there’s this technique that “important” people sometimes use on those who they are sure are in awe of their power and all round importance. They stay deliberately quiet when you indicate using non-verbal or verbal queues that you’ve finished talking. The hope is that since you are a normal person inbued with social graces that you’ll pick up the slack and keep talking. Then, as you grope around your little brain, you’ll spill the beans on your secret plans or whatever. After all you’ll be so flustered.

What should you do. Don’t panic and choose one of these two options:

  1. Talk about anything even obliquely related to the subject. Go into enormous, banal detail. If you’re talking about a project schedule then list every task you can think of. Don’t forget to give a history of which people have had anything to do with each individual task. Most importantly, try not to pause for too long for at least a few minutes. The idea is to apply a bit of aversion therapy. He goes silent. You babble.
  2. The alternative is to sit there quietly as well. After all he asked a question and you answered. If Mr Bossman has more questions then he should be able to ask shouldn’t he? After a while if he doesn’t get a flustered reaction from you he’ll probably not try it any more.

Hopefully you’ll never face the situation. I’ve only had it tried on me a few times. The first time I was flustered and madly groped around for a while trying to answer the question. By the next time I’d worked it out by reflecting on how uncomfortable I was the first time. I used the babbling technique which worked - no more attempts from that guy. The last time, with a different person, I tried the going silent technique. I also tried to smile knowingly at him. He gave up on the discussion (probably because he thought I was a deranged axe murderer).

P.S. If you’ve ever used this technique on someone then please stop reading my blog. We don’t want your kind around here.

All Managers are Clueless (lament of a new manager)

Wednesday, July 12th, 2006

Everyone knows that managers are clueless. They set impossible deadlines, they can’t delegate properly, they keep changing priorities and so on. Google has 1.8 million pages when searching for clueless manager. Clearly there is a lot of cluelessness going on. In fact managers are so clueless that most nerds don’t bother waiting to see if you’ll turn out to be clueless or not - they simply flip the clueless bit as soon as you are introduced.

New manager’s manager: Hi everyone, this is Manager, your new manager.

Everyone: [Clueless. Another bloodly manager the last one was so clueless. This one looks the same.]

New Manager: Hi everyone, as NMM said I’m your new manager. I’m looking forward to working with you all and finding out how I can help.

Everyone: [Clueless. Just as I thought empty platitudes. Clueless]

Now since you are reading my blog you clearly aren’t clueless are you. :) Unfortunately, unless you are joining an extraordinary organisation the chances are that lots of people will assume a lack of capability based upon their experience with others. Of course given your boundless ability you’ll turn these people around. Eventually. Until then you’ll have to deal with the consequences.

People who assume you are clueless will be less likely to come to you for help. Why would they bother? You’ll have to work hard to discover when people need help and be careful to actually provide genuine help.

People will assume that you aren’t equipped to understand their nerd problems. Be prepared for lots of slow explanations about how computers work or what XML is.  Worse, you’ll find that people will assume that you don’t care about quality and will sacrifice long-term benefits for short term “progress.

Good luck.

The telephone test

Wednesday, July 5th, 2006

I have a simple test that tells you a lot about the culture of any organisation.  There are two questions you need answer:

  1. If you are talking one on one in their office do managers generally answer the phone when it rings (thereby interrupting your conversation) or do they leave it for voicemail?
  2. Do managers regularly choose to delay or stand-up multiple subordinates when summoned by their superordinates?

If your answers are interrrupt and stand-up then you have a management culture that believes that they are central to getting things done.  This is, of course, pretty bogus, selfish and arrogant.  If you have only one of interrrupt and stand-up then you have a warning sign.  Hopefully, things are trending away from the arrogant management culture.  Managers exist to enhance the performance of others - if they do their job then they become less necessary.

The flexibility trap or why doesn’t corporate software have an opinion?

Monday, June 12th, 2006

Have you ever felt that terrible sinking feeling? The one where you realise that the latest upgrade of Super Corporate BlahBlah has broken a huge chunk of the loving customisations you did the year before last? Its a trap - the flexibility trap. Unless you are careful or lucky lots of corporate software forces changes to existing customisations and integrations. So all those special screen hacks you did will break. Those database queries that you use to feed the latest figures into your ERM system - dead.

The trap isn’t triggered when you decide to do a customisation. No its long before that. Its triggered when someone decides to buy software that:

  1. needs to be significantly customised to suit your needs; or
  2. needs to be customised before it can be used at all.

So what should you do? There isn’t a great deal you can do right now - most corporate software assumes customisation and or massive implementation efforts. Witness PeopleSoft for example. The idea of Opinionated Software as espoused by David Heinemeier Hansson offers some hope in the future:

Opinionated software was a term I coined to describe the rebellion against the fallacy of objective software. That software should be as configurable as possible from the outset to allow every user to bend it exactly to their needs. Opinionated software dares say the customer is not always right. That not everything should be a preference, that decisions can be made once for the better.

I’d like to see that idea take a stronger hold. Be a master chef, prepare me a meal of code that you think is the best it could be. Spare me the construction kit.

If your corporate software was sensibly opinionated then you’d have less customisation to do (as long as you agreed with its opinion). Ideally opinions would be obvious and shared by salespeople (”only buy our stuff if you believe that bug tracking should be a simple three stage process”).

The second trigger of the flexibility trap is software that is an empty shell waiting for you to fill it. Lots of toolkits fit into this category as does some software. For example, I’ve been working with a product that is supposed to provide help-desk style support. It has a workflow engine built into it which must be used. The bloody thing doesn’t even come with a simple workflow process out of the box. Its infinitely customisable, so it can do anything but can you get it to help without becoming an expert in helpdesk processes? No way. A waste of everyone’s time during setup/install and a real pain when it comes to upgrade time. Even if they had a menu of half a dozen standard processes (and optionally customised for those truly special cases) to choose from it would be so much better for everyone (except for their consulting arm). GRRRHFDHHFDHRHEHJHHHH!!!

Shelving a project

Tuesday, May 23rd, 2006

Today at work we decided to shelve a project. It was an update to an existing web content management system and was due to be released in a couple of weeks. Things appeared to be going okay until the project approached release. The project is pretty traditional (i.e. waterfall) and is/was in the “testing” phase. The development and testing environments have always been flakey (crappy architecture and people putting up with less than ideal situations) until about a week ago when they took a turn for the worse. Was it the code? Some problem with one of the servers? Nobody knows - the configuration control of the servers is out of hand - nobody can really work out what is going wrong. All up there was just too much risk floating around so we decided to bite the bullet and halt the project until we get the environments under control.
Lessons? I’ve got lessons:

  1. If something smells bad for a long time then it probably is. I wish I’d dug deeper into the smell earlier and ignored the advice that things “will be okay” or that the problems aren’t linked and are just a long series of individual, unrelated minor mishaps.
  2. If migrating between environments is done by manually repeating steps then stamp your feel and insist that it be automated. Don’t let the developers tell you that it has always been done that way and has always turned out alright.
  3. Go back to lesson one - remember to follow your gut.

Its a pity that we got so far and so much effort has been (potentially) wasted. Its embarrasing for us all. Worse, after the news of the project being shelved was shared with the developers they asked for one more day since they were sure they were close to fixing the latest problems. Now they think I don’t trust or believe them. That’s not true - I just don’t think that we can continue to dig ourselves deeper.

P.S. I started working on a new contract last year - its almost the exact opposite of my last role - big, very traditional organisation. The opposite of agile and not very fashionable technology or development processes (not much, if any, source code control, waterfall style testing, no real unit tests, etc).  Email me if you want to know about why I left my last job. I don’t think I’ll be blogging about it - at least not for a few more months.

Make someone responsible and put them in the middle (part 2)

Wednesday, May 10th, 2006

There were a couple of comments on my First make someone responsible… post that I’d like to highlight.

Ian from Financial Cryptography (a subject so complex I can barely spell it) chimed in with his usual wisdom to say:

…It’s a mess of contradictions - the job is mostly communications, but you need to be a technical expert otherwise the techies will snow you. The job is about compromise, negotiation and swallowing ones ego; but getting the technical skills required to face up to the people you are managing requires the reverse of that…

The ability to be able to smell obfuscation in nerds is something that most reasonably experienced managers develop. Being able to challenge, or better, work with a nerd to come up with an improved and acceptable (to the nerd) solution is something that can only come from people who have themselves been nerds. As Ian notes finding such people and keeping them in the middle is something that can be a challenge. Having a role model doing the same job somewhere else in the company helps.

Tarun from Musing of an Iconoclast added this:

…if you have a late or overbudget project then this is probably the only thing you can quickly change that will make a significant difference…

So true. Even if a process is being followed the absence of someone in the middle will probably bite you. As I said in the original post, adding someone is great experiment - showing whether or not the addition has helped.