Debate the doubters

I am at a friends place right now. He also happens to be a beta user of Trici, the product I am building. He was explaining to me why my product would not work. He talked about the alternatives people could use. This was a good discussion. As the discussion progressed, I was able to convey to him why I thought that people would switch from the alternatives to using Trici.

When the discussion started I was not so sure footed. His arguments and points made me think. I did not come up with anything new. But I analysed my hypothesis against the arguments presented. And after a lengthy discussion came to the conclusion that the hypothesis still holds. Its yet to be proven though.

But this discussion reinforced my belief that Trici is solving a pain point. It motivated me to work faster to prove my hypothesis. 

Getting back to writing

I have to admit, I have lost my skill to write. Tweets I can write, but long form... That is another story altogether. Someone suggested that I should write on Medium. I have to admit, I like the interface of medium better than that of blogger. But after the recent post by Evan Williams announcing firings at Medium and getting their focus back on figuring out a business model that does not involve advertising, I felt I should just stick to blogger. Blogger is not going to go away. 

If you think what I am writing is shit... Yes, well I am out of practise. But to get back to practise, I will have to start writing something.. Even if that something is shit. I hope to be more regular on this blog.  

What happens when you ship something you are embarrassed of?

You must be knowing the famous quote from Reid Hoffman:

(pic credit: startupquote)

What happens when you ship something embarrassing? The fact that you are embarrassed means that you have an idea about what it will take for the product to be not embarrassing. Fix these edge cases, polish that UI etc. But when you put an embarrassing product in the hands of someone, your list of embarrassments gets prioritized.

And then you know precisely in which order to tackle the embarrassments. 

Sharpening the Axe!

One of the biggest dilemmas that every team starting up from scratch faces, do you invest time on things which are not getting you any learning about the problem that you are trying to solve and what the customer thinks. Over the past few months, time and again I have come face to face with this dilemma. Today, I was pondering over the choices I made and whether there was any consistency in choices. In retrospect, there have been a few mistakes, but there have been some good decisions as well.

Mistake #1: UI/CSS Framework

When I started work, my choice of CSS framework was Bootstrap. It was something I was familiar with, had good documentation and was used widely. If I would get stuck somewhere, the probability of finding an answer on stackoverflow or elsewhere was higher since so many people use bootstrap.
Instead of customizing it from scratch, I could use a freely available and customizable template. This is exactly what I did in the beginning and used the same bootstrap template in the desktop app as well as the landing page of the website.

This was a choice I should've stuck to. However, I came across a situation where I was looking for a particular UI component in react and did not find a good one which was using bootstrap (Looking back, I feel the perception of what was good was flawed.) Material UI seemed to be the rage, but in my quest to be different,  I ended up trying WinJS.react and Winstrap. This is an example of one of those classic mistakes which one makes when working alone. This was so obviously a bad choice, yet somehow I made it. Its not that I had to redo a lot of stuff. I wasn't very far in my project and the time I lost due to this was probably less than a week. But that IS A LOT OF TIME! In the end, when I came across Materialize.css I chose that and have been happy with my choice. Material design guidelines on color etc mean that my app does not look completely amateur from the design perspective.  But I do feel that sticking with bootstrap, I would have been able to get the app in the hands of the first five users quicker.

Mistake #2: Not resolving Webpack issues

Webpack is quite awesome! But to get a feel of all its awesomeness there is a learning curve. The reason I wanted to use webpack was because in my code I was using all these bleeding edge Ecmascript features which are still TC39 proposals, e.g. async/await, import etc. Thanks to Babel, this is possible. However, there way people have suggested to use Babel in Electron is to let the transpiling happen at runtime using babel-register. I continued with this approach because it resolved the errors I was getting. However, this meant that even for the most simple css change in one of my react components, I had to rerun the whole electron app.  The time taken for the app to start itself was getting larger, due to all the runtime transpiling happening every time.  What I wanted was Hot-Module-Replacement to save on the time which I was losing every time that I ran the app. Also, transpiling during runtime would make the MVP too slow on startup and was not giving the feel of a native app.

I tried integrating webpack and failed due to an error which I could not resolve nor could I find a solution on the internet. Worried that this was delaying getting the app into the hands of the first users, I let that branch of code remain and continued work on other features. I got back to that branch and fixed the issues after a full 30 days. Today, I got hot-module-reload to work as well and I can see just how much time would have been saved if I had fixed the issues earlier.

