the lows

We’ve all heard the startup “war stories”, usually in the form of how hurdles were overcome to “smash it” or the gallant loser that could do nothing to stop his business falter. Now when reading these things I’ve always found it hard to empathise, because at the end of the day, I’m just not actually experiencing them, even the greatest writer in the world can’t make that happen. There often tends to be some new-found wisdom attached to these stories because time affords you that. I’m not sure if hearing it from the pit makes much difference either, you’ve got to feel it, then really not forget it, maybe it should be written down as it happening, not when it’s finishing, or maybe not. However, things really feel real when you’re in the thick of it, there are no anecdotes, no perspective, no money, only tomorrow, only bills, only lack of sleep, only walls not doors, the lights don’t turn on. It’s not hard, it doesn’t make you a hero, it doesn’t deserve sympathy, it’s not the way it should be, how it should be doesn’t matter because it’s the way it is. The Lows.

questioning the truth

So, a colleague once told me of a story where an important academic paper (well important in its respected field) presented results that turned out to be false. Not exactly NEWS (think more first-world-problem) but this paper was peer reviewed and appeared in a prominent journal but still managed to slip through. This paper turned out to be cited in many places and only when my colleague tried to reproduce the results many years later did it become apparent things were not right – it turned out to be a bug in the original authors code that caused skewed results in his empirical analysis.

The thing is though, this kind of shit happens all the time, and it’s really fucking annoying. If you attended any conferences, meetups, usergroups, etc this practice is rife. Someone standing in front of an audience says something and it’s almost always instantly taken as fact, without the need to provide sources of proof. The audience then believe this to be true, as in many causes they are in no position to prove otherwise, and those that do voice an opinion are seen as being “aggressive”. The sad fact is that most of the time errors/hearsay go uncorrected, and people walk away misinformed.

The fact of the matter is that you really need assume what someone has said might not be true, do your own follow up and make decisions based on what the evidence supports. Remember that many people have agendas, and also that it’s very possible that speakers are talking about something that they have only a rudimentary understand of. Don’t blindly assume that what someone purports to be be true is actually the truth.

managing people like they do in the movies

Blogging about how hard you are to “manage” is possibly not top of the list of the smartest things I’m likely to do. The day will no doubt come when I’ll be contacting Google begging, pleading and grovelling to get this damn article removed from its cache. Serendipity will mean this is likely to bite me, and bite me hard.

It’s been a while since I’ve taken my place in that ageing behemoth of corporate management structure. Occasionally I’m thrown back there when either I think too hard or I’m told a story of the woes and misery bestowed upon a leaders minions as he marches forward “managing” those below his threshold. It’s like everyone heard that the do-as-I-say-or-I’ll-make-your-life-shit style of management doesn’t exactly work but someone forgot to tell those in management. It’s not a pretty sight to see.

So yes, people still manage like it’s the 1920s, ’cause that’s how they see it done in the movies, man! Just like how having sex like it’s done in a porno is probably not what you want to do when you’re tucked up in bed for a night of love with your other half. However, what these two things do share in common is that bringing up the topic doesn’t seem to result in an optimal outcome.

Have the gall to bring this up with your manager and you’re likely to be branded, then derided, and finally sent with your tail between your legs to your (now) wall facing desk. Even the thought of saying no or questioning management is likely to lead to stress and anxiety in those that live with this day in day out. So much so that I’m even banned from bring up this topic of conversation with certain people.

How hard can it be to realise that you (presumably) were employed because you could do the job? You know more about what you are doing than those managing you? Therefore you are going to be the best person to make any decisions. Sure, there are jobs where this may not make sense, there are exceptions to everything, but micro-managing an intelligent workforce is the worst management decision of all.

Joel Spolsky wrote about the very same topic and suggested that management should actually be called administration. This makes sense.

People being stressed out about their manager is so wrong on so many levels. Actively reducing the quality of someone’s life is not something to be proud of. You should be damn well fucking ashamed of yourself if you are. If there is a problem, talk about it, try to sort it out, advise them that the job might not be suitable. Leave your ego at the door, you don’t need to control everyone’s life, settle for controlling your own.

the internet and i

