Leave The Detail

A couple of weeks ago I gave a short talk on my Facebook’s F8 Hackathon experience. Even though it’s been two months since then, the experience left me more ambitious and opened my eyes to see what can be possible with technology around me; from the very simple to the more interesting and challenging tools, which is the core lesson I took from my Facebook experience.

As numerous posts on Medium with similar experiences here and here point out, finding out that you have been given an opportunity to go to the United States, to be part of an event that lets you try out your ideas and to possibly win a grand prize of $15,000.00! And if you don’t win the grand prize, there are still prizes for your participation in the competition. I hadn’t seen anything like it before!

As a developer I often used to run to the IDE to try and execute an idea I would have been mulling over during my free time. I would forgo sketching the idea on a board or sketch pad with perhaps a basic flow that highlighted functionality. This is something common in a team during some sprint planning session. The end result would see me getting bogged down into the details of the implementation (say an Android app.) such as:

  • What libraries to use? (RxJava vs Architecture Components) for example.

  • Manual Dependency Injection or use Dagger2. 

  • What architecture to try out? MVVM? MVP?

The list would go on and on. What was supposed to be a “hmm this idea could possibly work” turned into debugging why this basic app, with hardly any UI was failing to compile because of some obscure Dagger issue I had. As you may guess, a lot of ideas fell by the way side. I had read articles in the past, but I suppose I always fooled myself into thinking that “it wouldn’t take too long” or “This would be a cool time to test this out”, rather than testing out the theory before experimenting with anything else. Needlessly to say, very little ideas, if at all, were executed.

F8 then came along and with that I met an awesome talented team of developers from all around the world. Our idea was a video platform that dealt with serving the availability of 360° videos. You can view our project here.

The Team was amazing, consisting of developers from Toronto, Los Angeles, New Delhi, Bangalore and myself from South Africa. The planning session got me to reminisce about all the subpar planning I had been doing all along for my projects and how it was supposed to be done. Within an hour we had designed our entire tech stack and had a rough outline of how this POC was going to be built. A few of the questions we asked ourselves were:

  • What our backend and front end would consist of?

  • What our ML technology would be.

  • How we planned things like user authentication

  • How we would consume the Facebook Graph API for checking user info and ultimately subscribing them to the backend.

The entire process had us coding in under 2 hours since the initial “START” command we were given, and in 48 hours we had a working, slightly buggy idea that we were able to demo to the judges. We unfortunately did not win, but the learning experience of being intentional in taking the time to plan what you’re going to do for your app, from a highlight reel perspective before rushing to the IDE was one of those things I will always hold on to. Definitely one reason being if we had all rushed to the IDE before planning the project, I doubt there would have been any direction in the way we put the application together. Sure we had some things change along the way (We had numerous issues with the ML part for example, calling in Amazon experts that eventually helped us in the end)

It’s easy to walk into any corporate meeting room and be the developer that gets given the work and all you have to do is fire up your IDE, get going once all the sizing of the work is done and with all additional politics ironed out. I think one of the reasons I miserably failed at planning is because as a developer I’m left out of the concept phase of a lot of meetings and am used to getting instructions given at the very end (a blog post will cover this particular subject later).

The fact is that a lot of us developers out there have tons of ideas, but because we often may lack the necessary creative phase of planning something from beginning to end without getting too obsessed with the detail; which is what we really love and enjoy. Thereby leaving a lot of potentially untapped ideas that could really change the world. It doesn’t have to be detailed with what dependency injection library we need to use or what npm modules do the best jobs, we just need to at least answer two questions before going any further:

  1. Will it be able to do what I need it to do right now?

  2. How quickly can I learn and implement this?

From then on, the highlight reel of what the project looks like slowly comes together until you need to build something that works and in the end, if your idea works out to be a successful product or service, then you can start worrying about tools. Further to F8, I was also inspired by the two sources below:

  1. A friend of mine, Tsatsi Mahase once told me “If you have too many users on your platform/service/whatever and it keeps crashing, then that’s a great problem to have. Right now you have no users – and you need to fix that first.”

  2. A quote from Oliver Beattie from Monzo once said in his YouTube talk: “always plan to throw away your first.”

And with that, I walk away with a priceless lesson and an additional skill.