Challenges when working alone on a new product

Working alone has its own set of challenges.

And by alone, I don't mean working remotely, where you are physically alone but connected virtually to your team. I am talking about the time when you don't have a team. 

Over the years people have talked about, and I myself have experienced it so many times, how explaining a problem to somebody else helps in finding a solution to the problem yourself. Interestingly, explaining a solution to a problem might also expose potential flaws that it might have. Which is why startups in stealth mode generally don't make much sense. 

As a programmer, being alone can be helpful. Quiet time without distractions is a factor which helps you get in the zone and/or help you stay there. But that is just one among many other factors. Having no one to talk to about what you are doing can inhibit your performance when the task that you are trying to do is something which you haven't done before and are learning for the first time. Its easy to get stuck and with no second pair of eyes to look at the problem, precious hours may be lost banging your head trying to solve what in the end may be a trivial problem due to a trivial mistake. 

Having access to structured information in such instances can be helpful. For example, I bought a Book on Android programming because one of the reviews on Amazon said that one could easily save 4 hours a day worth of time by just referring the book rather than searching for the best online resource. That struck a chord more than the 4 star review that the book had on Amazon. 

Distraction is another challenge and sometimes out of your control. The ideal thing would be design your environment to be distraction free, but that is not always possible. In the last one year, a technique that I have started following more and more is to write down or serialize my train of thought into notes that I write on Asana/Trello for the task that I am currently doing. By doing so, I have been able to reduce the cost of an interruption. I have made it cheaper to get back to work after getting distracted rather than trying not to get distracted at all. 

But today I noticed another challenge, where the fact that I was alone proved to be a handicap. I am in the process of shipping my first android app to the Play Store. Nothing too fancy, just a simple Android port of the tweetsmart.in functionality, which would be an easy way to familiarize myself with developing for Android. When you are building something like this alone, you are playing the role of the Product Manager as well as the Developer. This leads to very interesting conversations with myself. 

The Product Manager in me looks at app as it currently is and observes that we need to show the picture of the signed in user along with the user name, the way it is shown for the Twitter android app. The Product Manager in me also wants to ship the MVP in ASAP and thus asks the developer in me whether that can be achieved in a day. The developer in me thinks it shouldn't be too difficult, but is basically learning android from scratch so can't say definitively. He googles a bit and after an hour of research says to cut off that feature. The twitter api client that comes with fabric does not seem to have a built in way to get the User's picture. While it may be possible to get it by just calling the REST API, he feels the time will be better spent trying to fix the issue where the View is not refreshed after signing out. This dual thinking mode where I am arguing with myself gets to me sometimes and I get stuck in a rut, unable to arrive at a decision. 

I have faced this challenge before but I never saw it the way I saw it today. And I felt that with another member on the team, either of the two would have happened:

1. I would have figured out quickly how to get the picture to display in the manner in which I wanted. 

2. I would have decided to cut off that feature from the first release quicker.

But being a single member team currently, none of the above happened. Instead, I ended up writing this blog post!   

When learning something new

As a developer with some experience, many questions come up in my mind when learning something new. e.g. How do I write tests and automate builds? What are the shortcuts I can use to speed up my development? What are some expert level tricks that I can learn to churn out code faster?

However, it is important to realize that all of these things cannot be learnt in the first attempt itself. The goal should be to get the MVP out and not worry too much about learning everything there is to learn about the new platform/technology. That is because often, such information is not compiled and presented in one spot but is present at various blog posts, stackoverflow questions, google group threads etc. and one cannot expect to learn many of the tricks of the trade right at the beginning. It takes time and practise to become a master.

However, by not shipping the MVP a disappointing sense of lack of accomplishment/results starts to set in. This is very dangerous as this sometimes leads one to abandon the pursuit one had undertaken. And all the mighty tricks that one tried to learn on the way become useless and eventually forgotten, as one discovers when trying to take another shot at the failed project.

So, the right balance between learning and shipping has to be kept. Of course, I am assuming that one is working hard and that lack of progress in learning or shipping is not because of lack of hard work. But if you are in a dilemma, always err on the side of shipping. The motivation and sense of accomplishment that one gets after shipping can help speed up the process of learning as well.   

Focus

Take your time figuring out what is your next mission. What is the objective? What are you targeting? Know the constraints within which you work. Think about the calculated risks you would want to take.

And once you have a picture where you think you can proceed - START and FOCUS.

Weed out the things around you that distract you. Even though it may seem counter intuitive. Just focus on reaching your target.

You try and you fail - but the failure is the worst when you did not focus, because without focus you will not be able to identify the finer points that lead to failure. That closing of your eyes when the opponent hits a ball for a smash while playing ping pong, resulting in you always losing a point on smash. You missing plucking the 5th string while strumming the guitar, wondering why doesn't your strumming though good, doesn't quite sound the way you want it to.

You will identify these minute but important lapses, only if you have focus.

Otherwise, you can keep trying and keep working hard, but you won't make much progress.

So focus - try and repeat. Keep at it. You are getting better!