Interns: New Ideas, New Faces, New Energy

This is a reply to a post on the London Java Community Forum, I thought it was worth posting here, since it is indeed intern season and I have a bit of knowledge (and fond memories) of having interns myself.

Hi Barry,

Re: Interns, this has turned into a long response: I realise that it's something I'm quite passionate about.

I used to run the interns programme at Xerox Research Centre Europe in Cambridge. During the course of 4 years, I had 4 interns and organised maybe half a dozen interns for other members of staff. I found it to be terrifically useful way of investigating new ideas and doing solid pieces of development that you know need doing but can't seem to get around to (e.g. developing tools that will help you do your main job better - trying out new ideas). Put simply, interns don't have to turn up to all the meetings that you have to turn up, they aren't there long enough. They can be left alone to focus on doing just one thing and so can progress much quicker. They also have youthful enthusiasm and energy - they don't know any better, this can be a good way of injecting some life into a jaded team (one intern that someone else took on at Xerox organised the most amazing candlelit punt from Cambridge to Grantchester - it was a great team-building exercise, far better than go-carting or paintballing).

We also used internships at Xerox as an opportunity to give more junior members of the lab some experience of management. They'll be rubbish at it at first, but it's a very good, and revealing "trainer wheels" experience.

I would also say that this is an opportunity to try out hiring someone who doesn't have a cookie cutter CV and just see how it works out. My advice would be to hire the person with the CV that jumps out at you, irregardless of academic institution/qualifications. Hire a Medieval Historian or a Philosophy student (I'm maybe biased because this is my background). I do know other people in the industry who say that Philosophers make the best programmers. The best intern that I had had a degree in fine art and no technological experience whatsoever, the portfolio she sent me literally made me wince when I looked at it (pictures of decaying meat), but she produced three concept video in as many months which ended being shown at "C-Level" meetings and the ideas in them being used as part of merger and acquisition discussions.

Interns are also an excellent opportunity to try out pair programming (http://www.agile-lab.co.uk/2008/09/loneliness-of-self-taught-programmer.html) with someone who's none threatening and ready to learn.

The only BAD THING I can think of in relation to interns is if you are going to treat them as cheap/free labour. They're not trained, they don't know what you do if you think you can bring them in to do the dull bits of your job without you having to put in any effort, you'll be disappointed.

Hire the brightest one you can find and have fun.

If you're looking to apply for an internship - yes, put down your academic qualifications, but understand, especially in the current climate, that isn't going to make you stand out. I looked at a *lot* of CV's from Cambridge University Computer Scientists, I hired a woman from Winchester who sent me pictures of meat. Put down the strangest achievement that you have (that you're proud of) and label it. If you don't have a weird experience like this, go have one right now.

Regards,

Mark Stringer.

P.S. Just remembered that I had another fabulous intern when I was at Sussex. She was much more talented than me and instantly capable of implement things that I was just kind of dreaming about doing - and there's no way I could have ever got her input at any later stage in her career, she was destined for stardom. Handled properly, interns are a terrific way of getting a lot done in a really short time, good for you, good for them.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

The Meaning of Common Sense

"We are asleep. Our life is like a dream, but in our better hours we wake up just enough to realise that we are dreaming" - Ludwig Wittgenstein.

My brain has been readjusting only slowly from the tasks of navigating an SUV around Athens at high speed (if you drove slowly they would just run into the back of you).

But for most of that time, I've been mulling over Paul Dyson's post about Pair Programming and Common Sense. It reminded me of a couple of things. First, it reminded me of the Vikings and the Inuit in Greenland as it is described in "Collapse" by Jared Diamond and this white paper that I wrote after reading it ages ago. The upshot is: even if something is happening right in front of you, that you have to notice to save your life, there may well still be cultural and religious reasons why you can't see it.

