I just returned from ConFoo 2015, which BTW is a great conference with lots of good talks and events. The good thing about a multi-discipline conference like this, is that you get to talk to people from different technological and programming backgrounds.  I met people from the PHP, JavaScript, .Net, Java and Python worlds and -inevitably- we got talking about Ruby and the best way to start learning it. My part of the conversation always boiled down to the same arguments and recommendations, as distilled through my own experience of coming to Ruby from a C++ background. Here they are:

About You

You are an intermediate / advanced level developer who understands object-orientation and is familiar with design patterns. You’re probably a competent Java, C#, C++ or Delphi programmer.  Less likely, you’re a PHP, Python or Perl programmer but you still grok OO and DPs. You appreciate elegance, efficiency and the joy of coding.

Why you need to do it

Because learning Ruby will make you a more efficient and happy programmer.  Even if you decide to stick with your existing language, knowing Ruby will make you a better programmer in it.

Step 1:

Read this book:

it brilliantly takes something familiar (design patterns) and uses it to illustrate Ruby concepts and idioms.  It starts with some fundamental concepts and then cranks up the intensity with each chapter. By the time you finish reading it you’ll have a good basic understanding of Ruby. As a pleasant side-effect, your knowledge of design patterns will probably also have increased. If the last 2-3 chapters seem a bit of a struggle (which they might if you come from a static language background), just leave them out for now - you’ll come back to them later.

Now you can try this tutorial. It will recap your basic Ruby knowledge in a practical, interactive way. It will also fill-in any blanks left by the Design Pattern  book.You now understand basic Ruby principles, as well as concepts such as blocks, duck-typing and the usage of modules. Time for the next step:  

Step 2:

Complete the micro-blogger tutorial. It will reinforce the basics and will show you how to use Ruby in the wild, that is by integrating gems and third-party APIs into your code just like you need to in the real world. Once you’ve done this it’s time for some more advanced knowledge: You need to get familiar with the way Ruby handles lambdas and closures. There’s a plethora of articles you can google on the subject.  With extreme bias, I would recommend this one. 

You must get intimate with Ruby collections, specifically the more functional (i.e. map/reduce) aspects of them. So go and read chapter 9.  While you’re at it, feel free to read the rest of the book too. It certainly won’t hurt and it can be very informative.

Step 3:

OK, you now understand the Ruby idioms and appreciate the ‘magic’ Ruby performs. But how does this magic happen? Time to find out by whipping out this book: This book will help you comprehend how Ruby works and how you can utilise it to the max. It will get you acquainted with meta-programming (i.e. code that writes code) and will explain how the Ruby Object Model functions.  This is essential knowledge if you want a good understanding of the language. Once you grok the Object Model it becomes much easier to learn stuff like Rails or write your own gems.  The book is also littered with little Ruby idioms and techniques, a.k.a ‘spells’, that will increase your efficiency and understanding ten-fold.Once you’ve been through this book, you may want to re-visit the last three chapters of ‘Design Patterns in Ruby’; you’ll find they now make a lot more sense.Now go and test your Ruby skills here.

Step 4:

Finally, you understand enough of Ruby to make it your own. The last step is to build your own project. Pick an idea, any idea, it doesn’t matter. It could be something you’ve already done using another language, maybe an old work project. If you can’t think of any, here’s an idea for a project. Now implement it in Ruby. If you get stuck, this book makes for brilliant reference and guide. Once your project is working, sit back , light up a cigar and bask in the knowledge that you’re now familiar with an elegant and effective all-purpose language that will make your programming life much easier and more enjoyable.  Happy coding!

Continue reading

I’ve spent the last 18 years as a professional software developer. I’ve had loads of jobs, both as a ‘permie’ and as a freelancer/contractor. I reckon I must have read over a thousand job ads which I’ve looked into, that is I’d had more information about the job from sources other than the advert or the agency that published it.  I’ve learned one thing: to read between the lines.  IT recruiters speak a different language to us,  a language rich with subtlety and innuendo, a language which might seem simple at first but hides deeper meaning. As a service to the community I now present a handy translator from IT-recruiter-ish to common English. Make sure you look it up next time you see the job-advert of your dreams. 

