The question of who or what the Me is, is not a simple one at all. – Mark Twain

October 25, 2007

People often ask me, what do you do?

For most of the population I suspect the answer is easy, and satisfying. But what do I say? Software engineer, software developer, software something, software nothing. I feel that whatever I say will mislead people, I don’t purely develop, goodness no. I probably spend 35% of my time writing code, I invest the rest of my time in a plethora of other tasks, from investigation/research, to engaging with customers, helping to solve problems and a multitude of other tasks.

It feels as though Im doing myself a disservice my calling myself a “developer”. Having said that, that’s what I choose to describe myself as, why? Well, there is a few unwritten rules in the world of software.

Rule 1: If you call yourself an architect, it means you do no real work, have probably lost touch with the man at the key board and are set in your ways. (Of course I jest, but it’s not as wide of the mark as many people I have met would agree)

Rule 2: Consultants – will try and sell you a solution you don’t need, won’t tell you the truth, and will manipulate the people they have a grip on to further their own interests in a company. Beware the consultant, and beware the consultant that works only to sell.

So, looks like I’m sticking with “developer” for the time being.Another thing that really concerns me about this industry is how it appears as though in order to “move on up”, you have to consciously lose your developing skills in order to get people to see your other skills. Become an excellent developer at your peril, the glass ceiling is low, that really disappoints me.

On the flip side, those people that have got into positions of importance and credibility by remaining close to their technical skills get my full and complete respect, and I’m very lucky to work with many of them. Speaking to kings (directors of IT) and paupers (software developers) with the same ability to affect, is perhaps the most important thing I can work on right now.


They say that time changes things, but you actually have to change them yourself – Andy Warhol

July 15, 2007

It’s easy to forget how fast things can change, especially in an industry like I.T. Recently, someone introduced me to the concept of “boiling frogs”, and that a frog will jump out of boiling water if put straight in, but stay in the water and boil alive if the water temperature increases gradually. To some extend this is something that we are all affected by, I mean, from the age of 6, you look in the mirror every day, and barely notice anything other than your hair getting longer. 20 years later you are 2 foot taller and have to shave twice a day.

Back to I.T, an important lesson I’ve learnt recently is to make sure you are always aware of how your environment changes, because without this, you will struggle to get better at what you do, you’ll also end up missing opportunities. Lets take web services as an example, 4 years ago no one was using them in anger, 2 years ago, if you did web services = soap over http (smtp?! Like using a motorway to sail submarines) and now 85% of Amazons web service calls come in the shape of REST. Admittedly my example isn’t great, as there are far better example of rapid change, waterfall vs agile being a good one.           

I suppose, deep down, that’s one of the reasons I enjoy my work so much, because I know not what to expect, and I feel I’ll always have the opportunity to learn, im not sure how many other industries that can be said to be really true of. People say “I have 20 years experience in Banking” I say “Do you?” or do you have 1 years experience repeated 20 times?

I look for a few things in a job, 1) Opportunity to learn 2) Work with good colleagues  (and the word ‘good’ comprises of multiple facets) and 3) Be appreciated . Of course there are many other factors that effect day to day life, but those 3 standards are mine at the moment, they’ve already changed as I’ve evolved through my life, and I’m sure they will change again.

The proof is in the profit.

April 16, 2007

A blog is often like an interior monologue. I feel I need to put a few things down, even if its just so I can read it over a year down the line and see how naive I was/still am.A pretty good measure of success is profit. Be that profit, money, time, love(?). If you get lots of something good back from what you do, it means you’re doing well. (Stay with me…)

 Software engineers, are engineers, do they always look for the most ‘profit’?

 Or are they better at solving problems?

Sometimes software engineers build software to make money, sometimes to streamline a process, sometimes just because they can’t be sacked. Making money is where the real test lays, you have to be clever and smart to make money, they aren’t the same thing. Engineers are generally clever, they can deal with complicated ideas/concepts, simplify solutions, but are they as smart? Do they understand the factors that make a solution “killer”.

Often, I feel, it is the last mile that lets most development down, lots of hard work goes into developing a solution/product, and to quote Jurassic Park “They were so busy wondering if they could, they didn’t stop to consider whether or not they should.” Feature creep, software bloating, and parts of the solution that only the person that wrote the code understand appear. The pricing model gets looked at by one person, whilst the code was looked at by 60, no one thinks to get some customers, but the solutions great right? Only in your head. Agile software development helps here, as the customer should drive the product, but far, far to often the customer is never there, the developer self diagnoses and the result isn’t so great.So, the proof isn’t in the pudding, it’s in the profit.

Money is better than poverty, if only for financial reasons. – Woody Allen

March 7, 2007

I had an interesting conversation with Paul Downey the other day. REST is cool, its cool because its straight forward, pretty easy to understand (if you understand how a browser works, you understand REST), and its intuitive. However, no one can really claim to have implemented a REST web-service (and why would they, it’s a noose for the RESTians to hang you with).

Amazon and Yahoo all have apparent “REST” apis, that both break the first rule of REST, don’t use a GET if its not ‘safe’ i.e. don’t use a getter(http GET) to perform the actions of a setter(http POST). This is perhaps more obviously ‘wrong’ in the world of REST, but many of the rules are unwritten. Should I post to or or both? What should I do if someone sends me data in a format I didn’t expect e.g. Content-Type=text/html, when I expect text/xml?

Maybe this is trivial, but the point is that without guidelines or rules then how can REST services be consistent? Well, they can’t, perhaps that’s their advantage, perhaps not, depends if you’re an enterprise or a basement developer I suppose, and I suppose that’s why we have SOAP. Joy.

Great article how to provide a web api, talks about keeping things simple, which I think is the key to success. Again here Alex talks about not using HTTP for an unsafe operation. Its clearly wrong when you look at the http spec, but why services do it is really easy to answer. Because users can do cool stuff just by typing text in their address bar, they can delete photos on Flickr, send a text from Gizmo. Do they care that it’s not RESTful, I doubt it, not if they’re making money.

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.

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 :

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.