The Data Asylum

My Secret Santa decided to treat me to a copy of Stephen Covey's The Seven Habits of Highly Effective People. Presumably because I'm ineffective in some way, which is completely true. Here then is my list of how to be a highly ineffective person.

1. Social Networking. Check Twitter/Facebook every 5 minutes. Someone might upload a photo of you at any minute. You must know ASAP.
2. MSN. Having personal conversations on MSN can sap anything from 10 minutes up to an hour or two from your day.
3. Hangovers. Nothing keeps you alert like having a late night the night before. Especially if you are a "2 pint screamer" like myself.
4. Wikiwalk. Do a Google search on how to open a file in ruby. An hour later your reading about the Boer War in South Africa. You have no idea how this happened.
5. News feeds. Keeping up with the world and what is happening in your industry is important. Reading every article from the 200 feeds you are subscribed too isn't.
6. Coffee Time. Making a cup of tea/coffee is a great little stretch for you. To really be ineffective, make a cup for the rest of the office as well.
7. Unread books. Buying books and not reading them is a surefire way to feel smart. I currently have The Passionate Programmer, Linchpin and the 7 habits book waiting to be read/finished.

Is there anything missing. Do you have a favourite time waster? Let everyone know with a comment.

This is how I organize my widescreen desktop.

The main feature is moving the taskbar over to the left hand side. When editing code or reading a website I would rather have more space vertically. It is also easier to select a window when you have a lot open. The Quick Launch toolbar is more useful, because you can have a lot more shortcuts without taking away taskbar space.

One of the first questions I ask when attending an interview is why are you hiring a senior PHP programmer? It is a question born out of cynicism. If everything is going well in your organization why change things by hiring someone? But also the question is 'Why do you need someone with lots of experience'. They are going to be more expensive so why are you spending the money?

In Joel Spolsky's book on hiring programmers, he states :-

The great software developers, indeed, the best in every field, are quite simply never on the market.

Sitting on the other side of the fence, I believe that the opposite is also true. The great software jobs are quite simply never on the market. There are many reasons to hire a senior programmer. Let us have a realistic look at them from the point of view of the jobseeker.

• The business is growing and we have more paid projects then the current staff can handle.
  • This is the most common answer, and sometimes it's not rubbish. It's one of the better answers but the problem for the jobseeker is there is no real way to disprove it. Also you have to ask why do you need more than a mid-level or even low level programmer.
• Our senior programmer quit, and we are filling in his position
  • Why did he quit? Is he moving cities to look after his sick aunt? Or did he just quit because he didn't like the job? It is once again hard for the jobseeker to verify this. Even if they gave you permission to speak to the ex-employee, would you believe it if he told you it was the greatest job on earth? Perhaps asking how long his tenure was may offer an insight.
• We only hire experienced people
  • If everyone is senior who makes decisions? Who does the boring crap? (Seriously there are often a lot of repetitive tasks that are perfect for a junior to cut his teeth on, and would drive a senior person insane with boredom). Who am I going to mentor?
• Our platform is a complete mess and we need senior people to decipher it
  • While this is a cynical view I believe that there are quite a few positions where a senior position is required because of this very reason. It will not be stated explicitly or even understood by the people hiring, and can be a real surprise for employees walking in to a new position. Trying to tell if this is the case before hand is tricky. The sad thing is that this type of challenge could be attractive to a senior person. Give a technical person the opportunity to make something better and they (should) grab it with both hands.

What are the other reasons to hire a senior programmer? Get it off your chest and leave a comment!

• Sell your company. Tell a story. Where you have come from and where you are going. Why the position is so important to continuing that story. What technical challenges are the company facing. Keep it interesting and relevant to the position. You want everyone who comes for an interview to want to work for you. Even if the person is not right for the job, word of mouth amongst potential employees is a great tool for getting people through the door.
• Qualify the applicant. Ask hard questions and let them prove their knowledge. Most of the enjoyment you can receive from a job is through co-workers. One of the concerns a job seekers will have is the quality of their future co-workers. By showing that you are screening out lazy, boring and unqualified people, the person will feel more comfortable about taking the job. Instead of wondering if the company will be good enough for them, they will start to wonder if they are good enough for the company. It also puts a level of expectation on the applicant which is a good place to start the work relationship.

While looking through some old files I found this gem. It's an essay written seven years ago by Robert L. Read called "How To Be a Programmer: A Short, Comprehensive, and Personal Summary". It covers a what the writer feels are the most important skills to learn across beginner, intermediate and advanced skill levels.

I remember being heavily influenced by this as it appeared a short time after I first had a real job. seven years is a long time in technology and I was wondering if the advice in it held up. Here are a few excerpts.

2.9 How to Deal with Intermittent Bugs
The intermittent bug has to obey the same laws of logic everything else does. What makes it hard is that it occurs only under unknown conditions. Try to record the circumstances under which it does occur, so that you can guess at what the variability really is. … Try, try, try to reproduce it. If you can't reproduce it, set a trap for it by building a logging system, a special one if you have to, that can log what you guess is what you need when it really occurs.

When I first read this many years ago I was relieved. It's not just me that has these problems. I've used this formula too many times to count.

6.7 How to Know When to Apply Fancy Computer Science
There is a body of knowledge about algorithms, data structures, mathematics, and other gee-whiz stuff that most programmers know about but rarely use. In practice, this wonderful stuff is too complicated and generally unnecessary.

It's the biggest contradiction in our industry that a lot of importance is placed on solutions to complicated problems when most of the time simple solutions to simple problems are needed (and more desirable).

4.1 How to Stay Motivated
It is a wonderful and surprising fact that programmers are highly motivated by the desire to create artifacts that are beautiful, useful, or nifty. … There's a lot of money to be made doing ugly, stupid, and boring stuff; but in the end fun will make the most money for the company.

I'm not sure where I stand on this one. As much as I'd like to believe that fun is always the way to go I'm not sure that it will always pay the bills.

Overall it is still a relevant and important essay for any programmer at any level.