Good decision #1: Integrating flow-type and refactoring code

I did end up spending a month or so refactoring the code to use flow-type and Immutable.js. However, as the code has gotten more complicated, the investment in implementing these technologies has paid of by time saved catching bugs/errors which would have otherwise taken a lot more time to find and fix. At this stage, I have not implemented any automated testing, as that seems overkill for the MVP. But I will get to those very soon.

So the last few months have been a mix. I do sometimes get criticism that I have not followed the philosophy of "The Lean Startup", something which I myself advocate fiercely to others. My explanation for this has been that I am solving a pain point which I have. There is a minimum that I expect from my app before I give it out to other to try. Perhaps my perception of that minimum is biased, and I could have gone more minimal and learnt first hand from users. But from time to time, I have shown the progress to some of the first five users and the response has been positive. By positive, I do not mean, "Oh you are doing good", but "Oh I want that" Real feedback will only come once the app is in their hands.

I was speaking to an ex-teammate who, along with a few other ex-teammates, is working on his own startup. He was narrating how they have slowed their initial sales push because they need time to incorporate all the learning from their initial customers into their product.

I expect a tremendous amount of learning once I get the app in the hands of the initial users. Once all that feedback starts to come in, I will have to move fast. The time invested in setting up things like webpack-hot-reload or flow will pay off by allowing me to move at a faster pace when needed.

The key takeaway thought which I had today was something which I have had for years now. Invest time in sharpening the axe.

Keep Calm and Debug!

Programming is exhilarating. From imagining how you want a program to behave, to actually getting the program to behave in the way you want, is a journey of highs and lows. In the end, when you have the expected output, it does give you a high, a feeling of satisfaction. There have been times when I was feeling slightly depressed/low but felt much better when I was able to find and fix a bug in the code. At other times, I have gone from being energetic and happy to slightly depressed/frustrated just because I got stuck somewhere and was not able to get things to work as I expected. Depending on how other factors are playing in your life, programming can be an emotional experience.

When I was a younger, relatively inexperienced programmer, the frustration would come out on the computer. The choicest expletives were hurled at the computer because it would not work the way I wanted it to! "Why doesn't you work the way you are supposed to, you @#$&#$#@$*&!"

As I became more experienced in programming, I became cognizant of my emotional reaction in such situations. A computer is always going to work the way it has been programmed. If something isn't working, its probably because I made a mistake. Some times, the cause was not reading the documentation of a library properly. At other times, it was encountering a new way of doing something. I may have never come across this approach before and thus my mind was resistant to learn a new way of doing something. By reacting emotionally to such issues, I was taking the focus away from the core issue. If things are not working, then someone has to be blamed and who better than the computer.

Over the years, I have become more calm, collected and rational in how I approach such issues. By being cognizant of the fact that it is more likely that I made a mistake or misunderstood something, I can keep my emotions away and calmly analyze the situation objectively for what are the possible mistakes I could have made. I have noticed that when you are calm and objective, error messages seem to make more sense. Thus keeping emotions in check helps in being a better programmer.

Apart from keeping emotions in check, another thing that I have noticed which helps in being a better programmer is to think what is really happening behind the scenes. Over the years, as I developed a better understanding of how different systems/libraries work, I feel I have become a better programmer.

How? I now try and narrow down the root cause of the issue as much as possible. Very early in my career, I would just try various solutions which I found online. I do that even now, but to a lesser extent. I try to lower the amount of guess work that I do and try and think logically about what is going wrong and where. The reason this is important is because you also lower the chances of introducing new bugs. Something was not working, so you guessed and changed something. Still not working. You changed something else; still not working. You found a bug and fixed it. Still not working. What!? But you just fixed the bug!

Yes, but you introduced new bugs due to the two changes that you tried which did not work. So your program still does not work as expected, even though you found the bug which was originally causing it. By eliminating guess work, you probably would have found the original bug earlier and not introduced the new one.

This is something that I also told the younger team members at Babajob, when they would throw up their arms in frustration when something didn't work the way they expected.

So , Keep Calm and Debug!

Why you should not hide your idea

Talk about your idea, your product, what you are working on to anyone who is interested in listening, even your mom.

Everytime, as it explains the idea to others, the mind is not only trying to convince others, it is also trying to convince itself.

An objective mind is one which sees flaws in the arguments it is making, even though the arguments may have convinced others

