My Dad's on Twitter. You should be too.

Yesterday I received an email entitled "rkharcher is now following you on Twitter." That's my Dad. He's a pretty tech savvy guy but I was still pleasantly surprised seeing as how I had only mentioned the prospect of him joining half-jokingly the other week.

I've been wittering on about Twitter to various people who'll tolerate it for the last year or so. For those who've not experienced it, it's hard to grasp the potential utility of it. The media tends to portray it solely as a source of information about celebrity self-indulgence. *Why* on earth would you want to pointlessly inform dozen (or hundreds or even more) people of your mundane everyday actions or thoughts? Even more bizarre perhaps, *why* would you want to be informed of the same nonsense from others?

Well, here's the thing. Twitter is more a platform that you can use as you wish rather than an enforced stream of pointless drivel. It can be used in some very worthwhile ways. I'm going to share what I've learned about it in the last year. Maybe you'll be convinced to try it, maybe you won't. My honest opinion is you are unlikely to "get it" from just reading what I have to say here. You need to give it a go for a couple of weeks if I pique your interest. For me, it's become as essential as email and IM. I think the reason I most like Twitter though is because of the accessibility it gives me to people. For example, to see what someone like Mike Cohn (@mikewcohn) is writing about I can go visit his blog. But by following him on Twitter, I can see what he's reading too.

Career & Industry Information
This was what really got me hooked. Initially I signed up for Twitter because curiosity had got the better of me. But this happened to coincide with our adoption of agile software development. It didn't take long for me to find a very healthy and vibrant community of people involved in agile in one way or another. This ranged from the everyday person like myself, to industry thought leaders like Kent Beck (@KentBeck), Mike Cohn (@mikewcohn), Lisa Crispin (@lisacrispin), Jim Highsmith (@jimhighsmith), Ron Jeffries (@RonJeffries) and many more (apologies to those omitted, nothing personal).

Beyond the agile and Scrum world, I also starting finding and adding interesting folks doing software development in general.

Twitter became my top source of information and inspiration as I ramped up my knowledge of agile. The great thing here -- in contrast to simple googling "agile" or "scrum" -- was that I had this curated list of recommended links to articles, books etc. all flowing in for my perusal. The number of great discoveries made this way was huge.

Breaking News, and News in General
The second substantial use of Twitter for me is news. A lot of people will tell you it's good for breaking news, and that's true. But I've also found it to be good for news in general. With all the major international, nation and local newsources now on Twitter it provides a superb feed of highly scan-able headlines. One of the truly great things here is that the enforced brevity of Twitter (140 characters per tweet, maximum) kills the clutter associated with email or RSS based news updates. There's no clutter, no verbosity, no fonts...just clean simple headlines and you can quickly click through to stories of interest. Shakespeare had it right when he said "Brevity is the soul of (t)wit."

Responsiveness. Or Not.
One characteristic of Twitter which I only really appreciated fairly recently is how it occupies and halfway house between IM and email. With IM there's an interactive expectation. It's not much good unless the person you are IMing is at their computer too. Although email can mimic this to some extent it's a more verbose medium. Twitter sits somewhere in between. There's no expectation of an immediate, interactive response, although that can happen and it works great. The short messages can keep a conversation flowing. But equally tweets can go un-responded to for some time. It can mask timezones very well.

Controlling the Flood
One potential problem with Twitter is information overload. Luckily there are several mechanisms for handling this.

The first thing is to stop looking at Twitter like email. Based upon the people you are following, messages from them will show up in your "tweet stream". Unlike email, they don't sit there waiting to be read. If you don't look at it for a day, things just pass you by. This is nice because you can go switch off when you want and not worry about "missing" anything. You can be pretty sure that anything truly earth shattering will show up from more than one source over time anyway.

The second thing is to take advantage of "asymmetrical following." This is perhaps vastly more useful to celebrities than the likes of you and I, but it's still a key difference between Twitter and Facebook or Linked In. Just because someone chooses to "follow" you, doesn't mean you have to follow them. You only get to see the tweets of people you have elected to follow, and you can un-follow people anytime you like.

