I have moved the blog to my own domain and am trying to write to it on a more regular basis. The feed url stays the same as it was before.
Hope to see you there,
Although modern day IDEs (Eclipse, IntelliJ, Resharper etc) undoubtedly provide a lot of benefits when writing code, I am starting to wonder if the ease at which they make things possible actually encourages bad habits.
Useful features such as creating and initialising member variables from the definition of a constructor are quickly nullified by the ease at which one is able to create getters/setters/properties for these same member variables. All hopes of encapsulation gone with a few clicks of the mouse.
The counter argument is that you need to work responsibly when given a powerful tool, but it just seems to me that it’s hard enough to write good OO code (too hard maybe?) – anything which makes it harder is not a good thing!
I am convinced that IDEs need to provide an Office paper clip style Martin Fowler which pops up whenever you do something questionable (such as creating getters for every field on a class) and asks whether you really want to do what you’re doing.
Or maybe there is too much cranking out of the code and not enough thinking about the design of what we’re coding that’s the real problem…
Having just flown half way across the world from Sydney to London I’ve been thinking about how airport security is done and noticed a somewhat interesting link to the use of null checks in code.
In Sydney and Dubai airports my baggage and I were scanned only once before I was able to get onto the plane. I wasn’t scanned again when I went to the departure gate nor when I got onto the aircraft.
Yet I often see code which has null checks peppered all over the place – in fact in some code I’ve seen there were null checks before every single call on an object. Not only does it make the code look extremely ugly, but a lot of the checks were completely pointless since there was no chance of the object being null anyway.
Imagine how annoyed we would be if they checked our baggage at every single step from entering the airport to getting on the plane! So let’s cut out unnecessary null checks!
One of the intriguing aspects of pair programming for me is that of the non driving person in the pair – what are they supposed to do?!
Obviously there are fairly well known strategies for more interactive pairing, such as Ping Pong and Ball and Board (which is where one person controls the mouse and the other the keyboard), but neither of these strategies suggest what to do when you are not driving
Obviously it is very easy to be a bad non driving part of the pair, by getting distracted by what’s going on around you and a quick fix that I’ve heard to solve this is that when you’re bored, ask for the keyboard back. This solves the immediate problem but still doesn’t make you any better at contributing when you’re not at the keyboard.
One idea that I’ve been playing with recently is keeping a list of the next task that needs to be done after the current one is done – effectively just tracking where we are on the story. We use tiny tasks for most stories as laid out by Patrick Kua. This does work although you still don’t feel that involved, and it can end up seeming like you’re dictating to the other person what to do. This is definitely an approach to be applied with some tact.
Some of the more skilled non drivers I’ve worked with have the ability to see the bit of code being worked on as part of the whole and are able to see when we have gone too far down the wrong path and should actually be making changes elsewhere. I find this a lot harder to consciously improve, and I’ve been told it’s a skill that comes with experience.
I’m sure there are other roles of non driving that can be applied, mentoring being one, although that’s for another post! Thoughts?
One of the more interesting concepts used on the NLP course that I did last year was the idea of only giving positive feedback to people.
The thinking behind the theory (which I think comes from Robert Dilts, one of the early thinkers behind NLP) is that people know what they are doing wrong and already beat themselves up about it; therefore there is no point you mentioning it as well.
I was initially sceptical about this approach as it seemed a bit too idealistic for my cynical mind. I found it extremely difficult to start with and didn’t give any feedback to anyone for quite a few sessions. Eventually though something clicked for me and by the end of the 18 day course I feel I did gain a greater respect for and recognition of the talents that other people on the course had. The need to focus only on the positive actually seems to drive the mind to see more in this area than it otherwise would.
Although noone likes it when they are criticised, I think there are some occasions when someone criticising you can prove to be extremely motivational. This basically involves them completely writing you off and you then being determined to prove them wrong. For example at school I was told that I would definitely fail the Pure Maths modules of my A Level Maths course. Completely unimpressed with this verdict I persevered with it for months eventually scoring 85%. Job done.
I think sometimes when giving critical feedback it can say more about you than it does about the person you are giving it to, and this is where it’s vital to step back and think why you are giving the feedback.
I find at least for myself the tendency is to want to point out things people do that annoy me, which in effect is me trying to make the person more like myself. Steve Pavlina suggests that the things we hate the most in other people are the things we actually hate in ourselves. Therefore his suggestion was if you find something someone else does annoying, first look at yourself and try and improve yourself in this area.
I’m not sure if I totally subscribe to why this approach would work but I definitely agree that it is way easier to change yourself than it is to change someone else.
In one of the sections talking about how Amazon had changed the way books were sold, the author mentioned that Amazon actually have printing facilities available to them on site so that if they run out of copies of books they can just print some extra ones. I don’t know how I missed this but I had a look on Google and Amazon did in fact acquire an on demand printing company three years ago.
Sounds like a brilliant idea to cut down on wastage of unsold books although I imagine the overall printing cost per book would be higher if you excluded the cost of waste.
I’ve been told that InfoQ have a similar sort of idea going on whereby if you have a book you’d like to publish you can go to them and get it printed at a far cheaper cost than would be possible with a normal publisher. I couldn’t find anything on their website beyond the new ‘mini books’ series they have started running, but that does provide an email address to get more details so it could well be true. If so it’s great to see that it’s becoming easier for your average person to have their voice heard.
I’ve had the opportunity to have worked with many different people pair programming wise over the last year or so, and having seen it done in several different ways thought it would be interesting to work through some of my thoughts about this Extreme Programming (XP) originated practice.
First of all it seems to me that pair programming is a technique that is used with a lot more frequency at ThoughtWorks than at any other IT organisation.
Obviously I do not know every IT organisation in the world, but based on discussions at the ALT.NET UK conference I went to last weekend; it certainly came across to me like that. The difficulty in getting clients and/or management to see the value in having two people on one machine was the main factor mentioned as proving problematic.
I have been working for ThoughtWorks for 18 months now and have been pairing for all but 3 of those months. Perhaps contrary to popular opinion, not every project is a 100% pairing one.
I’ve paired with people for 20-30 days at a time, paired with people for 1 day at a time, paired with people who have been pairing for years, paired with people who are pairing for the first time, and all in all it’s been fun.
I now find writing code far more enjoyable when working with someone else, motivated by the opportunity to bounce ideas around and come up with better solutions.
The biggest benefit for me of pairing is that you have to vocalise your ideas to your pair. This massively reduces the chance of going down a dead alley as a ‘wrong’ idea would have to somehow make sense to two people, which is much less likely to happen.
Equally, when done well, you end up thinking a lot more about why you are doing things e.g. why should that method go on this class, should we introduce a new service, why are we testing it in this way, should we be testing it another way etc.
On the flip side there are times when you just want to look up something which interests you but isn’t totally relevant to the current task and that has to be placed on the backburner for the time being. Pairing can also prove very tedious when doing fairly trivial tasks such as changing configuration files; although of course it does help if every knows how to do this so pairing on these tasks does provide some benefit.
I will cover some of my other thoughts in future posts.