The second thing it reminded me of was my experience of reading Wittgenstein. When I was a second year at university, I would chat to some of the older students and they would try to tell me "But, you see, for Wittgenstein, the meaning of a concept, is it's use!" And I would have no idea what they were talking about. Then I spent a year or so (only in my spare time of course) reading the Philosophical Investigations. At the end of that year, I found myself saying to many many uncomprehending people, "But don't you see? The meaning of a concept is its use!"

In many ways what Wittgenstein says about meaning is so forehead-smackingly obvious that when you hear it and understand it, it seems almost unremarkable - you might even say, common sense, but that didn't stop it taking about 2300 years for anybody to come up with an answer to Socrates's problem of how we define "good". One of the reasons is that Socrates sets the problem up so that it's looking for a definition, and it takes a genius like old LW to come along and climb out of that culture, that mindset and point out that abstract definitions are precisely the problem. Obvious when you understand? Yes. Common sense? maybe. Easy to figure out for yourself? Possibly, if you've got 2300 years to think about it.

Perhaps this is why so many people fail to see the "common sense" of pair programming, they're in a culture where, as managers, they're supposed to get the most out of their people - as one of my management consultant friends sometimes rather unpleasantly puts it "sweating assets". In order for pair programming to make sense, they have to be in a culture of solving software problems in the most efficient and resilient way possible irregardless of team groupings. The Vikings wouldn't realise they were in the survival business and start fishing like the Inuit even when it killed them, so perhaps persuading people to do what can be regarded as "Common Sense" isn't that easy.


For further information, contact Mark@agilelab.co.uk (07736 807 604)

Technical Aspects of Agile – Two-day course

Aimed at developers and team leaders who are already familiar with Agile approaches, this course with three important technical aspects of Agile software development.

Pair Programming

To many people, especially in senior management, pair programming seems completely counter-intuitive. Surely, by getting two people to do the job of one person you're just halving your productivity? A substantial body of research shows quite the opposite - that pair programming doesn't reduce productivity, but maintains productivity whilst substantially reducing the number of serious defects that are found in the code.

This course covers the very good reasons for introducing pair programming and how to deal with some of the potential objections. It also deals with how to start pair programming - what are the do's and don'ts and provides course participants with some hands-on experience of programming with other people.

Test Driven Development

The practice of writing a failing automatic test for each piece of software functionality, together with a script that can run all of these tests has many beneficial effects on the process of software development. This course gives participants experience of writing tests and then coding against them using the well-known testing framework JUnit.

Re-factoring

As software development progresses on a project, code gets messy and changes in one place cause unexpected problems in others. Re-factoring accepts the reality that code gets messy over time and builds on the advantages of TDD (test-driven development) to allow principled clean up of code. Course participants will be given a chance to clean up the kind of horridly entangled bits of code they might experience and be shown the possible benefits of re-factoring for the ongoing support of the code base.

Attending this course will allow you to: transform the way you write software by getting hands-on experience of three important technical aspects of Agile – Pair Programming, Test Driven Development and Refactoring.

Suitable for: Software developers and leaders of software development teams. Working knowledge of the java programming language required.

Contact: Mark Stringer
Email: mark@agilelab.co.uk
Mobile: 07736 807 604

This entry as pdf

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Notes from a fry-up lunch

I had a fry up lunch on Wednesday with a friend of mine who's a developer and two of his fellow developers (he can own up in the comments if he wants to) a few things came up in conversation that I want to note down here - I might write longer pieces on them later.

• Quote: "The two projects that we made money on are the two projects where we said [admitted?] that we don't know". The standard case where the customer comes to you and says "How much for X" and you say Y pounds RARELY MAKES MONEY! But the model where the customer come to you and says "How much for X" and you say "Mmm, dunno. Do you want to pay me a little bit of money to have a look?" THAT MAKES MONEY! Maybe you can't get there straight away, maybe you have to do some fixed price stuff to get to that stage, but isn't good to know where you should be heading?