Lastly, a fairly recent new feature called lists can help sort the important stuff from the noise. The way this works is you can create any number of lists of your own, and add people you follow to one (or more) lists. Then you can just check in on certain lists. For example, I have lists for "agile" and "colleagues" and "news" etc.

The Social Aspect
The final aspect of Twitter I want to mention is the social element. It's somehow different (I think) than Facebook et al. There's an exploratory, discovery of new and interesting people to it. I've reconnected with people I haven't talked to in years despite having their email addresses or even IM accounts. Somehow Twitter has enabled conversations that they did not. I think a lot of that may be to do with the characteristics I described under "Responsiveness. Or Not." above. And Twitter is somehow humanizing for a technology. Catching a glimpse of friends and colleagues in a quite candid way does that. My colleagues now know what a total dork I am (if there was any room for doubt previously...)

Curiosity Piqued?
If you're interested in giving it a try, here are my pro-tips for getting started.

• Put a Twitter app on your smartphone. The iPhone is the best represented here. I've no experience with other smart phones but they all have something you can try. No smartphone? You can use Twitter over SMS. Looks like a pretty grim (and potentially expensive) proposition to me, but the option is there.
• Get a Twitter application for your desktop. On Windows? Try Tweetdeck or, my current personal favorite, Seesmic for Windows. Got a Mac? Good choice ;-) I Like Echofon but there are many others. The Mac has the best clients.
• Follow @Twitter_Tips. As the name suggests, they tweet out tips, often links to articles that are particularly helpful for those new to Twitter.
• If (when) you start getting emails indicating somebody new is following you take a look at their follower/following/tweet stats. THere is a growing spam problem on twitter. Bogus accounts will follow you (and hundreds of others too) hoping that naive people will follow them back. Once you're following someone you see what they tweet and they can even send you direct, private messages. Spammers of course will fill your tweetstream with spam... The key hallmark of a spam account is they have very few followers, have tweeted hardly anything and are following hundreds or thousands of people.
• Consider following me (@9200feet) ;-)
  

Feeding Body and Mind

Software development is an ever changing field. Some might even say volatile. Languages, tools, methodologies, paradigms, philosophies, manifestos. Structured programming. Functional programming. OO programming. Agile principles. Extreme Programming. TDD. Continuous integration. Acceptance testing. Automated testing. SOA. Pascal. ADA. Lisp. C. C++. Java. Python. PHP. C#. Ruby. Grails. Haskell. Scala. Cloud based computing and more...

How can one keep on top of this?

Well one very effective way the engineers have applied over the last few months is a regular "lunch & learn" session. The idea of something like this has tended to go in and out of vogue for years in Perceptive. There's always been plenty of topics that would be interesting: "Talk people through the latest work you've done," or "Show us what you've learned about the new technology your last project employed."

The big barrier of course is the substantial investment of time required to deliver a coherent and valuable session. And then to do that regularly, even monthly, even if the task rotates...well it just seemed really hard.

A few months back though, we hit on the solution. Google (amongst other sources) post a huge number of fascinating presentations and talks on a multitude of topics. And they're delivered typically but top thought leaders in the software development field. And they're free too...they're just a click or two away on Youtube.com or similar.

So we started running lunch & learn sessions. We'd start with watching a video that someone had picked out as interesting. Pizza would arrive. And when the presentation was done we'd sit and chat about it. We found it to be a really easy way to get exposed to new ideas and technologies. It required very little preparation effort which has allowed us to keep this up regularly, and in fact there's so much value coming out of this we're increasing our frequency from once to twice a month.

What's the point of points?

One of the earliest changes we tried out that got the agile snowball rolling was estimating using points rather than hours or days (or weeks...)

Estimating in points though is a weird thing. It doesn't seem to make a lot of sense at first. It's really quite hard to explain and has a rather abstract quality about it. Look at some of the things you hear or read when you go looking for an explanation:

"Points are a measure of effort more than duration"

"Points are relative, not absolute"

"Points aren't a measure of time, don't think of them in hours"

"Whatever you do, don't set up a conversion rate like 8 hours = 1 point"

And this "estimating in points" idea is meant to help?

When I started to read about points and their advertised benefits I sort of thought I got it. I wasn't certain, but I found myself ready to try them out and take a leap of faith.

