The fine line between the -ism's

An interesting chat at work: A colleague was reading a news paper article about racism in the job market, stating that a young job seeker had been advised to change her name from Jordan to Elizabeth. My colleague stated that he didn't think this was racism, but class-ism, remarking that Elizabeth is classier than Jordan, not more British.

I liked his point, it made me think that if someone told me I was to meet a lady called Jordan to interview I would have no pre-conception of her race. My pre-conception of Elizabeth however, was that she would be better dressed. My colleague then took the point a step further, stating he wouldn't date a girl with the same first name as a wine.

That's when it hit me

This wasn't class-ism, or racism, IT WAS SEXISM!

Whatever happened to the days of Audrey Hepburn? A women to be treasured and worshipped, change her name to Chardonay Hepburn and she becomes a glitter soaked vajazzled sexbeast! Michelle Pfeiffer => Lambrini Pfeiffer.

The true horror of this insidious state of affairs only becomes apparent when you show the difference between the sexes. Lets flip it around and see what happens to our men under this new regime:

• Johhny Shiraz
• Mike Bordeaux
• Ronny Budweiser
• Little Bobby Shandy
• James Hofmeister

All of a sudden these guys are comic book super heroes! Fighting for Good, Justice and Honour, but they have been subverted by the machine - unwitting soldiers in the war against the fairer sex!

Makes you think, doesn't it?

Thoughts on TED

I've been watching quite a lot of TED talks recently. Obviously the variety and depth of the talks is one of the things that make TED so amazing. I watched a couple recently, one was of a woman that wraps people in straws and takes pictures, the other was about a guy who designs book covers. It got me to thinking that if you could talk about your job all I needed to do was write some cool JavaScript and I'd be on the TED stage rockin' faces. Whilst living out this little fantasy in the theatre of my mind, I suddenly realised the horror. I then wondered when other people came to the same realisation?

Scenario 1: backstage

So, I am backstage and nervous along with the other speakers. The topic of conversation inevitably turns to subject of our talks. I give a pithy explanation of some software development project ending with my motivational line "One morning I got into the office at 8:30 to find there was no coffee... but you know, even through the dark times, we never gave up..." I guess that's why I am in the inspiring section.

I am imagining a reply to come from a plain looking middle aged lady, who you would correctly describe as "really nice". She would smile and say she was in the inspirational group too, which was great as we could be friends. I would smile and graciously ask her about her talk.

"Oh, I'm here to talk about my dog really. We were on holiday in India when my 6 month old child fell through a hole in the ground into a snake pit. The hole was so small that we couldn't reach her to get her out but we could see snakes all round her. I don't mind telling you I was really panicking! Then Poppy, my little King Charles Spaniel jumped down the hole and fought off the snakes until we could get help. She was bitten 15 times and had enough venom in her to kill a rhino, but she protected my little baby until we could dig her out."

As if this story isn't enough to knock your confidence, in the silence left by the end of her tale I hear the guy next to you finishing of his practice speech with:

"... and that's how I managed to secure a clean water supply for a village of people living in one of the worlds harshest environments."

Scenario 2: after the talk

Scenario 1 is pretty harsh, but that lead me to scenario 2. You don't find out about other people's talks till after you have delivered yours.

After giving my talk, I wander over to my friends to find out how it went from the perspective of a member of the audience. "So friends and family members, how did it go? Awww Mum, you are crying - did I make you proud?"

"What? Oh, actually, I'm still thinking of that puppy. Yea, you delivered your story really well, it's just that you were scheduled between that kitten that can sniff out cancer and the 16 year old kid who built a nuclear reactor in his garden shed. But your script thingy was good too..."

The journey home

But the punishment doesn't end there - imagine the journey home. Everyone is super excited and inspired by the talks they heard that day and are swapping their favourite bits.

"What about the woman who swam from Cuba to the States and kept getting stung by Portuguese men of war but insisted on getting her adrenaline shots in the water! She was mental!"

"Yea, but that guy who built schools for children out of trees he had to sail across the lake of terror - he was just some sort of saint."

Then to compound the injury, someone notices the sad on my and tries to help. "Well, I think my favourite bit was when Ant said he didn't know how to do that thing. Then he thought how to do it when he was in the bath and he got out of the bath and made the floor wet - that was pretty funny."