• A compelling reason for becoming involved in open source is that you get the respect of your peers. You also get coached by people who know what they're talking about. This is very different from the kind of feedback that you get from customers which is all about bugs or things not looking the way that they should. Perhaps pair programming could be a kind of mini, in-house open source in this way.


• Related to this - the loneliness of the self-taught programmer. Most programmers are autodidacts - they teach themselves. This means that some areas are very strong and some areas are very weak. When other people look at their code self-taught programmers can feel very foolish. If you're a self-taught programmer and you're trying to work within a framework which is supposedly helpful to development, such as test driven development, or pattern-based design, this can be very traumatic and cause you to really lose self-confidence. Maybe this is why some guru/surgeon programmers are so reluctant to pair program.

The Loneliness of the Self-Taught Programmer

I have a friend who is very well-read in all kinds of fields. He has a PhD in Organic Chemistry from Cambridge University but he is also widely read in Russian and French literature. He bundled through the Penguin Classics well before we left sixth form. He likes all kinds of pop music and he also likes opera. What's more he achieved all this culture and erudition from a relatively humble background - most of his reading was done in the ice-cold back bedroom of a council house in West Yorkshire where he grew up.

Now aren't we all lead to believe that education and culture are a good thing? Shouldn't having read all these books have made my friend more confident and well-received when he did finally get into polite society? Well, it should have done, but there was slight problem. Pronunciation. He'd read Proust, he loved him, but he didn't know that his name was pronounce to rhyme with "roost" and not "roust". He loved Puccini but he didn't know that the word "aria" isn't supposed to rhyme with "Mariah".

And so when he did get into polite society, people laughed at him. People who had never read Proust still felt it was all right to laugh at his pronunciation. He learned the correct pronunciations really quickly of course, but he never forgot the sharp humiliation of those condescending smiles.

I was at lunch yesterday with 3 coders, one of whom I'd never met before. We talked about Agile stuff for about 10 minutes and he didn't say anything. Finally he said that working on a project that used Agile methods - particularly in his case, test driven development - had made him completely miserable. After he'd left the project he'd lost all faith in his abilities to code. It took him several months to regain any confidence.

Learning to program is a back-bedroom, late-night activity for most people. Most people who do it, are autodidacts - they teach themselves. There are university courses that claim to teach it, but most of them miss the mark. Either the course is too prosaic and equates teaching programming to teaching the syntax of a certain language or the course is too theoretical and imagines programming to somehow happen as a natural bi-product of understanding certain branches of mathematics.

Even if you're lucky enough to find a course that does teach you programming instead of computer science or discreet mathematics, in order to actually write anything that works there's a ton of arcane detail that you need to learn and there aren't many ways to do that other than dragging through tutorials, manuals, FAQ's and forums and other people's code by yourself. By the time you've done that it's not likely that your knowledge is going to be rounded, flexible and generally applicable. It's more likely that your knowledge is going to be, at least in some areas, brittle, specific and sketchy. So what are the chances that you're going to want someone to look at your code?

And maybe this is what is behind what seem like stubborn denials, refusals and condemnations of pair programming. When you suggest to someone that you write code with them and their response is "I taught myself to code, why should I be forced to do all the work for some rookie who can't be bothered to stay up nights himself," or even "I don't have to drink a bucket of vomit to know it's a bad idea." You might guess from the emotive reaction that there's fear involved. Perhaps the fear of the autodidact.

RSS - Rogue Surgeon Sydrome

The surgeon model as advocated by Fred Brooks is the second most efficient method of developing software. The analogy is with the surgeon who is the focus of the whole show during an operation - the one that all the other members of staff are there to support. In many small technology companies, essentially, you have one surgeon/founder/guru who writes all the code himself, or certainly writes all the difficult stuff himself. Quite often the surgeon was the one who came up with the idea for the software or the business in the first place, it's his drive, his creativity and willingness to do something different from the herd that is the reason that there is business at all. If the surgeon is good this can be a very effective way of getting software written. For a while.