Mostly, these flaws reveal themselves when the mind identifies the many more variables involved when calculating trajectory to success

With the variables identified, they are incorporated into your calculations and you come up with hypothesis to prove that the equation works

Some more thoughts on the past few months

As I have recapped here, one of my primary objectives after leaving Babajob was to make myself comfortable in using a tech stack other than Windows, as well as learn Android development. The best way to do this was to build something small but useful, something which I felt was needed by people and they would use if it was built for them.

Of the many ideas I had, I started with Tweet Smart because I sensed there was an unmet need for such a utility. On twitter, I had come across several instances of people starting tweet storms and numbering the tweets as 1/n,2/n.... and then finishing the tweet storm by revealing in the last tweet the value of n. You can search twitter for "1/n" and you will find that there are people every day who tweet like that. I myself had wondered how did some people, or specifically @JP_LokSatta, compose a series of tweets which were numbered perfectly. I tried to do so myself and felt it was not an easy thing to do, which explained why many more people were numbering tweets as 1/n, 2/n... Thus, my hypothesis that there was an unmet need and if I built something that met this need then people would use it.

With this hypothesis, I started work. In a Lean Startup, the primary objective would be to test this hypothesis as cheaply and quickly as possible.  But my primary objective over here was to learn a tech stack and perhaps build a public portfolio of small hacks/products which would help others evaluate my code and the way I thought about products. At the same time, it was important to finish one project completely and rather than have multiple ideas as work in progress. For example, another idea which I thought I would ship was to build an app which alerts me when a Groupon becomes hot, i.e. it is bought by a lot of people in a short span of time, or a simple Math game which I have in mind. But having a 1000 users install and use TweetSmart would be more valuable to me than to have built two apps/services which no one was using. Thus, while I have been tempted from time to time, to pick up other ideas, I have resisted such temptations and stuck with TweetSmart for the time being. If my hypothesis for TweetSmart is true, then how many people can I get to install the chrome extension? 100, 500, 1000 or more? How many TweetStorms are people going to compose using my service in a duration of 30 days? Answers to such questions intrigue me more at this point of time rather than building newer apps/services. Thus the primary objective of learning new tech stack/android development had to be achieved within the constraints of the secondary objective : iterate on a single product/idea and build something that people use.

With this perspective in mind, I spent more time learning technologies rather than just validating whether my hypothesis was correct. For example I spent time building a Chrome extension, a website as well as an Android app for the same use case. A reason why I did this was to break out and do something new when I got stuck. Working alone can be monotonous and a challenge if you get stuck. Learning new skills such as Android development kept me engaged and made me feel I was making the days count, even though I was stuck on the  development of the website due to some stupid mistake. But I did not start work on any new ideas.

The website was something which I finished first and released. By release, I mean tweet about it and send an email informing some friends to check out what I had made. But it was far from ready to be publicized because of some obvious bugs and deficiencies. I was solving my own pain point, and I felt that my solution, though a step in the right direction, was incomplete.

The correct thing to do at this point would have been to continue work on the site and finish some of the features I felt were necessary for this Minimum Product to be Viable. However, I decided to get the Android app as well as Chrome extension to the same feature parity. The argument I had for such a decision at that point was that users were likely to forget the name of the site and not come back, making something like a Chrome extension attractive as once it is installed, it is easily accessible. In hindsight I am not sure how well does this argument stand. It is in instances like these that I feel better decisions would have been made if working with a team.

Anyway, I worked on the extension and shipped what I felt was a suitable MVP. I felt that I could now publicize the Chrome extension and indeed did so to a few strangers as well as people I follow on twitter. Two people to whom I tweeted about the extension, favorited the tweet. However, they did not install it. Since Chrome extensions cannot be installed on a mobile browser, I wondered if that was the reason. Thinking that to be a highly probable reason, I decided to focus on the mobile site rather than the Android app. While building the Android app would add to my portfolio, I felt I could delay that slightly and focus on getting people to actually use what I had built.

In the past few weeks, whenever I have had the time to work, I have focused on bringing the mobile site to the same MVP feature set as the extension. With the Chrome extension and now the mobile site as well in a much better shape, I am confident of going ahead with publicizing the extension and site and check how do people respond.

I also took some time to reflect on what I would do differently if I were to do a similar project in the future. I would share those thoughts in another post soon. However, I am quite certain that working absolutely alone is not very productive. Thus I am going to be actively looking for opportunities now, something about which I was rather passive in the past few months.