GitHub as a recruitment filter

When I was at QCon San Francisco, I heard a talk about recruiting software engineers, and one of the points of the speaker, was that you should check out the GitHub profile of the candidates. This is something I found a little worrisome, not only because I don't have an (active) GitHub profile, but also because it seemed to me that this would lead you to exclude a number of good candidates.

I am all for open source, but I don't spend time on them, since I have enough work to do on work and non-programming related projects for me not wanting to add more to it. Does this make me a bad programmer? Perhaps. But probably not. Currently I am mostly doing business analytics (i.e. trying to help define the needs of the customer), but when I am on a project as a programmer, I tend to average more than a full days work each day - I could spend the overtime on open source projects, but I frankly don't see how this is a better use of my time, in the eyes of optential future employers.

There are also numerous other reasons why using GitHub profile as a recruitment filter is a bad idea, and there are two great blogposts that explains this:

Ashe Dryden: The Ethics of Unpaid Labor and the OSS Community
James Coglan: Why GitHub is not your CV

They should be read in the posted order, as Coglan's post is an expansion on Dryden's post.

We got to do better - diversity at conferences

I have just returned home from San Francisco, where I and nine of my colleagues, spent 3 days at the QCon San Francisco conference.

As often happens at these conferences, the gender diversity was not impressive - according to the speakers page, there were 7 women out of 110 speakers, and none of them were keynote speakers.

This is, to put it mildly, abyssal, and we got to do better.

On the last day of the conference, they displayed a slide of all the track hosts in the conference. When I saw it, I immediately thought to myself (and of course tweeted): I think I now understand the gender imbalance at the conference.

 

 

 

At conferences like QCon SF, track hosts are heavily involved in selecting the speakers, and they tend to look at their own network when doing so. Unless you've done an explicit effort towards that not happening, your network tends to look a lot like yourself, and when people like the track hosts use their network to get speakers, the speakers end up looking like themselves.

 



Not all track hosts are like that of course - one of the track hosts in that picture is Jez Humble, who is very much involved in fixing the gender imbalance (2 of his 5 track speakers were women), and who has written a great blogpost about this: How To Create A More Diverse Tech Conference. That blogpost should be required reading for all conference organizers, and certainly wasn't read (or at least not followed) by the QCon SF organizers.

If the organizers don't want to follow the guidelines laid out by Jez Humble, then they could consider something as simple as trying to find a couple of female track hosts. That alone should help in the gender imbalance. Or perhaps just ask the vendors if they could use female speakers, rather than male speakers, on the vendors track, if possible - I know that at least one of the vendors had a great female speaker sitting in the booth on the first day, and she could easily have spoken on either the vendor track or in one of the other tracks.

Before anyone goes on about conference organizers having to choose the greatest speakers they can get hold of, I will say that that has been addressed by Jez Humble in his blogpost, and that at QCon SF, the level of the speakers was generally sub-par compared to similar conferences I've been to the last couple of years (which includes both QCon London and QCon New York), so looking towards diversity probably would have increased the quality.

Agile won't cut it alone

During the first day of GOTO Aarhus conference there was a track called When the Agile Manifesto isn't Enough, where a bunch of speakers talked about stuff related to agile, but not converted by the Agile Manifesto.

I didn't see the whole track, but I did saw 2 of the first 3 talks (I left during the second talk), and enjoyed Dan North's Agile doesn't scale, and what you can do about it, and Russell Miles' Without Simplicity there's just no Agility, both of which addressed why agile projects tend to fail at being agile over time, but in different ways. I thought I'd write a little about the first of those talks.

Dan North's talk was on how agile doesn't scale well (as the title indicates), and he started out by trying to explain what he meant by "scale", and basically he means working on bigger problems in bigger programmes. Big problems in individual projects are well handled by agile, but when you have many projects working together on bigger problems, agile doesn't help.

Simply put, the domain of agile is within the projects, but when we're talking multiple projects, we need to think about delivery assurance and governance (which put together is portfolio management).

Delivery assurance covers areas like cross-team concerns, product trade-offs, and technical trade-offs. Or put differently, covers the coordination between teams and the decisions which should involve several, if not all, teams (such as choosing the same database or even programming platform).

Governance covers areas such as organisational concerns, investment trade-offs, and portfolio balancing. In other words, this is where there requirements of the organization, as a whole, is evaluated, and decisions relating to which projects are prioritized are made.

