A Unit Testing Framework In 44 Lines Of Ruby

February 16, 2011 By 22 Comments

TestingLate last year I attended some workshops which were being run as part of the YOW Melbourne developer conference. Since the workshops were run by @coreyhaines and @jbrains, TDD was a prominent part. Normally this would not be an issue, but in a spectacular display of fail (considering it was a developer conference in 2010), the internet was hard to come by, which left me and my freshly installed Linux laptop without the ability to acquire Rspec. Luckily a few weeks before, I decided to write a unit testing framework of my very own (just because I could :)) and so I had a reasonably fresh copy of that code lying around – problem solved. But, it got me thinking, what is the minimum amount of code needed to make a viable unit testing framework?

A Minimum Viable Unit Test

I had some minimal code when I first toyed with writing a unit testing framework, but then I went and ruined it by adding a bunch of features :), fortunately it is pretty easy to recreate. What we really want is the ability to execute the following code:

describe "some test" do 
  it "should be true" do 
    true.should == true
  end
 
  it "should show that an expression can be true" do
    (5 == 5).should == true
  end
 
  it "should be failing deliberately" do
    5.should == 6
  end
end
Read the full post

The Greatest Developer Fallacy Or The Wisest Words You’ll Ever Hear?

February 7, 2011 By 53 Comments

Wisdom"I will learn it when I need it"! I've heard that phrase a lot over the years; it seems like a highly pragmatic attitude to foster when you're in an industry as fast-paced as software development. On some level it actually IS quite pragmatic, but on another level I am annoyed by the phrase. It has become a mantra for our whole industry which hasn't changed said industry for the better. The problem is this, in the guise of sounding like a wise and practical developer, people use it as an excuse to coast. There is too much stuff to know, it is necessary to be able to pick certain things up as you go along – part of the job. But, there is a difference between having to "pick up" some knowledge as you go along and doing absolutely everything just-in-time.

Read the full post

Here Is The Main Reason Why You Suck At Interviews

December 8, 2010 By 14 Comments

Interview failI've talked about interviews from one perspective or another on several occasions, you might even say it is a pet subject of mine. It's fascinating because most people are no good at interviews and when it comes to developer interviews – well; let's just say there is a whole new dimension for us to suck at with coding questions, whiteboards and whatnot. Of course, the other side of the equation is not pristine here, the interviewer can be just as much to blame for a terrible interview, either through lack of training, empathy, preparation or a host of other reasons, but that's a whole separate discussion. So, why are we so bad at interviews? You can probably think of quite a few reasons straight away:

  • it is a high pressure situation, you were nervous
  • you just didn't "click" with the interviewer
  • you were asked all the "wrong" questions
  • sometimes you just have a bad day
Read the full post

Converting Integers To Words – Bringing Order To English Through Code

November 6, 2010 By 28 Comments

IntegerFor a few years now, I've been meaning to read Peter Norvig's old book, "Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp", but every time I started I'd inevitably get lost in the code due to my poor Lisp skills. For some reason I just couldn't absorb the introductory Lisp chapters at the beginning of the book. So a little while ago I decided to "begin at the beginning" and slowly started making my way through Peter Seibel's "Practical Common Lisp".

Inevitably, one of the first things I learned about was the "format" function. Format, is essentially the Lisp equivalent of printf, so you kinda need it to produce the old "Hello World". Just like printf and its ilk, format supports string interpolation via embedded directives. For example if you wanted to print two strings side by side but separate them by a specific number of spaces you could do something like this:

CL-USER> (format t "~a~40t~a~%" "abc" "123")
abc                                     123
NIL

One of the most interesting format directives is ~r which will take an integer and produce its English representation e.g.:

CL-USER> (format nil "~r" 123456)
"one hundred twenty-three thousand four hundred fifty-six"
Read the full post

Write A Function To Determine If A Number Is A Power Of 2

October 18, 2010 By 57 Comments

Power of 2One of my friends always asks that question when interviewing developers. Apparently it’s quite ambiguous and many people misunderstand – which is curious since I thought it was rather straight forward, but that’s not what this story is about.

When he first told me about this question my brain immediately went ahead and tried to solve it, as your brain probably did as soon as you read the title of this post, if you’re a developer :). After thinking about it for a couple of minutes I said that people should get "extra points" if their function uses bit hackery to solve the problem. I later realised that the most interesting thing about this was how I arrived at that conclusion.

The First Thing I Thought Of Was…

Something along the lines of the following:

def power_of_2?(number)
 return false if number == 0
 while(number % 2 == 0)
   number = number / 2
 end
 return false if number > 1
 true
end

Of course it didn’t spring forth out of my head fully formed like that, but the general gist was the same. This code solves the problem and, as you can see it is an iterative solution. The first programming language I learned was Java, the second was C, so you might say I was weaned on the “iterative approach”. So, whenever I am presented with a new problem, my mind always gropes for the iterative solution first. You might say I find it the most “natural” way to solve a problem.

Read the full post

99 Out Of 100 Programmers Can’t Program – I Call Bullshit!

October 17, 2010 By 64 Comments

