86p blog

My DPC Speaker Experience

You may notice that my last blog discussed my route to DPC and how I planned to deliver a good talk. Now you know what they say about the best laid plans… I had so many ideas about how my talk would be delivered but actually giving a talk turned out to be much harder than I first thought! I was delighted even to be considered to give a talk at DPC11 and I’m now offering some thoughts on the traps I fell into and how I would like to improve if I get the opportunity to give a talk again.
 

Delivery … 

Giving a talk looks easy, right? Well that’s what I thought, before I gave my talk. It’s very easy to criticise speakers and much harder than I believed to actually deliver an enthusiastic and engaging talk. This is actually the first trap I fell into, I’m generally quite a confident guy but put me in front of an audience and that soon changes, so I practised my talk a few times; I spoke to my fellow colleagues, I spoke at PHP London and PHP West Midlands. However standing up there yesterday, I really felt like I hadn’t practised enough. So my biggest tip if you’re considering giving a talk and you don’t have much experience would be to practise, practise, practise again, then practise some more.
 
Although I had practised this talk before, with varying degrees of confidence I must admit, on the day my confidence levels plummeted. Now there were a couple of reasons for this, firstly I had a last minute change in slide order and content (I’ll come to that later) and secondly it suddenly dawned on me that I was actually giving a talk on DPC and if I was listening to this talk I might be a little bit bored. Not the best thing to come into your mind when you have an audience I can assure you! So it really is important to conquer your nerves and sound authoritative and most of all be enthusiastic about what you are delivering. Conquering your nerves and sounding enthusiastic is not that easy and I’m sure you can read many theories on how to do this ranging from “imagine everyone on the toilet” to “imagine yourself sucking a lemon”.

One other thing I would think about when delivering a talk is how to command the space. While you may not think it, your movements and body language help to engage the audience. So one tip I was given by a former colleague was that if I wanted the attention to be on the slides, remain still however if I wanted the attention to be on me (eg if I was just talking and the audience didn’t need to look at the slide) then I should move around, use gestures etc.

Finally, I think it would have really helped my talk delivery if I had given more examples of how to use search, and Solr in particular. I think from my own personal experience of attending a talk that it is easier to follow if the speaker gives a story behind their choices. So when talking about Solr, on reflection, it would have been better to include more real-life code examples in screen shots and explain each of them in greater detail.   

The slides….

When writing the slides there are many things to be taken into consideration. The most important lesson I learnt yesterday is that it is a bad idea to change your slides before you talk. Too many alterations are not a good move, especially last minute. A couple of days before my talk I changed the order of my slides, this meant that the talk I gave at DPC was different to the one I had practised. I would not recommend changing slides after having practised the talk extensively, as this was offputting. During the talk, the slides I anticipated coming up next were not there and I found it really hard to remember what was coming up next. After all those changes I then thought that actually the slides were in a better order beforehand, as I’d actually written a methodical plan.

Something to consider when writing the actual slides is not to put too much on each slide. Of the talks I saw yesterday the ones I preferred were the ones with little information on each slide. This was a trap I thought I had avoided as I thought about it carefully during the writing process. However I think there were some slides with too much information and a clearer way to plan the slides would be to have no more than 3 brief bullet points per slide which you can then explain. Visual images also help to maintain interest levels, such as a live demo to truly show the power of searching with Solr.

Finally …

In conclusion, I would say that although this talk may not have been as successful as I had hoped, it has been a great experience. I think it’s always good to take on new challenges and this was I bigger challenge than I had anticipated. Doing my first talk has been a steep learning curve and now I definitely have a better idea of how I would go about doing a talk in the future. Thank you to everyone who has given me constructive feedback. Talking at an event such as DPC takes a lot of courage and I certainly have more respect now for speakers having gone through the experience myself. I wish anyone giving a talk the best of luck, don’t forget to practise as much as possible!

Road to DPC: Part 1 - CfP and Plan

A few weeks ago I submitted my first talk to a technical conference. I honestly didn’t even begin to think I’d get anywhere with it this year, but hoped that it’d all be good practise. As I expected, it got rejected and my friends who’d been involved with the selection process told me it was a close call. Then just over a week ago, an excited Harrie Verveer got back in contact saying they’d like me to talk after all. Amazing news!!! Then the realisation that I’ll be talking in front of a crowd of professionals - terrifying.

I genuinely couldn’t have got this far without all the help from my friends. In fact, I hadn’t planned on submitting to this conference, it’s only because Harrie asked me to submit that I even considered it.

I’ve been attending technical conferences for the past 5 years, all thanks to David and Katherine Goodwin of Pale Purple. They convinced me (though it didn’t take much) to go to PHP UK way back in 2006. I thoroughly enjoyed it and have been attending them ever since (and others besides). For me, conferences give me overviews to topics and allowing me to check my knowledge on a subject against other professional developers. I then spend time investigating further to the subjects that interest me most.