Initially I was skeptical. After all, it's pretty easy to pick away at some of this stuff and claim that it's just another pointless (pun intended) change as one sees so often in software development. (Software development is, after all, partly a fashion industry.)

Take the claim that points are relative. Well so can hours be. For instance, if "feature X" took 100 hours and is estimated by me as approximately twice as hard as "feature Y" then, relatively speaking "feature Y" is gonna come out at 50 hours. So big deal.

However, here's the thing. Points alone are not that special. They do address some of the issues of estimation such as it tending to be fractal, i.e. at some point the more detail you break down your work into the more complexity you unveil and less less accurate your estimates turn out. But by themselves they are not going to solve any major problems.

Points + team based estimation + tracking team velocity on the other hand is very powerful.

Together these concepts work like the legs on a three-legged stool: it'll fall over if any one of them is missing, but together it's rock solid.

So how do these three things work in concert? Easy...

• Points really do provide a nice simple unit that discourages over-analyzing things and are very easy to to perform math on (twice as hard, half as hard etc.) They're very quick so there's no need for tedious marathon estimation sessions.
• Team based estimation encourages full understanding and participation by the whole team. It also limits the likelihood of the most experienced people providing unreasonably low estimates that other team members have to abide by. It also equalizes the understanding of effort between software and QA engineers.
• Finally velocity, that is the measure of total points of work completed per iteration, provides a team with an easily understandable measure of their capacity, i.e. how much work they can get through in an iteration. This is incredibly useful because it allows a team to guard against being asked to complete an unreasonable amount of work in a certain period of time. Moreover, with a list of features estimated in points one can now easily predict how many sprints are likely needed to get them all done. Much easier than estimating in hours...

Those three points (pun intended, again) are pretty good for me already. But there's more. We now have a much more customer friendly language to speak in. It makes for easier negotiations. It turns the conversation away from "can you just get it all done by June" to more of a dialog where they understand capacity and can make comprises over features to hit their preferred deadline.

And that, for me, is the point of points.

"Checking in" on the Coding Exercise

Earlier this year I wrote about how I was setting out to use a code exercise as part of the interview process for a software engineering position. Six weeks or so later, I haven't yet snagged my ideal candidate, but I sure as heck am sold on using this approach. I think I can safely say I'm never going to recruit without using an exercise like this in the future.

Here are my seven "lessons learned" from this approach to evaluating candidates. I had previously learned all of these lessons anyway, but it never hurts to have a refresher course...


1. Some people can "talk the talk," but not "walk the walk"

I'm looking to hire a "Principal Engineer" -- that may have some scope for interpretation when it comes to a precise meaning, but I'm fairly sure that by anybody's reasonable definition it includes the ability to write decent code. Quite frankly, to me, it clearly implies a software engineer at the top of their game. That's not to suggest that I didn't receive candidates that *sounded* like they were awesome...

But there was the thing...there is a surprisingly large number of people out there looking for a job at this level who aren't very good engineers. Some of these I kind of guessed might not be so hot from the initial phone screen. They fell into my "underwhelming" category, aka "didn't blow me away but I've no real concrete reason not to let them have a crack at the code exercise." But the other contingent here were those that phone screened like pros, that left me thinking "that's the one!" after I got off the phone with them. Sadly, quite a number of these turned in surprisingly mediocre work. (At this point may I offer my apologies to any former candidate reading this if I hurt your feelings. Sorry about that.) One person offered a solution that reminded me of when I first used to write code...around age 11. 'Nuff said.

Lesson learned: don't get carried away just because someone's a smooth talker and sounds impressive on the phone.


2. Some people can't read

I thought the exercise was pretty clearly worded. It wasn't too long or complex or ambiguous. I know some elements were not super-specific, but that was purposeful -- requirements often aren't clear in the business world anyway. The key aspects though were there. Or so I thought.