There's a problem though. The surgeon model doesn't scale. At some point a successful piece of software is going to need a lot of boring, non-charismatic things done to it, like multiple language support and multiple platform support. At some point the organisation is going to grow and start to hire people who aren't doing it for love, but for money. Somewhere around 10-15 people organisations can no longer be run charismatically (because everybody just loves being in the founder's gang) and have to start being run bureaucratically (because people do the job they are paid to do). Accounts staff, sales staff and business development aren't the kind of people that the surgeon/founder - as someone I know delicately put it - wants to go to lunch and eat noodles with. To avoid these problems many new media and technology companies get stuck at around 10-15 employees, vaguely hoping that they'll be bought out by some Silicon Valley conglomerate. With no other growth/exit strategy they stagnate. It can be unpleasant to watch and even more unpleasant to experience.

This is a very tricky situation to be in and there aren't many good solutions. Quite often the "Surgeon" in this model is a founder of the company. The kind of person who founds a company isn't the kind of person who wants to follow rules. That's how they got where they are, by not following rules. Sometimes for other employees this can be very inspiring. Sometimes it can be very tedious. People who have had to work with Steve Jobs have called this the "Hero shit-head roller coaster". At one company that I used to work for, the "Surgeon"/founder would resort to chanting "Ooh! Aren't we grown up!" whenever the issue of pensions was raised at board meetings. This was infuriating for the other board members who had grown up, had wives and children and would really quite like to not have to survive on Pot Noodles for the last 20 years of their lives.

You can bring in "professional" developers and "professional" project managers - these are people who rely on process rather than charisma to get the job done. But very often they don't sit well with the people who are already there, gathered around the surgeon. When I suggested to one company that I talked to that they deal with this problem by hiring in outside project managers they said "Yeah, we tried that - he got eaten alive." You can bring in professional management and then fire the founder. Apple did this and that didn't work out so well either. What companies really need to do is restructure in a way that allows the company to scale and remain creative. The surgeon/founder should be given a role where he can carry on doing what he's good at - doing new things, breaking the rules, in business speak R&D.

Agile processes can help ease the passage through this difficult period. Pair programming allows the surgeon/founder/guru to spread his knowledge of the software around the development team. Test driven development and refactoring reduce the demands on the surgeon/founder and leave him free to do what he's best at - thinking good thoughts, breaking the rules and coming up with new product innovations. But Agile can't be the whole answer. You're probably not supposed to say this, when you work for an Agile training and consultancy company. Things will only really move forward when the founder and others on the mangement team admit to themselves and each other what they actually want from their careers and make sure that this is something that their position in the company can really provide. Maybe this is an Agile process because Agile is all about having those awkward conversations sooner rather than later.

This isn't just a problem in software development. I've been talking it over with Dave Dawes who works with social enterprises in the Health sector and he recognises it as a common problem. In many fields, amidst all the hullabaloo about the need to support entrepreneurship, the need to support successful organisations that are ready for the second wave sometimes gets lost.

Try everything once...

This post has been bothering me for some time.

I was tempted to point out that programming simply isn't like walking down the street. Programming isn't a straight race. In programming: fast!=good. But then, when I thought about it some more I realised that programming in a team is in some ways like walking down a busy street: like it or not, the best way for anybody to make progress is to have some sensitivity for the speed at which others are moving. In both programming, and in walking down the street: fast!=good.

Finally I wondered who would want to hire, or be on a team with, the kind of person who can't even walk down the street without getting annoyed. But maybe behind all this maladroit bluster is fear. This is what Kent Beck has to say about fear in the preface to his book "Test Driven Development".

• Fear makes you tentative [and so reluctant to try something new - like pair programming?]
  


• Fear makes you want to communicate less [like maybe not wanting to pair program?]


• Fear makes you shy away from feedback [like maybe not wanting to pair program?]