That's why it's actually a good thing I will never get to do a TED talk.

Science cont...

Previously I stated that I believe the scientific method to be our best bet on determining the validity of a claim. However, I also stated that I believe scientists to be flawed in their implementation of the scientific method. This is partly because no-one is truly independent, especially when it comes to disproving their theories. It is especially true when it comes to money, determining your own career and keeping your job.

Richard Dawkins

When I was at school I read The Selfish Gene by Richard Dawkins and changed my plans on what I wanted to study at university. One particular story from the book has stayed with me throughout my life - it was about a Cambridge professor who sat in a lecture given by someone with an opposing view point. The professor realised that the opposing view point had great merit and at the end of the lecture he went onto the stage, stated he had been wrong for a number of years and thanked the lecturer for correcting him.

Like most people, I have spent much of my life being wrong and being corrected by others, but that story has always helped take the sting out of it. It is much more important to learn than it is to be right.

Big science

I fear that the large sums of money being poured into science and the way it is handled has caused this lesson to be lost in science today. This is because it's pretty difficult to take £150 million in government money to study the nuclear furnace in suns and then turn round and say "sorry, I was wrong, it's all based on electricity".

In the introduction to his book The Trouble with Physics, Lee Smolin talks about the difficulty of getting a tenured professorship in particle physics if you don't study string theory. Donald Scott talks about NASA (annual budget of $15 billion tax payer's money) openly refusing to fund any cosmological research that is adverse to the Big Bang theory. Rupert Sheldrake talks of Richard Dawkins refusing to listen to his evidence before debunking him.

Yet every new major discovery in science has brought with it things that were previously unthinkable, for example, Bruno's assertion that the sun was a star, or Darwin's assertion that we all have a single common ancestor. New discoveries often prove the old ideas wrong - the earth is not flat, nor is the universe mechanistic. Yet science is closing down alternative avenues of investigation to concentrate on the most popular?

This dogmatic approach to learning seems far removed from the early writings of Dawkins that so spoke to me. It also seems somewhat counter to the general spirit of scientific discovery, especially when Rupert Sheldrake asserts that if a mere 1% of the current scientific funding could be used to fund non-mainstream projects and make a real difference.

We are living in a time where advances in particle physics have slowed dramatically. The imagined benefits of the human genome project largely failed to materialise, despite enormous amounts of money being thrown at the problems. Perhaps it is time for science to become less dogmatic, less like a religion and more like an open network of people searching for answers through rigorous application of the scientific method.

Science

One of the problems with interacting with others is dealing with a fundamental lack of common ground. For example, when your two view points on a topic of discussion are so far apart that there is no place to plant a flag and say "Ok, this is our mutually agreed and understood starting point". I find that these are always deeply painful discussions, which sadly are usually quite difficult to get out of. This can be pretty depressing, as they also seem quite easy to see coming.

If you are a musician, one such conversation may start "I don't see what all the fuss about jazz is, I mean, it's just picking a series of notes from your scales isn't it?" Obviously, when someone says something like this as an opener, you can just let it slide, but when they wait until half way through a discussion, you can't really just nod and smile.

Scott Adams (of Dilbert fame) has pretty much made a living from these kind of fundamentally opposed understandings in engineering. I once had a supervisor say to me "I don't understand why this is taking so long, if it's a computing problem, then the answer must be either zero or one. Just try them both and use whichever works." I still wonder if they were actually pretty funny and I just didn't get them.

It is perfectly possible for two people to view the same issue very differently and for both to have sensible views. Politics is full of such scenarios, however these are not the issues that concern this post.

For me, these interactions often start part way through a discussion with the assertion "well, 'Science' doesn't know everything". This statement tells me a number of things:

• My assertion that I am right in this instance has been extrapolated to an assertion that I am right about everything.
• The discussion has moved to an emotional phase
• There is evidently a deep misunderstanding about science.
• If I haven't been able to explain my point up until now, there's no chance of me doing so by continuing.

Science doesn't know everything