Moreover, I'm not too sure how you decide to undertake an exercise like this when looking for a job and don't pay really close attention to what you're being asked for. Maybe not doing so exposes that you're not a detail oriented person. That's certainly how my interview panel and I interpreted things when somebody sent us a "solution" that was completely different to what was required. As a reminder, the exercise requires an algorithmic exploration of a "maze" kind of environment. What we received was an interactive text adventure game. Which was cute and all, and it was clear that quite some effort had been put into it...to the extent that my initial reaction was that I wanted to cut the guy some slack. I was interested in having him come in for a face-to-face interview and finding out what happened. However, as my colleagues on the interview panel pointed out, submitting such a significantly wrong solution really did not bode well. If someone can't pay enough attention to get things right for a job interview, what hope is there gonna be when they have their feet under the desk?

Lesson learned: if it's wrong, it's wrong. Just because someone appears to have put a lot of effort into something doesn't mean they get away with producing completely the wrong deliverable.


3. Some people get stuck off in the weeds

This third point, moreso than any of the others, is likely to give prospective candidates some good advice. Lucky you huh?

I've seen this trait in engineers before, so it's perhaps not surprising to see it rear it's head amongst the candidates. I still don't quite understand it myself... Given that you don't want to spend forever on something like this that *might* help you land a new job, why oh why would you spend your time on things that are of low or no importance? At it's core the exercise requires you to parse an XML document, read in a text file and figure out some kind of algorithm to make your way through a maze looking for objects. Why then would you spend time on patently unimportant aspects or worry about odd or implausible corner cases? Some people think they're being "thorough" and there are times when that is appropriate. But one has to keep things in perspective...

Lesson learned: watch out for this behavior in candidates...because in someone on your actual team this can lead to a lot of waste from "over-engineering" to running around blind alleys (or mazes ;-).


4. Some people have surprisingly little pride in their work

Maybe some of what I interpret as lack of pride is more down to chaotic work practices, I'm not sure. Nonetheless, would you submit to a potential future employer code that was a mess as an example of your work? I'm talking about large swathes of code commented out, duplicate files, irrelevant files, stuff you've tried and abandoned etc. I wouldn't for sure...not exactly going to create a good first impression. Now I know I say to people "I'm not looking for a perfect solution" -- but I still would expect a certain degree of professionalism in what I do receive...

Lesson learned: another characteristic to watch out for in candidates. If this is what they show at an interview then goodness only knows what kind of stuff is going to come up when they're comfortably settled in their job.


5. Some people are incredibly slow

Perhaps this one shouldn't shock me. It's been known for decades that the best programmers are often an order of magnitude more productive than the worst.

Lesson learned: make sure you check how long someone spends on an exercise if you attempt something like this. Either that or provide clear instructions that they should only spend X amount of time (and even then check...) It's very telling.


6. Some people will give you whatever answer they think you want to hear

A gentlemen who shall remain nameless did a 180 on test-driven design during his interview because he thought we wanted to hear that this was the "One True Way" to approach software development. At this level of the game I'm expecting you to have well established and thoughtfully considered views on how to develop software along with an open mind that recognizes there is always room for learning something new. What I don't expect is you to roll over at the first challenge and alter your world view.

Lesson learned: yet another dubious behavior to guard against, at least in a senior position.


7. some people are awesome

I know it's been some rather grim and to some extent heavily laced with sarcasm and cheap shots at other peoples expense up to this point. But there is some good stuff too. There are some awesome people out there. I know this, I've interviewed them. Sadly they've not necessarily been the right fit or they've ended up going to other employers. However, they are out there. To at least see them during the recruitment process is a welcome reminder of their existence and of the fact that you've got to sort the wheat from the chaff if you ever want to bake some kick-ass bread.


And finally...
A few other interesting things that emerged. Out of many candidates so far only one has declined to undertake the coding exercise. Almost everyone has said they had a great deal of fun doing it, and a couple of said they're impressed that we take finding good candidates so seriously. A shocking number of people talk about TDD in their phone screen but then don't offer a solution with any unit tests ("well I didn't actually have time for that...")

Oh, and it's interesting how many people opt for the "stumbling drunk" algorithm whereby one wanders randomly around the maze looking for objects...

Coding Exercises for Software Engineering Interviews

I've read about it. Talked about it. All with a positive "it should be done" spin to it. But despite that, I've never actually done it. It being to actually have interview candidates for software engineering jobs write code. Now I'm going to do it.