Agile has no opinion on delivery assurance or governance, and this is why it doesn't scale. This doesn't mean that we should stop using agile, it just means that we have to recognize that we need to do something on top of agile. So agile should be done in the projects, while portfolio management should happen between/across projects.

What I've written above, is, of course, a rather simplified version of the nearly hour-long talk Dan North gave, but I think those are the important points.

Dan North's talk covered an area which I've been thinking of recently, since I've come across the problems with agile across multiple projects in the past, and I think he is absolutely spot on. I think agile is a great idea, and something which you would be stupid not to use in one form or another in your project, but I also think that the allure of agile has been harmful, since it has made a lot of people think that they could reject all classical project management, including such things as portfolio management. This is probably one of the major reasons why projects still fail when doing agile.

One of the reasons I think Microsoft is currently good at creating programming languages and tools that support them, is that they put a lot of effort into portfolio management. The different language teams coordinate on what they want to add to the languages, and they make sure that the tools (e.g. Visual Studio) are up to date, so they support the new features in meaningful ways. It obviously also helps that they have some great people involved in this, but without the coordination, the best people in the world would not be able to make something that anyone could use.

So, to sum it up, agile is useful within projects, but we must not forget that there often is a need for coordinating, or even prioritizing, between projects, and agile is inadequate for that purpose. Instead one should turn to classic project or even organizational management tasks covered by portfolio management.

Impressions from the 1st day of GOTO Aarhus

This is just a short blogpost with my impressions of the 1st day at GOTO Aarhus 2013 - longer, more detailed blogposts will follow, based on specific talks.

My schedule for the 1st day of the conference was:

1) Introductions to the tracks - this was basically just the track hosts that introduced their tracks. There were a lot of great speakers and several interesting tracks, but the track hosts should practice giving short introductions to their tracks and the speakers on it.

2) Something completely different: an opera singer showed up on stage and gave a short performance. I haven't seen this before at a conference, but it was a pleasant surprise.

3) Keynote speech: There and Back Again - Software Security in the 21st Century by Brian Chess.
I plan on writing a separate blogpost about this talk, but I found it interesting and it contained som important reminders to everybody.

4) Dan North: Why Agile doesn't scale, and what you can do about it (when the agile manifesto isn't enough track)
It was an intentionally provokative title, but the main message was that agile is not focused on scale, and we need to look at other things in order to get agile to work on large scale projects.
I will write a separate blogpost about some of the talks on this track.

5) Mads Troels Hansen: Do's and don'ts for Distributed Scrum (when the agile manifesto isn't enough track)
This talk was about a number of patterns for doing distrubuted scrum succesfully. It would have been a great series of blogposts, but as a talk it was lacking the overarching narrative, which made it interesting. I left this talk early.

6) Russell Miles: Without Simplicity, there's just no Agility (when the agile manifesto isn't enough track)
The theme of this talk fitted pretty well with the theme of Dan North's talk, and will be covered in the same blog post.

7) Ola Bini: Working on cancer (Architechtures track)
Ola Bini talked about a project he had done together with 3 other Thoughtworks developers, where they had created a system which could help ensuring that people get better treatments for their cancers.
The first part of the talk was a (brief) introduction to the microbiology behind cancers, and even if it was simplified, it was a rather good, short introduction. The rest of the talk was about the solution they built, and the technologies used. It quickly ended up as a long list of technologies, but there was not enough time for him to get into details or even show code, which is a pity, and would have made the talk more interesting for a lot of the people in the room.

8) Work break. There wasn't any talk that I really wanted to see, so I spent the time doing some work that I needed to do.

9) Keynote speech: Computing like the brain: the path to machine learning by Jeff Hawkins
Jeff Hawkins talked about his work on machine learning. It was an interesting talk, but I had some serious problems with Jeff Hawkins using the termology of computer science to describe the brain, as it erases the very real differences between the brain and machines. I am also doubtful about whether he is really as close to creating machine learning as he thinks he is (for many of the same reasons as described here)
One thing I really did like about his talk, was his endnote that we are never going to upload our brains into computers, and anyone who thought so, clearly didn't understand neuroscience.

10) Exhibitor reception and conference party
I am a big proponent of using conferences to network, and the exhibitor reception and the following conference party are definitely great places to do that. I got to talk with a lot of interesting people - some I knew already, but a lot I didn't know.

A must read blogpost

I was linked to this great blogpost "To my daughter's high school programming teacher, where a tech writer writes an open letter to her daughter's teacher, explaining how that teacher failed his duty to help foster an environment that welcomes young talented people, regardless of their gender.

