Teen Developers – Rohan Kapur

My apologies for our last interview, as it came out a little later than we were hoping. You may’ve noticed it wasn’t posted by me; Life’s had me busy, but I’m sure this week’s interview will make up for it! So my thanks to Rohan for such an awesome interview!

Teen Developers   Rohan Kapur

Rohan’s Workspace

Could you start by telling me a little about yourself?

Hey, my name is Rohan Kapur. I’m an avid computer scientist, musician, and High School sophomore, currently living in Singapore.

You’ve gotten to attend WWDC before on a Student Scholarship. What was the application (pardon the pun) process like for you? What did you gain by attending the conference?

Yep, I have! The application process was nerve-wracking, stimulated by time constraints and somewhat vague instructions. When I finally clicked the Submit button, it was a huge relief! I received the acceptance email in Chinese class, and it was certainly the most triumphant moment of my life. Attending WWDC was always on my bucket list – I even sent Steve Jobs an essay in 2011 on why minors should be able to purchase a ticket! At the conference, I made many friends, enjoyed San Francisco, achieved some Apple fanboy milestones (including watching new products announcements, and meeting Apple execs), etc. Most importantly, however, I made connections in Apple and the developer community. I think networking is the underlying principle of any conference, and if there’s one piece of advice I’d hand out – make connections and exploit them, because you never know when you’re going to need that person’s business card, but you’re going to need it eventually.

Before developing iOS apps, had you done anything previously programming-wise?

No – learning to make iPhone apps was the first form of programming I did. Only years later did I branch off into other fields like web and backend development.

I see one of the apps you’ve made is called Travelog. Where did you get the idea for it? What was your biggest struggle while it was in development?

There is a major backstory to Travelog, and in this paragraph, I’ll do my best to condense it. Travelog was my first personal project…. sort of. My Dad actually pitched me the idea of being able to index your flights for tax purposes, and in 2011, I made MileIndex. That was my first “app” on the App Store. You could record your flights in a simple list view, export them, and access statistics eg. miles flown. Soon, MileIndex developed into Trvlogue, which was a more sophisticated version. It stepped up it’s game in terms of features, design, and usability. You could now check out relevant information on your destination, including latest news, places of interest, weather, etc. Shortly after, Trvlogue turned into Travelog. If MileIndex was the start of the marathon, Trvlogue was around 21km in, and Travelog was the finish line. I felt a compulsion to make it into something legitimate, that actually looked professional, and had advanced uses. Little did I know that usability would end up paying a huge cost.
The goal for Travelog was to exponentially improve upon the established idea, design, and feature set of Trvlogue, to the point where it didn’t look like a teenager made it. This was all while adding a social networking element that allowed you to check out which of your in-app connections are flying to the same destination that you are. This is actually something my Dad constantly complained about, he was sick and tired of posting “Who’s gonna be in Manilla next month?” to his Facebook. So, I decided to include it in the final iteration of my travel app. After a long time, I eventually launched the buggy app to the store, and decided to stop pursuing it. Here’s what happened along the way:
  1. Major Burnout. Travelog/Trvlogue/MileIndex was never an idea that appealed to me. It was an idea that appealed to my Dad. I just wanted to make an app. But soon, I felt that I needed to refine on each version of the app (MileIndex -> Trvlogue -> Travelog), and I fell behind in many departments. I didn’t have much enthusiasm for the concept, and working tirelessly on it, while yearning development of another app (Contra), made me bored of programming as a whole. It made me unproductive. Eventually, however, I released it.
  2. Legacy Code. Each time I worked on a new version of the app, I ported over a lot of code that already worked. This meant that Travelog had code from Trvlogue, or worse, from MileIndex. This was code I wrote as a programming newb, almost originating 2 years prior. I found myself rewriting blocks and blocks of code, after discovering they were producing major bugs and memory issues.
  3. Lack of Knowledge. Some of the legacy code involved downright bad security principles and practices like saving private data to a public space. I had to spend hours learning about this stuff before I could implement it. But that’s not all – I wanted to create a social element to Travelog, as I discussed before. I didn’t know anything about backends and web, nada. I started off by using Amazon’s AWS iOS SDK, and eventually settled on Parse. Neither require development of a backend) but even then, it was a steep learning curve for someone who had only dealt with offline data.
And so, trying to achieve all these things, the project spun out of control. The codebase was a huge mess, plagued with bugs, crashes and glitches. At the end, I just published it to the App Store, and let it be. Travelog was a failure, and I learnt so much from it. It taught me new technologies, but most importantly, it taught me practical approaches to project development, including to never again be compelled to perfect something, because it can kill you. Accept that stuff will suck at first, and be open to fixing it later. Draw the line when building your product, and don’t add too many features at once. Keep it streamlined and focused, but expand later.
You’re also currently developing an app called Contra. Could you tell us a little more about it? Have you encountered any roadblocks while working on it?
I’m very excited about this one! Contra is a social debate platform that allows users to publish two-sided controversial topics eg. “Is racism against black people still prevalent in the US today?”, “Is God a viable theory, considering the Universe is such a mystery?”, etc. People can vote on these topics, post and discuss their viewpoints, and argue against other people. The idea to build the app sparked after I found a passion for arguing against other people on the Facebook comments of tech articles. I thought… there’s gotta be an app for this! Well – the answer (believe it or not) is no. There is a website called debate.org – but a complete absence of mobile presence. And mobile’s the way of the future! So around Jan 2014, I set out to develop Contra. The major roadblock I experienced while developing Contra was that I needed to learn how to build an entire backend system. I had no knowledge of how to build a backend. I had worked with Parse before on Travelog, but that wasn’t going to fulfil my needs for Contra. So, with the help of my friend Lenny Khazan, I literally went out and learnt how to build a backend. I watched videos on HTTP, read articles on REST API architecture, server management, deploying server-side code, familiarized myself with Node.js, yada yada. After a few weeks, I started work on Contra’s Node.js backend, and Lenny helped me along the way by reviewing each iteration of code.
If you had to give advice to someone about how to overcome struggles while making apps, what would that be?
There are so many struggles you can face while coding, eg. a lack of ideas, inability to fix bugs, burnout, and even struggling to fathom the logic of programming. Here’s what you should do:
  • Outsourcing work to others – not everything has to be done by yourself, and being able to work with others and integrate outsourced work is an extremely important skill.
  • Finding deficiencies around you – look for nuances in your daily routine, someone else’s, or the general public’s. What’s missing? Is there something you can do to optimize time, or make a task easier? Can you build some sort of software to do this? There’s an idea.
  • Don’t give up. I believe that to succeed in programming, you’ve just got to not give up.
  • Give it some time! Bugs can be hard to fix. I know this. Spend some time looking through the code, add some debugging logs, comment out potential suspect offensive lines, scour the Internet, ask a few questions to some online forums, etc. Try to be independent about it, though. When you are forced to solve problems by yourself, you can fix many other problems with established approaches later on. It may take time at first, but that time is earned back later.
  • Never try to perfect something. Ship something that works well, but is not necessarily perfect. It can always be refined later. You need to first see that people will actually use your app.
  • If you are burned out, change what you’re working on, and move on before it gets worse.
Anything else you’d like to add?
Actually – yes! Contrary to a lot of people’s beliefs, I don’t consider software programming to be my area of main interest. I would love to study (and am already delving into) theoretical Computer Science, which is essentially an intersection between Math and logic/problem solving, with programming being a practical component. I’m most interested in Artificial Intelligence and Big Data, and would love to pursue a career in either field.

As always, feel free to contact Kaleb if you’d like to be featured. Posts come out Thursday mornings every two weeks.