This past weekend I had the opportunity to speak at Silicon Valley Code Camp. I shared with my fellow developers the process I have developed when participating at hackathons. The process is quite extensive, so 75 minutes was not long enough to get through quite the number of experiences I’ve had. Here’s a brief summary of what I mentioned.

I started off by sharing a little bit about me. I’ve been a web developer since I was a teenager. I started my first website to announce the “upcoming” short stories I was writing back then. I was a kid that enjoyed writing and pretending I was some kind of writer/developer/marketing extraordinaire. From there I continued building desktop websites, and eventually moved into more dynamic languages including Perl, PHP, JavaScript and HTML.

Within the last decade I’ve been more mobile focused, building responsive web apps for the iPad and mobile devices. I also picked up Node.js and some native development in Android along the way. I found my passion of hacking prototypes when I discovered what I could build in less than 24 hours. Had I not attended my first hackathon, I might have taken a completely different path in life.

In August 2009, I went to a Google Wave hackathon thinking I could get free food and maybe learn something about the social platform with robots that could interact amongst the community. However, I learned quite a bit from that experience, and how to handle failure. It turned out that I didn’t know Java very well, and I stumbled through session cookies trying to get the now-defunct API offered by Kayak working. I learned how team communication is key, and how a lack of communication can lead a team down a path of trouble.

Each hackathon since, I’ve always made sure to keep my teammates in the know of my progress and any blockages I might have, and to make sure I know any of theirs. You see, a Java programmer could have solved my hours-long struggle in a matter of minutes, had I only asked my teammate! Instead, I wasted hours, and ended up not finishing my implementation at all. How embarrassing!

But if you learn from failures, you can make them successes. After each hackathon, I write down my failures and successes so I can be reminded of what I’ve been through and what I have learned. Occasionally I peruse the list and see where I’ve improved, and what I still need to work on.

I also talked about my life experiences. I am a NASA enthusiast, watching rocket launches and getting invited behind the scenes of missions NASA is supporting has been incredibly inspiring to me. To see a rocket launch reminds me of all the hard work that goes into these missions. When you understand the amount of effort that is put into the mission, and the blood and sweat, you can’t help to appreciate what humans can accomplish when they work together. I’ve met my share of astronauts, and Hoot Gibson has quite a story to tell.

I have also travelled quite a bit around the United States, blogging about my journeys on 30daysoftravel.com. I have learned the different cultures across the states, and how some are less technical. Different places have different approaches to solving problems, and it is this differentiation that can be valuable to building products.

I mentioned some of the typical skills that a hacker can come to the hackathon with. From a designer to front and backend developer skillset, to business and marketing power, you have at least one skill. If not, you have a problem. Seriously, a problem to solve. Check out my guest blog post on AT&T’s Developer blog for more about that.

Over the last two decades, I’ve watched as the web environment has changed. We used to have web browsers rendering simple webpages. Then came mobile devices that changed the browser size of websites and added touch. Then hardware like the Raspberri Pi, wearables, and now the connected car have changed where we use these solutions. In the car, we use our voice and audio to interact with applications. If that wasn’t enough options, where do we host these solutions?

I talked about the cloud ecosystem, and how IBM’s Bluemix platform makes it easy to deploy your applications. Further, at the time of posting this, there are over a hundred services on IBM Bluemix that you can use in your hacks. From designing a mobile application using Kinetise, to integrating Single Sign On with Google, LinkedIn, and Facebook to your app, to analyzing the text people write in emails and ranking them on positivity using IBM Watson’s Tone Analyzer API, to storing data and running analytics on the data using dashDB. It would take many blog posts to showcase what Bluemix offers, but stay tuned!

The number of combinations available to hackers today are nearly endless. It’s a great time to get into hackathons and harness all these tools to build prototypes of your wildest dreams.

That’s why I joined the IBM Bluemix team as a Technical Evangelist here in Silicon Valley. I love to share my quick/quirky prototypes and how I build them with others, hopefully inspiring them to try it themselves. If I can walk away from a presentation knowing someone listened and absorbed how I approached the problem I solved, I have made a difference. I have received some really touching emails from college students who stopped by the IBM booth this weekend and are inspired to share with their universities the power of a hackathon. I have found my passion!

With a restraint of 24 to 48 hours at a hackathon, I emphasized how important it is to start small and think big! Using a jigsaw puzzle analogy, I try to make each part of my hack a puzzle piece. Mentally I know they fit together, but always have the option to switch them out if necessary.