I don’t overly subscribe to the whole “Speakers are rockstars of the PHP world” aspect of conferences, though I do enjoy talking to people who have lots of experience with a technology. I hope to some day give back to the conference community that has inspired me so much.

So now, for the first time, I’m setting off down the road of preparing for a conference. I’ve no doubt it’s going to be a nerve racking ride - quite literally, I get very nervous talking in front of people, though I know I’ll enjoy it eventually. Talking to my many speaker friends, I’m starting to realise the effort that goes into every talk I see at these events.

My rough plan of attack for not making a complete fool out of myself in front of between 1 and 300 delegates (most likely near the 1 end of the spectrum), is as follows:

• Research - gathering resources, read as much as I can

• Blog - I’m writing a technical blogpost that follow on from my talk

• Draft - Write my talk, bounce it around my fantastic technical friends who’ll more than likely put me straight

• Create - Divide the talk into slides, ensure they flow, apply a theme, make it punchy, the usual fun stuff

• Practise - I’m lucky that my girlfriend is a teacher, though it’ll bore the hell out of her, she can help me with my delivery

• Practise - I work with a great bunch of technical minds only too willing to correct me when I go wrong, or ask tricky questions

• Practise - I’ve scheduled myself in for talks at various PHP user groups and I’m hoping the practise in front of similar audiences will help be the final preparation for the talk

  • 05/05/2011 - PHP London

  • 10/05/2011 - PHP West Midlands

• Deliver - By this time, I’m hoping to be sick of my talk, so fed up of it that the prospect of getting it over with will be so good that I’ll be looking forward to getting up on stage.

Looking back at the preparation, this looks like a lot of effort. I hope it gets easier with experience, assuming I get accepted to future conferences.

Over the next few months, I’ll be writing about my first ventures into speaking at a conference. I’ve no doubt it’ll be a challenge and perhaps people can give me pointers on how to make it easier. The goal of these blog posts is to inspire others to do the same. Write your first proposal. If you want to know how hard it can be, stay tuned and I’ll do my best to describe it to you.

Tips: Applying for technical jobs

If there is one thing I can pass on to potential interviewees, it would be always think as if you were the other side of the table. I hope this entry enlightens some people and perhaps I’ll get a different perspective to keep in mind with my future endeavours.

I’ve recently been involved in technical recruitment at Ibuildings, which has taught me a few things about the whole process from the interviewers perspective.

First and foremost is that writing a good CV still isn’t common knowledge. The curriculum vitae is an applicants first engagement with the company (usually) and yet some people still don’t put in the required effort. I realise that everyone has their own style, but I think I’m aiming for common ground when I say; CVs are not the place to waffle. Concise, thought out paragraphs are desired, not essays of unsubstantiated claims. Something else I look for is a clear list of relevant skills and their level. Not like a skills matrix but something to give me a good idea of an applicants preferred skills and how they would rate them self.

Secondly, if you’re presented with a coding task, there’s a good chance its there to get an idea of your coding abilities and style. In other words, don’t make the solution as small as possible just because the task mentions not going over the top. From my perspective, a coding task is to see if the candidate has some of the required skills for the job. If your application has errors or warnings (under any operating condition), what does this say about your abilities, if nothing else your attention to detail.

If you make it to the interview, relax and answer honestly. Obviously it’s not easy to relax, but something candidates always forget, an interview is a two way exercise. The candidate should be deciding if they like the place / people as much as the interviewer is checking they would fit in. Anything can come up in an interview, random questions, practical tasks, the important thing to do is try to remain calm and think clearly. If you don’t answer honestly, get the job and are put in a situation you can’t deal with, it’s going to be a waste of your probationary period. Always ask at least one question, it’s an easy way to show that you’re interested and can see yourself working for the company. Try and go into the interview with a positive attitude. Finally, if you go into the interview with a positive attitude, it shows and your interviewers will be left with a positive vibe.

To summarise, think about the process from the other side. Put effort into the procedure, it’s a short time that can make a lot of financial difference. Remember it’s a bidirectional process and you can leave at any time.

Introductions

My name is Paul Matthews and I’m a Software Engineer working in London. My hobbies include snowboarding, photography and Taekwondo. Amateur photography being a relatively new development, though I encourage you to take a look through my photos on Flickr - any advice is always welcome. Snowboarding on the other hand I’ve been practising for years, unfortunately the sporadic nature of my practise has resulted in only averagely developed skills.

I work for the company PHP development company Ibuildings. My roles include bespoke application development, pre-sales and architectural design. Currently my technical interests include MongoDB document database, Solr search platform and Git version control system. I’ve recently published a blog post about starting out with MongoDB in PHP and I hope to continue to share what I’ve learnt and hopefully learn some more by doing so. If you’re so inclined, you can also find my personal Github account.

With any luck, over time the 86p blog will offer everything it can to help aid others in their quest for technical knowledge. More importantly, it’ll save my girlfriend from having to listen to me explain technical concepts in real-world terms, for which I’m sure she’ll be grateful.