Science doesn't know anything... it's not an entity in its own right. There are scientists, who certainly don't know everything and as far as I am aware, they don't claim to. In fact, if ever there was a group of people who are crushingly aware of what they don't know, it's scientists. Scientists are a group of people who attempt to acquire knowledge in a systematic manner. That systematic manner is called the scientific method.

The scientific method

The scientific method is the best method we have for acquiring knowledge. Its past victories include penicillin, television, brain surgery, space travel and the atomic bomb. It is of course flawed as are the people who implement it, however it still remains, to date, our best bet for determining the validity of a claim. So, when Brian Cox appears on tele and tells you that the sun is a giant nuclear furnace, he isn't handing you down a decree directly from science itself. In much the same way, when I say "there's no evidence to show that homeopathy works any better than sugar pills and no obvious method through which it could have the effect you are stating" I am not saying that I know definitively that homeopathy is a load of crap. I am saying that there is no evidence at all to suggest that it does work and thus, it would be foolish of me to believe it did.

I am not saying that it is impossible that I have won £2,000,000 on the Spanish email lottery; it's just that it would be foolish of me to believe something without real, compelling evidence.

It's the same with homeopathy. I would gladly take homeopathic remedies, if someone could give me compelling evidence to show that they worked. It's not enough for me to hear that a friend's aunt took this potion and she swears by it, I want to see it work in a standard and repeatable manner.

Being right for the right reason

It is also important to be right for the right reasons. Being right for the wrong reasons are just luck and that is a poor strategy for future success. For example, lets say you have 2 boxes, one has £100 in and the other is empty. You can choose one box and keep its contents. The only information you have is that the box on the left is twice as likely to contain money as the the box on the right.

There are four possible outcomes depending on your choice and the location of the money:

	Left box chosen	Right box chosen
Money present	You are lucky and smart	You are lucky and an idiot
Money not present	You are unlucky and smart	You are unlucky and an idiot

My point here is that the result depends on how lucky and how smart you are. However, you can only affect how smart you are.

Developer Cruft

Like most developers, when I start to work on a new project I don't generally do so from scratch. I have a series of code snippets I use to do common tasks. Things which can be added to a project quickly and safely - having been tested in the fires of other projects. This helps me develop faster and more robustly - it would seem growing old has some upside. Experience counts for quite a lot in development. Having a back catalogue of problems you have experienced and solved is very useful.

However, software development is a fast moving industry and I can see a trap waiting for me. Anything I wrote previously could have been superseded by others in open source projects. Unfortunately, it is much easier to use a familiar block of code than to learn something new... This is not a problem a more junior developer faces, there is only the unfamiliar. The code produced may take longer, but it perhaps has the advantage of being more relevant. My name for this issue is developer cruft, how much of my code at any one time is a bit old and past it?

My solution to this problem is to look toward peer review, having others dig about in your code and make fun of it is a great way to get to grips with new things that you've missed. Sometimes that's not really possible, for example, in a really small team. When you are on your own, it's hard work keeping up to date. The recent explosion in JavaScript and thus JavaScript libraries, frameworks and plugins make it hard work keeping up-to-date. I find reading other people's JavaScript a great way of getting development advice from others - sure it's harder work, but its really helpful. As well as reading other code, working with other code can be a real eye opener - if a project isn't highly time pressured, consider developing in a different manner, perhaps using a new framework, it will open you up to learning and that's never a bad thing.

Don't get me wrong, code doesn't become bad simply by getting old. Sometimes the code you wrote a while back was awesome then and still rocks the show today. Sometimes it was sub-optimal then and you've learnt enough in the intervening time to recognize and fix it. Whatever you find, its important not to rely too heavily on old code you wrote when you were less experienced than you are now.

Opinionated Development

Opinions

I am a big fan of opinions. I hold my own quite strongly and I like others who hold their opinions based on experience and good sense. Opinionated development seems like a winner then, things which have been learned from experience becoming standard methodologies. Obviously, this is only really useful if you agree with the opinions of the creator. However, it really shines if you are inexperienced and looking towards others for good practice. Encouraging good practice is a worthy thing, it is often hard to find good information when writing software and it is impossible to avoid problems you are ignorant of.

Arguments

