Mistakes are the portals of discovery – James Joyce

February 18, 2007

“Ahh poop” or words to that effect, could be heard resounding through my flat in the middle of last week. Throwing away code is hard. I’d just worked out that the 3 classes I’d written, were wrong. Worse, the 3 sets of tests that I had written (first, test-first), were now useless. The code wasn’t bad, but I hadn’t thought about how to solve my problem well enough. You shouldn’t http POST to a URL query, its just not right, e.g. www.david.com/service?day=wednesday&recordfootball=true

Throwing away code, however, is a good thing. It means you’re learning, it means you are raising the bar of your own efforts. (Refactoring code is very different, and is a tool every agile developer should have, sure, refactoring can be painful too, but never as painful as throwing away code). If you don’t throw away code, that you know it fundamentally wrong in its functionality, because you are too attached to the code, things will only get worse. It also teaches you a lesson in checking what you are doing, at a business logic level, is correct in the first place. This also taught me a lesson about the advantages of pair programming.

Unfortunalty, I am unable to pair on this project as it is something I am doing in my own time, but I suspect if i was pairing, somewhere along the line someone would have said “what are you doing that for?”.It also got me thinking about code reviews. I’ve never really been involved in one, but I’ve made a resolution with myself to try and do it. Just take a class I’ve written and go through it with some of my colleagues at work, because i know there must be better ways of doing the things I’ve done, and similarly, i think there are a few tips I can teach people by looking at my code. Far too often in the IT world the person that wrote the code owns it, that is “badness”.

Thinking about it more, i think it shows a degree of honesty with yourself when you throw away code and allow it to be reviewed. Programming is not an art form, despite what people say, its deterministic, and so, in fact, it takes a clever person to know when there code is not useful, or unperformant.

So, in fact I reckon I’m in profit after my c# malfunction. Having written 3 useless classes and 3 useless test classes I’ve made my code more useful, thought about how i can use code reviews to learn and teach different techniques at work, appreciated the value of pair-programming and well, filled up some more space on my blog. J

p.s – this made me laugh. Say you have 4 telephone numbers that you can input on a form to set up a conference call. You name each variable logically, private String telNumberOne , telNumberTwo etc. But you think, well pretty much everyone knows what you mean when you call it a telNo so ill refactor my code to call the variables telNoOne, telNoTwo. Except when your in a live meeting and you try and get your colleague to look at the the first phone number

David : “Look, you see telNoOne”

Colleague : “Tell Noone about what? Your code? Why?”

Although this wins as a (how not too) guide on variable naming conventions : http://mindprod.com/jgloss/unmainnaming.html


Bad communicators go the furthest.

February 6, 2007

Recently, I’ve learnt the importance of communication. What a cliché. 

Hands up if you haven’t got something along the lines of – “excellent communicator” on your C.V.

We all seem to think we’re good communicators because we all understand ourselves. But do other people understand us? Can you take complex technical issues and explain them to people? Trust me, the answer in your head right now is almost defiantly, not what the last person you explained something to would say.

Here’s an example. What is Spring? I don’t want to hear the words ‘dependency injection’ or ‘inversion of control’, yes they make me sound important but they don’t help non-techies understand them. There are some incredibly clever people out there, and the problem is, they know all the answers, but haven’t got a clue how to explain them to people. In my short experience I’ve found that half the reason people get to the position they are is because they are actually bad communicators, quite clearly clever, and quite clearly the only people who can do the things only they understand, as there is no chance of them ever explaining the concepts to the lay man.

In my opinion the most important factor in communicating to people is not the words you use, but making sure your audience understands you, otherwise say it with your mouth closed, it’s about as useful.

So my new resolution is to make sure people understand what I’m telling them, and when I’m doing anything, do it in the simplest way possible. I think that people are worried about making hard problems simple, no one wants to appear trivial. Nothing in the whole of the world cannot be described in a simple sentence. Just ask the oxford English dictionary.So, next time you explain something to someone, do something so simple it hurts. Ask them to explain it back, this is not demeaning, this is to check they understand.

Complexity stops things from working, use examples, explain, be expressive, simplify.

But for goodness sake don’t make things more complex than they have to be.


No one wants a young Einstein.

January 29, 2007

One of my good friends, who works as part of a sales team once said to me, (paraphrased) “credibility is one of the critical success factors in my job, I’m young, 22, how am I suppose to convince someone to buy from me when they feel like they are dealing with their son?”

This raised an interesting point, one that i think its particularly valid in the IT field. Youth works against you, when you need to make a good first impression, being young, is not a great start. I think most people would try to deny this, saying that age doesn’t matter, I think this view doesn’t reflect the facts. I think its human nature, take Albert Einstein for example, as a 22 year old he graduated from Aarau in 1900 as a teacher of mathematics and physics.

Although he sent applications to many universities trying to obtain a position teaching, he did not get an offer to teach from any of them. No one wanted Einstein. In fact, in support of my argument, his first ever non teaching job in a patent office was only achieved after a well respected friends father implored the director of the patent office recommending him for the position.The formula is simple, if you are young, you have little experience and less knowledge then someone that has existed for a longer time than you.

Yes, it’s flawed, but why then are there so few young professionals at the very top of the IT industry? There are many examples of young, intelligent people who have done well in the IT sector, Larry Page and Sergey Brin, cofounders of Google are the obvious cite, but these are self made, well done to them, but no one gave them the opportunity, they made it themselves. Sadly, I can see very little evidence of large , or even medium sized IT firms promoting young (<25 )staff to influential positions. It certainly not because they don’t have the drive, balance, intelligence and potential, so why is it? I don’t know.

I’m fully aware of the counter argument, yes there are very experienced professionals, who are experts in their field, and they have had to earn their right to be where they are, only too right, I’m not talking about replacing them, merely supplementing them. After the dot com boom the IT industry has seen a serious decline in the number of graduates taking an IT-related degree, not to mention the sad cosmic dearth of females in this industry. The lack of young role models is simply no coincidence.

I hope I grow old quickly. Or invent the new Google.

I have a feeling I know which one will come first.