If you are able to read this please keep it to yourself, don’t tell anyone about it. Your ability to possess information that others do not have access to is crucial to moving only in the forward direction. Yet there is very little information now that is not readily available to everyone. The internet is almost ubiquitous. Rewind a mere 15 years though and observe how the landscape has changed so dramatically.

Back then a PC was the something only the posh kids had. My school was fully laden with BBC micros that you could only use to control some piece-of-shit-circuit-board that you had cobbled together to light up a few LEDs in the form of a traffic light.

I still remember to this day getting my first PC – a (big) Compaq laptop of sorts. It was purchased second-hand from a shop that specialized in guns, knifes and guitars – I still have it somewhere. They probably didn’t even know what it was. When I read stories of people in the 80s having PCs it makes me laugh as, in my world, this stuff was sooo out of reach that you wouldn’t believe.

Still, what would the general public have done with the PC back then anyway (apart from gaming)? The internet was a luxury goods item at this point. Even at university only a few computers had internet access. However, between ’95 and ’97 it exploded. You were faced with a computer lab full of students looking up porn and printing out the pictures (I mean they were not much use unless you printed them out, right)! Those were the days of looking up what you wanted with reckless abandon without feeling that someone or something was watching you – soon to be quashed with the corporate firewall and government legislation. Make no mistake though, we are still in the golden age of the internet. Laws and legislation will likely mean that the freedom we associate with the internet now will not be the same 30 years down the line.

What puzzles me most is how we got by programming without the internet? If tonight I decided that I wanted to learn OCaml to build some super useful web service, then I would start by searching Google. I’d get binaries, sample programs and documentation in minutes. If I had a problem, I could search on Google or ask a question on Stackoverflow. The barrier to entry is just non-existent. I struggle to remember exactly what we had to do all those years ago. It must have been ridiculously hard compared to the present day. But this is good. We got information easily and moved forward. That said, the internet does have its bad points.

We now struggle to get things done because we can listen to music online, watch videos, read blogs, not to mention the ease with which we can communicate with friends using social networks. What the internet gives with one hand it takes away with the other.

I’m often tempted to unplug the router and see how I get on with work minus the internet. Invariably at the last minute though I find some compelling reason to have it switched on, then the thought of uplugging it fades into nothing and time just slips away again.

on being open to change

How easy is it just to say no? I think you’ll probably find just about as easy as it is to always say yes. In the past I have often found myself entrenched in that no camp. It’s so easy to hate a company, a stance or an ideology without even attempting to think of the why.

I recently decided to try out an approach where instead of following my five second gut instinct assessment, I would instead spend some time trying to overcome my own (possibly) over zealous opinions.

My test subjects for this were the guys at 37signals. I frequently found myself disagreeing with most things these guys were saying for no reason other than the aggressive way they generally put forward a point. This is a real stupid thing to do – even more so when you see it in writing!

Anyway, in this new era of love and enlightenment I picked up the book Rework by Jason Fried and DHH. I was immediately surprised how much I identified with the things these guys were saying about running a business, from focusing on products that can make a profit from day one, to abandoning long range forecasts (or to paraphrase “elaborate guessing”) about your business. So two guys I thought I “hated” actually hold opinions pretty close to my own, i.e. I was being an asshole!

Before anyone gets the impression that I’ve now turned into the “super fanboi”, I should say that I don’t think that Rework described THE way to run a business. It’s simply A way to go about things, and one that happens to be close to what I believe. For example, the books contains ideas that may fall apart when it comes to dealing with large enterprises or when trying to build “uber” companies like Google and Facebook – who can argue with their success. However most of the ideas seem spot on if you are trying to build a small to medium B2B business.

So the moral of this story is try to see past the way information is being presented to you and look at what the information is actually telling you – this is true for both the hater and the fanboi. However, it should also not be overlooked that if something is shit, then say it’s shit.

is ruby killing your career?

I’m probably at the point with Ruby where I consider it my programming language of choice (I program in both Ruby and C++ in my day job).

Over the last few years I’ve kind of grown to love Ruby but I’m not really one to get passionate over someone else’s choice of programming language – apart from Java, which, I’m sorry, I hate. However, when it comes to employment, there is no doubt in my mind that being competent in a particular programming language can strongly influence A) getting an interview and B) getting the job.

