Mark Everard

I was lucky enough to participate in the first UK GiveCamp over the course of the last weekend.

Wow, what an incredible experience!

“Pair 120 developers with a collection of UK charities each with an IT need. Lock them in a room, feed with caffeine, cooked pig and sugar. Leave to bake over the course of a weekend, peel open (and off the floor) on Sunday afternoon. Stand back and view the results.”

The concept, execution and community was superb (see @stack72′s post for a great list of thanks to those involved). A special thanks must also go to UCL for hosting the event and the generous sponsors for providing financial support and goodies! Come the Sunday afternoon ‘show and tell’, all of the project teams delivered some great work, much of which will make a tangible difference to each of the UK charities that got involved.

“For the first time in living memory, someone cried because the software we did was so good.”

What better testimonial than this? How many times have you had this reaction whilst working in your day job

GiveCamp UK 2011 - photo by Bert Craven

A software development microcosm

Whilst the time-scales involved in GiveCamp make it an unreal experience, at the end of the day it’s just software development, and so the normal rules and pitfalls of software development apply.

The thing that really struck me whilst working, is that is that it’s very easy to get carried away and lose focus from the end output. Whilst much of this could be attributed to the excitement, intensity (and tiredness) that surrounds the event. Actually it is just par for the (software development) course.

If you’re ever involved in a future GiveCamp (and by all means you should), here are some of my top tips……

Deliver deliver deliver

Don’t overreach and try to build the Tower of Babel. Solving one problem well, is better than half solving many problems.

This means you constantly have to question the solution to make sure that every design decision that is made, is made for the right reasons. Do you really need that level of granular security or additional view? Focus on your core functionality only.

Remember building ‘cool’ stuff is not the output you’re looking for. Delivering a working solution that solves a real world problem is the ONLY goal….

Engagement

As ever, it is important that you have a engaged stakeholder / product owner – who is actively available to field questions and define their needs (we all know this from our day jobs right?)

Remember though, the charities will be like a kid in a sweetshop – whilst you are their ‘knight in shining armour’. It’s ok to question their requirement wish-list. 41 hours is not a long time to deliver a solution. So always make sure you stay focussed on solving a real and well defined problem.

Keep it simple stupid

After the weekend, the solutions are handed over lock and key to the charities. You need to make sure they know what you’ve built for them and that they have enough information to support it going forwards. This could mean documentation! One team produced a 40 page document on how to install a SQL Server instance. The time spent on that document was way more important than any one additional software feature. Without it, the solution wouldn’t have even been deployed.

Remember – not everybody knows the things you as a developer takes for granted. Imagine that you’re delivering a solution for your dear Nan. That’s the level you should aim for.

Focus on what you know

When you’re under pressure to deliver, don’t go off-piste and make some ‘left-field’ technology choices, so you can learn the latest new and shiny thing. Stick with what you know and what your team has capabilities with. Don’t worry, they’ll still be plenty of opportunity to learn.

For me I was working with ASP.NET / MVC but I still learnt more about Git, Entity Framework and what an awesome service AppHarbor provide.

Future me

I definitely wish I’d had ‘future me’, looking over my shoulder to remind of those things throughout the weekend (especially at 2am on Sunday morning when the adrenaline was wearing thin). However I also know that ‘future me’ would have told me how proud he was of all of us who donated time and effort to help out.

Top stuff to all involved. Here’s to GiveCamp UK 2012!

As programmers, we’re very used to dealing with systems that are easy to understand and behave predictably (though I have worked with some codebases that are the exact opposite).

Aside from code, the majority of our day-to-day interactions in the workplace are with team members, managers, clients and other colleagues. These human interactions are often much harder to predict and respond to, but can have a much greater impact on your work environment, productivity and workplace happiness.

I attended Roy Osherove’s ‘Lead Better London’ course held at Skills Matter back in July (and have been meaning to post a follow up about it ever since). Roy was / is a leading voice in the .NET community (though now he’s exploring what Ruby has to offer) and is the author of ‘The Art of Unit Testing‘, which I consider to be THE book to read if you want to learn and become better at writing test code for your software. Roy regularly blogs about software team leadership issues over on FiveWhys.com, and it is from there where I found out about the course.

The 2-day course caught my eye, as it was focussed on managing people and software teams rather than any specific project methodology, such as agile. Courses such as these give you a great opportunity to take a step back and view your workplace and your interactions within it in a different light, without the distraction of your ‘real work’. Roy is a great mentor and from the off, ably demonstrated the ‘ninja’ leadership techniques he was trying to teach to us. His ability to listen, comprehend and consolidate a problem down to a fundamental is a skill I really want to perfect.

Things I took home with me from the course:

• Confidence to Lead: motivation to tackle the issues I see day-to-day in my workplace
• How I react: ability to recognise my own and my colleagues behavioural traits and adjust my response to suit
• Who I want to be: a clearer idea of the characteristics I believe make a good leader and the willpower to make sure I follow the right path.

The plural of Lego is Lego, not Legos. The word Lego is a trademark and should be used as such. Here is a picture of some Lego bricks.

Roy is holding another course in London this November (2011) , so if you’re interested in learning how to lead and grow a software team, then you should do what you need to do to get yourself on his course.

For me, the challenge now is to take the skills I’ve learnt and put them into practise in my day-to-day work life.

Let the human experiment begin……

Slides for a talk I gave to Fortune Cookie’s HTML developers, where I tried to press the following points:

1) WebForms != ASP.NET
2) MVC FTW