The comments under the blogpost are unfortunately predictable - men denying the problem etc., so don't read them, unless you want to get annoyed.

Why you should allow your employees to go to conferences

A few days ago, I was talking with a friend, who I used to study together with. We were talking about GOTO Aarhus, and whether he thought he would be going this year.

He told me that it was unlikely, as the company he works for, has a limited training budget, which also covers conferences.

While I can understand why some companies might have to be careful about costs, it seems to me that this is short-term thinking, which will cost them in the long run.

In my experience, and in the experience of other people I have talked with about this subject, the people who ask for conferences, usually belongs to a group of people that the company would like to keep in their organization. This doesn't mean that the company wants to get rid of the people who don't ask for conferences. Rather, it means that innovation within the organization tends to happen from people who likes to seek inspiration everywhere (and what are conferences other than a giant source of inspiration?).

Conferences are, in other words, a great way to introduce new ideas and solutions into the organization, as long as someone who wants to go there, get to go. For the people going there, conferences are often a vital part of getting new ideas, since they will spending days together with like minded people, who might offer new insights. I think most of us have tried to hear someone say something, and suddenly have your brain go "click", realizing that you've dealt with a problem the wrong way. A conference offers you thousands of opportunities to get such "click" moments.

People like my friend, comes back from a conference with fresh new ideas, and new ways at looking at old problems, perhaps allowing for a novel new solution to a problem the organization has had for a long time.

So, all in all, my suggestion to companies would be, that if you have a employee who wants to go to a conference, think twice before saying no.

On the other hand, don't force employees to go. It is quite fine to suggest to someone that they go, but if they don't think that it's worth the time, it is pretty much a self-fulfilling prophecy, and a waste of money.

At the end of the post, I should probably also mention the fact that some people, myself included, consider conferences so essential that it is something we take into consideration in relationship to employment (my current employer, NineConsult, also considers conferences essential, so in that sense we're a good match).

This year's GOTO Aarhus conference

It looks like I might be going to the GOTO Aarhus conference again this year as a blogger, like I did last year. It is not completely decided yet, but there is a high likelihood.

If I am going, this would be 4th time I'm going to this particular conference, which is favorite conference (perhaps together with QCon London). Not that I have been to that many different conferences - I go to more than many people in IT, but I've only been to just over a handful of different conferences.

So, what am I looking forward to?

I haven't taken a full in depth look at the schedule yet, but glancing at the speakers list, I see several great speakers among them. People I'd hate to miss out of a general principle, would be Dan North, Jez Humble, Dave Thomas, and Ola Bini. Though I am considering Dan North, as I think I might have heard that talk before (I will have to hear the introduction to the talk).

I also noticed Kevlin Henney among the speakers, but unfortunately he is only there as a trainer for the training days. If you ever get the chance to hear him speak, I highly recommend it - he is an fantastic entertainer and teacher rolled into one.

Subject wise, I tend to avoid technology specific talks, and rather go for talks that can apply broadly across technologies. This means I have a tendency to go for talks related to processes, people, and principles across technologies (e.g. architecture or big data).

This year I think I will be spending my time mostly on the following tracks:
Monday: Architecture and "When the Agile Manifesto isn't enough"
Tuesday: "Lean IT Enterprise" - this is only half the day, so I need to find other stuff to fill it out.
Wednesday: "DevOps In Depth" and Career. Perhaps "Data in Reality", but there is so little information about the track right now, that I cannot really tell what the talks will be about.

The schedule can be found here

Another thing I am going to spend my time on at GOTO Aarhus is networking. I think it is incredible important to take advantage of the opportunity such a conference gives for meeting your peers and the masters of the field. And GOTO Aarhus is especially good at facilitating this, throughout the conference. I have been to other conferences, even other GOTO conferences, where this important aspect was lacking, but somehow GOTO Aarhus manages - especially during the conference party, where you have the chance to meet not only the other participants, but also the speakers.

So, if you're going to the conference, I highly recommend not missing out on the party. Who knows, you might end up having beer with someone like Michael Nygard or Jim Webber, both of which I have drunk beer with at conference parties. OK, probably not those two, as neither of them appear on the speaker list, but you get my point.

One should of course not forget to network with the vendors. People have a tendency to think that the vendors are just someone you should visit to get free stuff or win something, but this is a mistake. Often the people standing at the vendor booths are passionate about the company or product they represent, and they are often highly knowledgeable about the things they talk about. Remember, the vendors often send their best representatives to the conference in order to convince people.