This is why ruby developers, like me, are killing their career. Sure Ruby is cool and Rails is awesome but do a quick check on job boards and see how many people are looking for a ruby developer. Actually, let me save you the time I’ve done some of the work already.

I’m not claiming this to be scientific in anyway what-so-ever but it does warrant some thought. I only searched using the programming language as a keyword, which, I know, may not give the full story but should convince you there is some merit in the point that I’m trying to make. Additionally (and I suppose somewhat importantly) my search area was restricted to Scotland.

First up I carried out a search on s1jobs.com. The table below gives a summary of the results:

Language	Number of jobs matching keyword
Ruby	3
Java	18
C#	26
C++	9
PHP	7

I then tried a cwjobs.co.uk:

Language	Number of jobs matching keyword
Ruby	2
Java	35
C#	45
C++	45
PHP	4

As you can see, the job prospects for Ruby developers here in Scotland are somewhat dire. Sure, people don’t always look for a particular programming language when employing someone (which is a decent policy) but, as I said above, it helps a lot.

I decided to take my crude search a little further as I thought “Hell, there will be waaaaaaay more cool Ruby jobs in London”. Below we have the results, just cwjobs this time:

Language	Number of jobs matching keyword
Ruby	57
Java	792
C#	838
C++	611
PHP	196

That was kind of disappointing! Ruby still doesn’t do that great – even worse when you realise there were over 200 that mentioned Perl and 150 Python. By the looks of it if you want to maximise your chances of getting a job in the UK, and already doing Java or C# in your day job, you’d be better off learning C/C++ in your spare time.

Is all this going to stop me coding in Ruby? Probably not. Is it worth thinking about for a minute? Yes sure. If I was starting my own company and was hoping to get some developers in then I’m likely to be faced with a problem. Yes you can train people up, but that costs time and money. When they leave it may be worse, as the chances of finding replacements at the required skill level will be difficult. Finding a Java/C#/C++ programmer is bound to be far easier.

So is it all bad news for us Ruby developers? Well not if you plan to move to California – yeah yeah I know I’ve went on about it before. I’m not exactly sure of the popular job boards in the US so I went with the only one I knew off the top of my head, careers.stackoverflow.com. The results for the Bay Area are as follows:

Language	Number of jobs matching keyword
Ruby	27
Java	33
C#	10
C++	23
PHP	17

Maybe this was a skewed sample set but impressive all the same. So moral of the story is if you want to be a well paid Ruby hacker make sure you don’t stay in Scotland :-).

the future is email

In a recent podcast Jeff Attwood and Joel Spolsky were discussing the virtues of email. As a somewhat brief summary of the discussion I think it’s fair to summarise that Jeff hates email. As it happens I’m inclined to go along with him on this one, but possibly for different reasons.

From what I can gather, the problem Jeff and Joel were describing with email is that we end up with an inbox full of emails that never get read or processed, and to allocate the time to process these mails and respond would be a job onto itself. To be honest, I don’t suffer this problem quite as bad, mainly due to the fact that I do not receive in any shape or form the level of email that both of these guys do. As a result, it’s hard for me to appreciate the hate of email for the same reasons. However, I feel there is a far more toxic fallout to the email culture than that which is described.

It has come to my attention recently that many (large) organisations still use email as a way of providing an API to their service. What do I mean by this? Well, in this digital age it is often the case that a web application uses the API provided by another web service to interact with it. For example, if I want to receive a list of the tweets that I’ve made, the twitter API allows me to do this by accessing a given URL, and returns the data in the format of my choosing. Similarly, I can also publish a tweet by posting data to a given URL. This is all rather nice – everything is communicated over good old HTTP allowing easy integration with other services.

However, many firms that are not technologically aware are using email as a mechanism for inter app communication. I don’t want to bash individual companies here but the ones I have personally dealt with are multi-national companies with profits in the billions. Yet despite such profits margins their software systems look like something seen in War Games. To perform any communication with these systems you send an email, and responses are returned to you via the magic of an automated email. Thus, you have to parse the email body and/or parse an email attachment to get the response data. It’s as if Web 2.0 passed like an amoeba in the night without these companies so much as blinking.