If something doesn’t quite work, maybe the puzzle piece can be rotated (maybe the better word is pivoted) to work differently, and fit better. You know how the knob of the puzzle piece kinda fits, but you find out it really doesn’t? Grr, I hate that!

Completing a jigsaw puzzle takes time, so keeping things simple can show progressive progress. Once I put several puzzle pieces together, I can see a face to a human in the picture. In hacks, for example, I start to see how email messages can be analyzed using IBM Watson’s Tone Analyzer. My vision starts to come alive. I know eventually I’ll have a text-to-speech component to finish off the hack, but I keep it detached to help manage the stress level so I don’t get overwhelmed. I think big by planning the path I’m going to take given more and more time.

It’s important to start with things you already know. For me, PHP and Node.js are my go to languages. I build HTML/JavaScript proof-of-concepts because I can see things coming together visually pretty quickly. Click save and launch a web browser with your HTML file, and you can see instantly. Push it to IBM’s Bluemix platform in a matter of a couple of minutes, and share the URL with your teammates or scale worldwide. Times have certainly changed (for the better)!

As the number of hackathons under my belt have increased, I have worked on a large number of APIs and understand the patterns and commonalities they share. They all have their quirks and differences, but they act similarly. Your app provides data, said API does something, and it returns data back to your app. The API might store data, you might retrieve data from it, or it can do a variety of different things like send text messages.

Sticking with things you know best helps you get off the ground quickly. Once you have a base, expand your experiences. It is similar to a baby taking their first steps. They learn their motor skills and how to operate their arms and legs. Then how to wiggle on the floor, followed by elevating their butt and eventually onto their feet. They fall, but learn to get up. They conquer the balance equation, and they put one foot in front of the other. Success!

Over the last six years and a hundred hackathons, I have learned how to visualize what I’m building and piece by piece to build a prototype. APIs are so much fun for me because there is always something new to try out. The sponsors are always interesting to talk to and I enjoy understanding their marketing and branding process.

Sponsors come for a number of reason. First, brand awareness. If you don’t know they have an API, you’re less likely to build on their platform. They also want to see what others might build on their platform. It is one thing to have internal hackathons with your own employees, but having fresh faces on your API can be quite a difference. Taking those concepts back to the product team to enhance the product is also very valuable. Then comes partnerships. Some companies invite teams to followup and pursue the process of taking their concepts to market. Both parties benefit from that. Here’s an example of how AT&T helped publicize Read With Me.

I discussed how to tell a story when pitching your prototype. You want your audience to be engaged, interested enough to get behind your product. If you get passionate users behind you, they will end up marketing it for you! Judges love unique approaches. Don’t reinvent the same billion dollar startup that has taken three years to be where they are now. You will likely never catch up and always end up being behind your competition.

Another mistake I see frequently is using slides. Unless you’re pitching a business plan, slides waste the short amount of time you have on stage. Judges and the audience want to see what you were able to accomplish and build over the weekend. By the time you get through the slidedeck, you find yourself running out of time trying to showcase the demo. Avoid the slides all together and go directly to the demo! If you have time remaining after the demo, talk through the points you would have put on the slides.

Lastly, what happens on Monday morning? First, I sleep in! After all nighters, I crash before I get to eat dinner on Sunday. I wake up refreshed on Monday and start talking to my teammates. Find out about team commitments. Do you all have time to devote to making this a startup and really support customers when the going gets tough? It’s tough working a 9-5 job and coming home to do another shift building your startup. It’s not impossible to do, but some people decide it isn’t for them and slowly fade out of the picture. Set expectations to avoid misunderstandings.

Before you commit months of your life on the project, make sure there’s a market for it. Even though judges liked your concept doesn’t mean millions or billions of people will flock to it too. This feedback is an indicator you might have something, but you still need to do due diligence to see that this can lead to a business and success like an acquisition or a self-sustaining company.

I showcased some of my hacks which can be found on my travel blog and this blog. My DevPost profile also features a number of prototypes.

I ended my session by inspiring others to use the experiences they have along with those from people they meet. These experiences are what makes hacks unique and solve real problems. You just have to find an upcoming hackathon and jump in. You will find your passion and what you really like to do.

And in some cases, you can make a difference by inspiring others with proof of concepts you build at hackathons. I love to watch presentations at hackathons, giving me new ideas of things I want to try out and see what experience I can add to the concept.

Mention me on Twitter at @dothewww and let me know what hacks you come up with.