They say	They mean
An exciting opportunity has come up	Exciting for us as the commission is huge; for you not so much
You'll be working in a dynamic environment	You'll be working all hours under the sun while requirements constantly change and managers run around like headless chickens
An environment that rewards achievers	unless you work 80-hour weeks you get no bonus
A work-hard, play-hard ethos	You''ll be treated like a galley slave by a bunch of imbeciles who think drinking a jug of vodka every night is 'playing hard'
Our client is a leader in their field	Our client think they're a leader in their field
A company with a high public profile	The local paper once had a two-column article about them
You will be encouraged to take ownership of your own projects	Success is shared, failure is all yours
A rapidly expanding company	Part of their annual cycle of firing & re-hiring
Salary is competitive	...if you're an a 18-year old intern looking for a summer job. And it's 1982.
Huge career progression opportunities	Layoffs planned in 2 months
They're using tried and tested, enterprise-level technologies	They're using Java EE
You'll be working on a complex, highly-configurable system	They're using Java EE
You'll ocassionally need to address issues raised on the legacy system	They're using Java EE
A company driven by results	Forget about Test-Driven Development
Development is centred around customer-focused delivery	Cucumber is out of the question too
A high-quality environment	But there will be loads of MS-Word-based documents
The company is currently transitioning from a waterfall methodology to Agile	They don't know what Agile is but they know it's meant to be good
It really doesn`t get much better than this.	It can get much better than this, but you'll never know it if you apply for this position.
Send your CV in now so you don't miss out on this fantastic opportunity!	Bwa-ha-ha-ha-ha!!

PS: this is work in progress. If there’s something I missed feel free to comment here and I’ll add it to the list.

Continue reading

A luxury beach house or a hut? Depends on who's looking at it.

I got inspired to write this after reading one of Mike Cohn’s recent blog posts. Now, before I begin, let’s get one thing straight: I agree with probably everything Mike has ever written about Scrum and Agile and I’ve learned a lot from his book ‘Succeeding with Agile’, which is essential reading for anyone practising Scrum. Did I say I agree with everything? I meant nearly everything ;).  Story-point estimation is the point on which I beg to differ. It’s my major bug-bear with Scrum, the one thing that I find ‘not fit for purpose’, broken, not working, kaput.

Mike, in his post, likens the definition of a story-point to the definition of a “yard”, i.e. a standard unit of measurement that can be agreed upon by everyone. The reasoning goes that, if everyone can agree on how long a yard is, then everyone can agree on how long a mile or an inch is and therefore have a standard frame of reference for future estimations. That would be fine and dandy if we had a real chunk of code which represented the true length of King Henry’s arm (say, for instance, Matz’s MRI code(1) ). The thing is, there’s no such thing as a ‘yard’ in software development. There’s no universal measure of how complex or long or time-consuming something is. Take what’s probably the simplest unit of measurement in the coding world: the ‘hello world!’ app. In something like Ruby, Perl, or even JavaScript(2) it’s one simple line of code. In Java it’s three or four and brings into play importing libraries, object-orientation, the main function, even the file system itself. So to a Java developer a ‘yard’ will always be much longer(3) and more complex than to a Ruby/Perl developer.

Moreover, a yard remains ever unchanging and unchangeable, unaffected by the whims of man or nature. Whether you’re tired or beaming with energy, in a good mood or in a bad mood, full of cynical experience or optimistically naive, a yard is a yard is a yard is a yard.  The same cannot be said about good ol’ story-points. Something that appears very complex or time-consuming today may well appear simple and quickly-solvable tomorrow. Knowledge is power and if I had a penny for every time I came back a week later and re-adjusted my estimate downwards for a previous story after learning a bit more about the relevant domain, well….I’d probably have enough money to buy myself a pizza. Not just any pizza, I’m talking 16 inch, thick-pan, filled crust here, the works. That’s a lot of pennies right there!

Not only that, but the way we define a ‘yard’ in software changes dependent on the observer’s technical perspective and even psychological or emotional state. Factors like personal and team morale, inter-personal relationships, outside influences, e.t.c. they all affect our ability to tell how time-consuming or complex a story is. On a ‘good’(4) day I feel there’s nothing I can’t achieve and my estimates tend to be overly optimistic, reflecting my psyche.  Conversely, when things are gloomy so are my estimates - everything seems like a huge chore to me. My definition of a ‘yard’ keeps changing, victim to a dozen or more fluctuating factors, none of which are taken into account when we come to ‘agree’ on an estimate during our planning poker. In every single planning meeting I’ve attended, ‘consensus’ is always closer to the estimate of the most senior/influential/charismatic person in the room. Trying to give objective estimates during planning poker is a bit like trying to avoid taking drugs at a Grateful Dead gig: peer pressure will prevail in the end. Still, I can envisage an environment where planning poker works fine. The trouble is, that environment consists of closely-knit team-members of similar experience, skill, background and ‘status’(5). Last time I checked there weren’t many dev teams like that!So what are we to do? Well, we can always fall back on Joel’s evidence-based scheduling approach. Or we can get Story-point estimation working right, using more objective measurements and accounting for a number of technical and environmental factors. I have some thoughts on this but they’ll have to come out at a later post as this one’s already getting too long.

Footnotes:
(1) feel free to replace with your chosen bit of legendary coding.
(2) not accounting for the surrounding HTML
(3) I’m not having a go at Java (this time), just making a point about complexity and size.
(4) I don’t have many of these, to be honest.
(5) For want of a better word.

Continue reading

Here’s a scene: you’re in the interview room at a really exciting company, being interviewed for your dream job.  You’ve already aced the technical interview and really hit it off with the team leader and the other team members. You can already imagine yourself happily working there. But just before you start visualising your first ‘employee of the year’ award, another person walks in the room. They introduce theirselves as the HR manager and ask if you mind being asked some more questions. ‘So, Fred’, goes the first one ‘what is your biggest weakness?’ ‘Ermm..’ you fumble, ‘..Ben & Jerry’s, I suppose’.  ‘No’, the HR person goes, ‘I meant as a professional developer’. ‘Why didn’t you say so’, says you, ‘in that case it has to be Herman Miller chairs. I’d sell my own grandmother for an Embody full mesh’.  ‘No, no, that’s not what I meant’ they say, ‘I meant a weakness in your abilities as a professional developer’. ‘Why would I tell you that’ you reply, ‘I’m trying to sell myself here, not bury myself’. At that point all the positive vibes you’ve built up have evaporated, your self-confidence is shaken and you’re beginning to wonder if this really is the right company for you. Yes, you’ve fallen victim to the….CURSE OF POINTLESS INTERVIEW QUESTIONS (ta-dah-dah).

Continue reading