You may say that it must work for these companies to be making the profit margin they do. However, as customers, we are paying thousands on development costs to integrate with these systems – in many cases we have no choose in the matter. At the end of the day these companies are slowly falling behind and if they are choosing not to innovate at this level, I personally don’t hold out too much hope for innovation on a wider scale. This kind of strategy no longer works, Google and other such companies have long since blown this way of doing business out the water. No-ones’s saying the death of the non-innovators is going to be quick!

So what is the message I’m trying to get across? Well first, email for this style of inter app communication isn’t really helping anyone. If you are thinking about doing something like this, please think again. Also, on a more general note, can companies that fail to innovate survive in this technology driven society? It’s obviously hard to answer this question with definite authority, but going by gut feeling and history, it doesn’t look good.

the mark of sucessful software

Right, so I’ve been thinking about this for a while now. It’s a question that has been contemplated more times than anyone cares to remember, and still we have no good way of achieving the goal that it sets out. A quick search on Amazon will probably yield a thousand books on the subject – each and every one making you think the next is the holy grail. So am I going to tell you the question?? Well I suppose I must.

What is successful software? I’m sure the exact definition of this is subject to opinion and means different things to different people. Therefore all I can do is bore you with the details of what I think makes successful software:

Software that the end user is happy with – a no brainer, if no one wants to buy or use it then you may as well give up. Happiness encompasses how the software looks, the user experience, and the functionality.
Software that is finished to schedule – no one likes to wait, from management to clients, and even developers. Software that is late causes stress on everyone. Scheduling is hard and it has to be realistic. The end result of cramming and cutting corners is poor quality.
Software of high quality – you can finish on time but if it doesn’t do what it needs to do in a manner the user expects, or simply is littered with bugs, then there is not much to be cheerful about. It has been documented ([1]) that bugs caught early can mean 1 hours spent now can save up to 3 to 10 hours later. As a result bugs caught after release cost between 40-50% more. This is always worth keeping in mind.
Software that is cost effective – achieving all three things above but at a cost which prevents profit does not make sense. Costs are important and developers should also be mindful of this – even for internal software.
The developers are happy and proud – I’m sure there are many employers that would be happy if they got software that satisfied the first four criteria but couldn’t give shit how their employees felt or what it took (out) of them. Stressed out employees are no good, they will only leave, and sooner rather than later you will find that you can no longer attract those employees that are smart and get things done. It’s surprising how easy it is to keep people happy without spending a lot of money.
The management are happy and proud – if all the above is achieved at the expense of a stressed out, worn out, nerve shattered manager, then the same problems that arise with unhappy developers can be seen in management with the same negative results.

Now that we have a definition of successful software we can ask the natural question of how to achieve this. As I mentioned earlier, there are more books that I care to read telling me how to do this. Yet I feel none of them can apply in every situation. They all preach some methodology from the latest fad to the decidedly idiotic. If any one of these methodologies actually conclusively worked, there would not be as many books. I’m convinced that the truth lies somewhere in between them all and depends not only on the organisation, but on the people involved. So surely those involved in creating the software may have a better perspective on what will work than the author of a book? (This is not to say you can’t steal ideas that you have read and apply them in a suitable manner.)

I have my opinions on what I think would work for me, and is something that I can probably document in a follow up post. For the moment I will leave this with the statement that don’t be frightened to break rules and invent your own when something is not working. This is the only way we can make our software more successful.

[1] Rapid Development – Steve McConell

sticking with what you know

There comes a time in every programmers life when they have to learn new things and step out the box. Yeah it’s difficult, for sure. It’s all too easy to create the latest application in your software empire, using a language you’ve been developing in for the last 10 years. However, the real problem is thinking this is the only choice. When is it time to abandon this certitude?

First, we cover the forced abandonment. This is when you are pushed kicking and screaming into pastures new, whether you like it or not, i.e. the new job. Here, not only is the new language curve ball thrown (viciously), but you also get whole new set of business rules into the bargain. So what do you do? You program the new language like the old one, only translating the syntax in your head. This is not the best way to learn a language though. Why? Well consider those C programmers trying to program imperatively in Java, Java programmers in JavaScript, C++ programmers in Ruby, and so on. When there is a change in paradigm this mapping strategy just doesn’t work – a similar situation exists with languages that contain a more powerful expression set. It also encourages the behaviour where people learning enough to get the job done, without understanding what is really happening, or that there may have been a better way using “unmappable” language’s features. A better approach would be to write something small, and new, that allows you to explore the language’s features. I’m sure most people can think of something they could write. Furthermore, if you can make it useful to other people, or even your new employer, then everyone’s a winner! This is something I touched on before.

