oh no, I just updated a ruby gem!

Are you a ruby developer? Do you want to manufacturer something to do? Well here is a quick tip. Take your beautiful working Rails 3 application that you started creating 6 months ago and type in “bundle update”.

I don’t think there exists a time when I have issued that command and then 10 seconds after it completed not thought “what the fuck was I thinking”. Just about every gem that updates seems to make several breaking changes. For real comedy value it’s worth doing it between major Rails releases, actually, I take that back, make that minor Rails releases.

This just doesn’t seem to happen with C++ libraries. When coding in C++ (which I do almost every day) I can reliably update to even major version changes and still be pretty much guaranteed that what worked before will still be working now. At most you get a “deprecation” warning. Not in the Ruby world, oh no, here progress is rapid but backwards compatibility is an afterthought. It really is no wonder that enterprises are so cagey about moving to, how can we say it, well in the words of Steve Yegge, hardcore liberal languages. There is something to be said for stability.

So is this a bad thing? As much as I would like to say that I think it is, I’m just not that sure. There is nothing more frustrating than using something that is not willing to change (I’m looking squarely at you Java). It’s the fact that there is no attempt to maintain backwards compatibility for at least a short period of time that doesn’t fill me with confidence.

These days you see many people picking the latest and greatest technology to build a business on. This always makes me squirm just a little. This may be OK for a small business with technical founders. However, it makes little sense for a company with shareholders where employees can leave at any time. I certainly wouldn’t want a company I’d invested my money in being in left open to the vagaries of change quite so much.

stop trying to show how smart you are

Sitting feeling bright and somewhat giddy with my own self confidence I decided to dust down my copy of “C++ Template Metaprogramming” by David Abrahams and Aleksey Gurtovoy. Thinking I really need to be the master of something and further thinking C++ template programming was that “thing”. I approached the task with some gusto for at least a few days hours minutes, however, as with most advanced study you really have to be willing to dedicate your life to it. It’s never long before the inevitable gloom of reality sets in and you realise that this is more than an afternoons work. Without much control your brain starts telling you that there are much more important things you could be doing. Thankfully for everyone else on your team you stop and decide that it’s just not worth it.

The fact is that writing code that only those who have decided to dedicate a fair chunk of their life to is never going to be the right choice. There is nothing worse than trying to understand code like this. There are times where it pays to be smart, like when you have a better (much) faster algorithm, or doing something saves you hundreds of lines of code. But most of the time you see this kind of code it’s people just trying to prove how smart they are.

Now C++ is not alone in this. Ruby has exactly the same problem – you can get stuff happening as if by magic. I could be wrong but I imagine most people read code from top to bottom, working line by line, they don’t expect code to be auto generated or happen as some elaborate method_missing technique. Sure I can maybe relax my vitriol for those building frameworks where things are being used in some generic unknown context. However the vast majority of applications out there don’t have to deal with these problems. The biggest problem these applications face is that the developers creating them want to architect some elaborate framework to fit a very specific use case – it almost makes me cry. I’m not sure why as a profession we don’t revel in an approach that oozes simplicity. This is certainly what the smartest developers I’ve working with have always managed to do.

writing code used to be simple

Not that many years ago, though more than I care to remember, the process of writing code started with pen on paper. I’m not talking about 1970 here where you had to apply for compute time on some mainframe to see your ideas come alive, rather 1995 where it seemed the normal practice was to encouraging us disobedient students to first distil our ideas (and code) on paper. I’m gathering that this practice is largely forgotten? Despite its disappearance this can still be good practice but is made difficult by the increasing complexity of modern code libraries and frameworks.

Take Ruby on Rails for example. This used to be the poster child of getting an application up and running quickly. This might be still be true if you have years of experience developing Rails applications but for a newbie, forget it, you are going to struggle. The introduction of the asset pipeline, amongst other things, has made learning how to use Rails a labour of love.

It’s not just Rails though. A lot of the code that you need will already be wrapped up in a library written by someone else. Creating a modern software application is essentially just a case of rearranging these packages into a new unique order. In fact, the need for the order to be unique can probably be dropped.

Using these libraries is good though? Right? I mean we should never “reinvent the wheel”?

So how many times do you find yourself spending more time trying to figure out how the fuck to use some library than if you had written it yourself? No-one really expects there to be detailed documentation, which is just as well, as in general you’d be thoroughly disappointed. Maybe it’s because I’m dumb, but figuring out how to use a library can be a complete time sink. I mean, I hate to encourage this, as it seems like I’m committing a heinous crime, ’cause that’s what I’m told I’m doing, but just write the code yourself if it gets it working quicker for you. Obviously don’t rewrite the exact library that you are shying away from using, that is just stupid, but if you only need a subset of it’s functionality then go for it.

Never forget though, there will be a team of astronauts telling you that’s not what you should be doing. They will be spouting dogma, about this and that. However, if abandoning some well written (and not so well written) rules allows you to create a product that people use and love then tell the astronauts there are people who want to hear their shit on the moon and let them go there.

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 :-).