What really pushed me to action was being involved in a recent round of interviews for a Scrum Master. For this, we provided the candidates with a number of scenarios prior to the interview. These might be something like a product backlog of stories, information about some teams, velocity etc. and they then had to come in and present to the interview panel what they made of it. Certain challenges were inherent in the scenarios such as story sizes larger than velocity, stories that didn't fit neatly etc.

I was part of the panel interviewing some half dozen candidates, and I found this approach very insightful. Besides the interest of just seeing who could put together a small slide stack and talk coherently about it, it gave a much firmer foundation for asking questions about. Out were the theoretical "in such and such situation how would you..?" -- in was "I noticed that in sprint 1 you didn't get in all the top priority stories, can tell us about that decision?"

So, fired up from the Scrum Master interviews, I decided that I would come up with something to use for subsequent software engineering recruitment we would do.

I started off looking at an example from a colleague who had interviewed with Thoughtworks in the past. There were a choice of three problems a candidate could choose. They were very much your run-of-the-mill "coding challenge" though. I decided to think a bit deeper about what I was trying to accomplish.

My initial thoughts were focused on setting an exercise that would hopefully steer people to:

• Demonstrate competency with key Java APIs and features such as:
• Collections
• Generics
• IO
• XML
  Parsing
• Annotations?
  

• Show us that they knew a design pattern or two
• Wrote code that had suitable comments, Javadocs
• Used a consistent code style
• Utilized unit tests
• Employed a build tool beyond their IDE

I circulated these ideas amongst my esteemed colleagues, including Jim and Rajiv to get some feedback. Rajiv offered an interesting idea which I think we might use in conjunction with a coding exercise: how about presenting people with some fragments of code and asking them to spot errors and code smells in them (e.g. not closing connections in a finally block etc.) I like this idea but was still really keen to actually see somebody's work, some actual code they'd written. As I'm sure someone else has said somewhere else, "you wouldn't hire a chef without having him cook you a meal." He might be able to talk about the culinary arts in the most poetic and comprehensive way. But if he can't cook, he ain't worth squat.

In addition to Rajiv's idea, he and Jim both helped shape my thoughts on what kind of things we wanted the exercise to focus on. Key to this was something that would have the candidate demonstrate problem solving. It had to be non-trivial, non-textbook with a variety of approaches possible. Though also we couldn't ask they work on something too demanding and time consuming...

Ultimately, here is the exercise I came up with. I'll be using it soon because I have just opened up a position for a Principal Engineer in Billerica, MA. I'm very excited to see how this works out. If you have any feedback or constructive criticism please leave comments below. Thanks.

Code Exercise: A-Maze-ingly Retro Route Puzzle

This code exercise is (very loosely) based on some of the ideas in old school text adventure games. I enjoyed these so much as a kid I even learned how to write them on my old Commodore Vic 20. Thus began my descent into programming geekery. Ah, happy days.

Moving on... in this exercise you are supplied with two files. The first is an XML document (with inline DTD) that describes an adventure game map. It will look something like this:

<map>
    <room id="1" name="Hallway" north="2" />
    <room id="2" name="Dining Room" south="1" west="3" east="4"/>
    <room id="3" name="Kitchen" east="2">
        <object name="Knife"/>
    </room>
    <room id="4" name="Sun Room" west="2">
        <object name="Potted Plant"/>
    </room>
</map>

As you can see, a room may or may not permit travel in one of the four cardinal directions and may or may not contain "objects". The second file is a plain text file where the first line indicates the ID of the room the player starts in, and each subsequent line lists the name of an object they must collect. This file will look something like this:

2
Potted Plant
Knife

The objective is to write a program that will:

• Parse the XML and create a model of the map
• Read the plain text file, noting which room to start in and which items must be collected
• Output a valid route one could take to collect all the items specified in the text file
  

Given the above example the following is (one of the potentially) correct outputs:

ID  Room          Object collected
----------------------------------
1   Hallway       None
2   Dining Room   None
3   Kitchen       Knife
2   Dining Room   None
4   Sun Room      Potted Plant

There are going to be questions people have as they seek to clarify the above requirements, e.g. "Does my output have to be exactly like the example? Do I have to find the optimal route or simple a valid route?" I'm unlikely to provide any further clarification, but rather ask people to make and state their assumptions as part of their work.