For many people though, this is the only time they will ever consider abandoning. This is sad, and a poor characteristic in a programmer. And to be honest, I just don’t understand it. That’s not to say that I don’t accept that people just do programming as a job, then go home and don’t think about it. However, it’s like most things in life, it’s nice to progress?

As a programmer there will also be other signs that the tide is turning, and you don’t have to be too alert to spot these. Previously I wrote “Perl is Dead, Long Live…Perl?” and being a big Perl fan it was sad to see the language apparently dying, so I know what it’s like. Some signs to look out for may be:

the language features are not moving on (Java watch your back) – the people who created it no longer care,
the community surrounding the language is dwindling – the people who use it no longer care,
there is little in the way of choice when selecting libraries/frameworks – the experts have fled,
other programmers have never heard of it – there is no buzz,
jobs using it are few and far between – businesses have given up on it, the death kneel.

However, this is all not to say that you give up on your language just because it’s no longer cool – popularity is by no means a great indicator that something will suit your needs. It need not be the case that you give up on your language of choice, instead it could be that you contribute and drag the language forward. But be careful with this one.

Finally, any decent employer will want to see that you are continually developing your skill set – their business needs are continually evolving, so why aren’t you? You are much more likely to land a better job if you contribute to your own education in some way. It looks good and it’s also something to talk about.

So go out and learn something new today, and stop sticking with what you know.

programming just isn’t that hard!

Programmers at times can take themselves, and their abilities, a little too seriously. The fact is that programming, in general, is just not that difficult. Sure, there are parts of it that are tricky but, at the risk of over generalising, the capabilities required by your run of the mill programmer are not that high. Are you sure I hear you say?

Well plucking figures right out the air I’d say that around 90% of applications involve a simple CRUD model. So what we are essentially doing is gathering data, processing data, and writing this data to the database. Two-thirds of this process is pretty simple, i.e. gathering the data and writing it to the database, this leaves the possibilities for hardness in the processing data phase.

Again in most situations the processing of data is pretty simple with no complex db manipulation or algorithmic mind games. Consider your typical web application for example. The processing of data is minimal, with little to no algorithmic work involved at all – I mean with Twitter there is literally nothing to do. Google on the other hand has lots to do: it has to make those search results shine. This is not to say that developing Twitter is simple, as the scaling issues will make your head hurt. However, scaling problems are only going to affect a very very small number of sites out there, but due to their ubiquity they are the ones we hear most about.

If all this programming nonsense is so easy then surely it’s difficult to make bad software?

Nope. The fact is that the only people who care what the code looks like are other developers. The code underneath could be shitter than an incredibly shitty shit and the end user wouldn’t know. As long as it carries out the task that they require the software to do, in a reasonably efficient and user friendly way, no one really cares. Oh apart from other developers.

Obviously nice structured code, that is easy to understand, free of bugs, and a maintenance dream is a good building block. However, it is by no means a guarantee that you are on to a winner. Marketing, user experience and coolness are all equally important, actually, they are probably much more important. I obviously can’t say for sure but I would imagine there are plenty of successful software products that are badly written but tick these boxes – maybe even most successful products, as they are free from the burden of the studious programmer.

So, essentially what I’m trying to say is that despite programming not being that difficult there are many other more important factors that contribute to the success of a software product. Many software products do their job, but the one that will be successful is the one that does it well.

All this is not to say that programming well is not important. On the contrary, it’s important to other developers who you work with and that is not to be underestimated. This is a topic for discussion another time though!

Finally, for those non-programmers out there, don’t start shouting “If it’s so simple why does it take so long”? Well just because something is easy it does mean there are not lots of easy things to do. I mean, hammering a nail into a piece of wood is pretty simple, right? But if I asked you to hammer 10 million nails into a bit of wood it would take you a long time. Remember this marketers and project managers.