All our knowledge has its origin in our perceptions. – Leonardo da Vinci

April 23, 2008

One thing that has recently become very apparent to me is that, in fact, people skills over any number of technical skills, are far more important in my career. This has become increasingly apparent as I have recently changed jobs, moving from a permanent position at a large “blue chip” (hate that description, like “red-brick” unis) to slide into the contracting field. It just suits my lifestyle at the moment, no mortgage, no women, no cry.

It seems as though I’m beginning to realise that appearing to be successful, is far more important than actually being successful, or being good at your job. In many ways this is a sad but true conclusion of the industry I seem to be operating in. Admittedly, job-hunting magnifies this fact by a factor of 10, because the cost and benefit to the employee and employer is at its highest.

I’d compare getting a job to a crisis situation, like escaping a burning building, crisis brings out the best and sometimes worst in people. Its also a huge PR exercise, selling yourself to someone. This is where it gets interesting, because, traditionally, the “alpha geek” developer, who is very good at their job, is in fact a terrible salesman, in fact all the developers I know shirk at the thought of the slimy salesguy/guyess. And (never start a sentence with And), herein the lesson lies.

You do actually have to turn into a salesguy to progress in your career. If you don’t you’re going to struggle.

The thing is humans, are clever, but inherently simple when it comes to processing information in short terms. So, in situations where you only have short terms, you have to exploit this. I dislike using the word exploit, but thats what it is, and this is where I’ve had my greatest struggles. I mean, I’d certainly not lie, or fabricate, or mislead, but I have had to learn that acting as though you are the greatest at what you do is the only way you’ll find success, especially, and notably, whilst you are still young, i.e <25. As credibility is inversely proportional to age, it shamefully appears sometimes.

The reason this has been such an epiphany for me is due to the fact that I know it is not in the nature of the stereotypical software developer to be like this, and I’ve noticed the change I’ve had to go through in order to be successful. I’m keen it doesn’t change me fundamentally, but Im also keen that I develop it further go help me get to where I want to be.

So, the old David James, software developer = quietly confident, bright, technically sound.

The new DJ = Experienced, leader, salesman.


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.

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.