BullshitSomething has always struck me as a little bit off, about that "statistic" (or its equally unlikely brothers, 199 out of 200, 19 out of 20 etc.). I remember reading Joel's post alluding to this back in the day, then Jeff's a couple of years ago, there were a few others, most recently this one. And as much as I want to just accept it (for reasons of self-aggrandisement), I can't. I've been in this industry for a few years now, in that time, I've met some really good developers, a bunch of average ones, even the odd crappy one, but I am yet to meet the veritable army of totally useless non-programming programmers that must surely exist if those numbers are accurate (the "architects" don't count :P).

Why Should Top Developers Seek You Out?

Whenever I see the latest post about how hard it is to hire good people, because x out of y developers are useless, one question immediately springs to mind. Is that x out of y applicants, or x out of y working developers? There is a massive distinction. Unless you're a company trying to compile stats by doing an industry-wide study, you can't really comment on the skill levels of all working programmers in any authoritative fashion. So, we must be talking about x out of y applicants. But once again, it's not applicants in general it's applicants to YOUR company. All of a sudden the headline is:

Read the full post

Learning A Software Development Lesson From A Children’s Poem

June 7, 2010 By 7 Comments

Shut Up

As I was getting ready for work the other day, some children's program was on TV. Normally it's just background noise, but today something made me pay attention. Here is what I heard:

A wise old owl sat in an oak,
The more he heard, the less he spoke,
The less he spoke, the more he heard,
Why aren’t we all like that wise old bird.

I've recently been on a kick of extracting software development related lessons from everyday situations and events – that little poem immediately made me think of opinions. Software developers are an opinionated bunch, which is fair enough – comes with the territory. The trick with opinions though, is knowing when to shut up and listen to those of others. I could probably stand to follow that particular advice a lot more often :). If you can master that trick you're guaranteed to learn something. Even if all you learn is how to keep your opinion to yourself, once in a while, that's still a skill worth having.

Read the full post

When A ‘Mount Fuji’ Question Is Not Really A ‘Mount Fuji’ Question (Are You As Smart As You Think You Are)

June 2, 2010 By 90 Comments

Mount FujiMany people hate 'Mount Fuji' style interview questions. Questions such as:

"How many barbers are there in your home town?"

or

"How would you move Mount Fuji?"

That last one being the most well known of these types of questions and the one from which the rest get their name. These questions were initially popularized by Microsoft, but many of the most well-known tech companies have used them since. They have recently fallen a bit out of favour, but you're still likely to come across some if you do few tech interviews here and there.

There is a good reason why many people don't like these types of questions. Most of the time, they don't really have a good answer. The question is designed to put a person under pressure (when they can't immediately see a way to tackle the problem) and see how they handle it, as well as see if they can come up with a creative solution on the spot. Some developers tend to enjoy that kind of challenge, others seem to loath it which is why opinions about these questions are highly polarised. While I personally don't think these questions are the be-all-end-all, I do believe they have their value, but that is not what I want to talk about.

Read the full post

On Personal Skills And How Even Riding A Bike Is Not Like Riding A Bike

May 31, 2010 By 21 Comments

RidingIt seems that in this industry we're operating under the false assumption that once we learn (or hear about) a skill, it is with us for good. You only have to look at a typical developer's resume for an example – it is truly buzzword central. I mean c'mon, just what exactly do you remember about XQuery or iBATIS at this point? I sometimes look at some of my own resumes I have used in the past and can't help being impressed – if only I were really that awesome :). If you're honest with yourself you can quickly classify all those skills into 3 categories:

  1. Stuff you have used recently and know pretty well
  2. Stuff you used to know pretty well, but haven't used for ages
  3. Stuff you've had some exposure to, but don't really remember much about

Only the skills and tech that end up in the first group truly deserve a place in that buzzword list. The problem is that we don't tend to prune skills/tech off our resumes all that often. More stuff makes us sound more impressive – who wants to mess with that. This would actually have been ok if we made a conscious decision to include neglected and forgotten skills for marketing purposes, but the sad thing is the vast majority of developers/people truly believe that all those skills deserve a place.

Read the full post

How To Be A Real Elite Programmer And Make Sure Everybody Knows It

May 30, 2010 By 55 Comments

Elite

  1. Real elite programmers can't have distractions like kids and spouses in their life. Cut your family out of your life to maximize coding time. While you're there cut your friends out as well to maximize coding time even more.
  2. Real elite programmers don't have hobbies that aren't coding. If you still engage in activities that don't involve a computer, this will have to change. If you find yourself burning out, just man-up and push through it.
  3. Real elite programmers do their best work at night. Sleep is for wussies.
  4. Real elite programmers hate their day job. Otherwise they would have nothing to complain about to other real elite programmers.
  5. Real elite programmers eat pizza and drink Dr. Pepper. No other food is allowed, if you have fruit and vegetables in the house, they will have to go – stick to the diet of champions.
  6. Real elite programmers don't read about programming, they DO the programming. Don't bother with books, just keep programming. Remember, you know best, those book-writing wimps are just a bunch of noobs, they should have been coding instead of writing, you're way better than that.
Read the full post