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. http://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

Advertisements

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.