Obviously, there's a "but" in there somewhere... I do like opinions, I also quite like a good argument. I find having my opinions challenged good fun and also quite enlightening. The best people to challenge my opinions are those with different experiences to mine (as well as greater knowledge of the subject matter!). Whereas I may have avoided a technique due to inherent issues, others may have found ways of neutralising the issues rendering the technique useful again.

Communities

A possible pitfall that I see in opinionated development communities is that they will tend to attract like-minded developers. Penetrating discussions rarely occur between people who agree on a subject and there is a possibility of the community becoming dogmatic. Especially when junior developers learn their trade in this manner, with no direct experience of the value of other methods.

Just a thought...

Choosing a library / framework

As I may have mentioned, I'm working on a javascript web app at the moment and it's been pretty interesting. We're taking a restful approach to the system and maintaining as much separation between front and backend as possible. One of the first decisions I had to make was whether or not to use a framework to take care of that side of things for me. I really like backbone.js and was struggling to think of a reason not to use it and build something myself. Obviously building something from scratch would help me develop my skills and be a great learning experience, but would it suit the project? Here's my initial thoughts on the subject.

Pros of using backbone.js

It's well written, proven and much better tested than anything I could build in a reasonable space of time. It follows a tried and tested route for developing the type of web apps I was looking for. Working within the clear confines of the library would help to speed up the development of the app. It would also speed up on-boarding of new members of staff faster than having them learn a custom framework first.

Cons of using backbone.js

The framework won't be mine, I won't know it as well as something I'd written myself. I will have to work around the differences between a generic framework and my specific needs. As we are developing the application in an agile manner, it's impossible to know if the framework meets our, as yet, undefined future needs.

Initial Conclusions

Yea, this all pretty much adds up in backbones favour, doesn't it? Using a generic framework would be faster and would help keep my code from becoming a sprawling mass. The smart thing to do would be to immerse oneself in backbone and really get to know it. My only remaining doubt was about the actual needs of the system we were building.

Further thoughts

There was still that nagging doubt in my mind though. How could I learn a new framework and expect it to keep my code neatly organised, when what I needed my code to do kept changing and morphing as we worked on the user journey? I was busy thinking about how I couldn't build something as polished as backbone in a short space of time, when it occurred to me that perhaps I didn't need to. Building a framework that was specific to the apps needs as they grew and developed might actually be faster, as changing my own code is easier than changing directions within a new framework. It also occurred to me that my framework wouldn't need to be as good as backbone - like everything in commercial software, it needed to be adequately good. Especially as I expect the code written in this early "let's get something online as quickly as possible and refine it as we see how people use it" stage to be re-done at some point when the system requirements are more fully understood.

This new idea had other benefits too. By building and developing the framework to the applications growing needs I would have a much better understanding of the system. Later on, when the app was more mature, it would be much easier to put it into a generic framework like backbone.

So far, it's been an amazing experience. I've learnt a truckload and really enjoyed it, the app works well and seems pretty solid. I also feel like closer to the system, it's my code, I know which bits are optimised and which bits aren't. I also know exactly how long it will take to change the areas that need to adapt to user requirements.

I am happy with the decision I made and the results we've had. I know so much more about how the app should work that I would do a much better job of putting it into a framework. I still have plans to do that, but I have more to learn about the system first.

New job

Last month I took the decision to leave Peach and move on to a start-up company called Toowist. It was a tough decision for a number of reasons: I have some good friends at Peach and I think it's a great place to work. Unfortunately, I wasn't coding very much at Peach and I've come to the conclusion that I am, at heart, a developer.

I have been working at Toowist for 2 weeks now and the days have flown in. I have been plugging into Spotify and churning out code, which is pretty much where I am supposed to be.

Technology

Toowist is a tourism company based around providing socially sourced travel guides. Obviously there is much more to it than that, but here I am interested in talking about the code. The site is going down the web application route and it's been awesome working on a system where the front and back-end are totally detached.

Working with bright people is always a pleasure and it very much helps whatever project you are developing, it's vital though in a small team of three that everyone gets on well and are pulling in the same direction. Again, I think we've been fortunate here in that we are agreed to release code early and often so we can learn from mistakes and take on-board feedback.

To summarise, all is busy and all is well. Long may it last.