gistfile1.md

#How I went from forklift driver to developer in 9 months.

##Description

Moving up the ladder from forklift driver and general labourer, to front end developer, with a stint in manual testing, was a big challenge. However it’s exactly what I did, and I couldn’t have done it without following a few core principles.

Getting up the nerve to go to local usergroups, and conferences, and discovering a new found love of public speaking, was a huge leap from labouring. Similarly, I discovered contributing to open source wasn’t that big a deal, and some things certain projects did made it really easy! Also, learning about things like source control was super integral to being where I am today.

The most important part was trying to learn something from everyone I met. It didn’t matter where I met you, if I saw an opportunity to learn more, or try a new thing, I was there.

I’d love to tell you how I went from forklift driver to developer in less than 9 months, and show you how you can help anyone wanting to make a start.

##Abstract

This talk focuses on how you teach people, and how you present things in ways that made sense to me, and will hopefully challenge how you think about explaining fundamental concepts to people.

I wanted to try and learn something new from everyone I met, and it put me in good stead as I got involved in my local tech community, and went to conferences and got a job within the tech industry.

I’d also like to go into how you can help newcomers with the tech-y things that people kind of take for granted within the development world. Things like source control, open source contributions, and watching and giving talks at local usergroups, and conferences.

I think it’d be really good to look at how we onboard people to projects, in Open Source, or your company’s codebase, because I think it’s a really important transition to go between, I know how to think programmatically, to I can contribute to the code that's already written and rewrite it, and look into how someone new to a legacy codebase reads the code.

Hi,

As a rule, the abstract of a talk should provide information to the attendee on what they can expect from the session in terms a number of things:

• What is the subject?
• What level is the talk aimed at?
• Is the speaker an expert in this subject?
• What will I learn and take away from this talk?

I think that the concepts outlined in the Description section could be an interesting talk, but I don't think that the abstract sells it as it doesn't tell me, the attendee, why I should come to this talk.

Make the first line of the description about ME rather than about YOU. You can tie in your story later - it's a good one - but the opener needs to be focused on what I'm going to get from the talk. If the takeaway is _____________, THAT is what needs to come first. And by takeaway, I don't mean the specific advice, but what that advice will DO for me.

This is way too long. I'd recommend making it a bit more concise, keeping the details of your story for your talk and just mentioning the high-level outcomes in your abstract.