• Fear makes you grumpy [like getting annoyed with people you don't know for walking down the street?]

But what are his fears? Are any of them legitimate? It might be legitimate to fear that pair programming will mean that you will have to spend your entire working day explaining to some newbie where to put the semi-colons. For this reasons pairs should be changed regularly. It might also be a legitimate fear that some of our best ideas and our best problems to solutions happen when we're alone. A way of working that allows people to cook up ideas in private before they test them out in public is well-known in other collaborative fields - the so-called "Cave and Commons" approach. For that reason, pairing shouldn't be scheduled to take up the whole day. Programmers should be give time in their "Caves" to get their heads together and sketch out ideas. A friend of mine who regularly paired with someone and didn't take this approach said that he and his partner found themselves coming in earlier and earlier each morning to try to sketch out their ideas and find a solution to the previous day's problems before their partner arrived.

Pair programming is about learning from other people and letting people learn from you. Pair programming is about sharing the knowledge of a system around a team. If you're really worried that you're not going to learn anything new when you pair with someone, don't be. Ask any teacher, they'll tell you that you only really understand something once you've taught it to someone else. And that's assuming that you manage to find someone who really can't teach you anything. Chances are they will know something you don't know. They'll know a library you don't know of, they'll have worked on a bit of the system that you don't know. They'll know a keyboard short-cut in Eclipse, or (may a higher power preserve us) in vi. They'll have been taught the latest template libraries in their final year at college.

There are lots of reasons why this is a good idea. If a member of the team leaves for some reason, it reduces the chances that some part of the system will become impossible to maintain . It increases the chance that mistakes and problems that require knowledge of the whole system will be spotted. But it's certain that pair programming won't work if it's forced on people.


Agile Lab's Technical Aspects of Agile course offers developers a chance to experience pair programming in a safe, non-threatening environment. At the same time they improve their technical skills in test-driven development and their coding and architectural skills through refactoring.

Technical Aspects of Agile - Central London 8th and 9th July

We're running a course on the Technical Aspects of Agile on 8th and 9th of July at 01Zero One in Soho, central London.

The course will run for two days. The first day will deal with test driven development (TDD) and the second day will deal with refactoring. Throughout the course people will be asked to pair program.

We understand that for various reasons people can find pair programming daunting. This is a perfect opportunity to give pair programming a try in a safe, non-judgemental environment. We think you'll like it.

Technical Aspects of Agile - Course in Development

We're thinking of running a one-day, actually possibly a two-day course that covers some of the crucial technical aspects of Agile. We would probably run this through 01 Zero One in central London, where we've already successfully run our introduction to Agile methods course. We would probably offer the course initially to people who are comfortable programming in Java, but we might also offer it for more web-based languages such as Flash, AJAX/Javascript or Ruby on Rails. Of course if any company wanted us to run the course in a particular language, we could talk to them about offering the course them in-house.

Pair Programming. To many people, especially in senior management, pair programming seems completely counter-intuitive. Surely, by getting two people to do the job of one person you're just halving your productivity? A substantial body of research shows quite the opposiste - that pair programming doesn't reduce productivity, but maintains productivity whilst substantially reducing the number of serious defects that are later found in the code. This course would cover the very good reasons for introducing pair programming and how to deal with some of the potential objections. It would also deal with how to start pair programming - what are the do's and don'ts and provide course participants with some hands-on experience of programming with other people.

Test Driven Development. The practice of writing a failing automatic test for each piece of software functionality that is added to a system, together with a script that can run all of these tests has many beneficial effects on the process of software development. This course would give participants experience of writing tests and then coding against them using a well-known testing framework such as JUnit.

Re-factoring. As software development progresses on a project, code gets messy and changes in one place cause unexpected breakages in overs. Re-factoring accepts the reality that code gets messy over time and builds on the advantages of TDD (test-driven development) to allow principled clean up of code. Course participants will be given a chance to clean up the kind of horridly entangled bits of code they might experience and be shown the possible benefits of re-factoring for the ongoing support of the codebase.