Its been a while...

A thing that I noticed about myself recently is that I have become a consumer of content, but I hardly spend any time producing content. This blog is of course, not "content", but it used to be an outlet for my thoughts. 

I was thinking the other day how I have become a very different person from who I used to be. In some ways good, in some ways bad. Some of it is just aging. Some of it is just circumstances. But some of it is just bad habit and lazyness. I had an urge to rediscover some of the habits that I used to have and one such habit was blogging. Writing down my thoughts, on anything. Just go through the motion of writing. 

And given that I have learnt touch typing, I thought let's give this a shot. Lets write something everyday. 

Hitting Targets

In any company, however big or small, one is always chasing targets.

Sales teams are chasing sales targets, engineering teams are chasing shipping targets.

If your startup is consistently missing targets, that is a sign of an underlying problem. Could be lack of product market fit or insufficient number of people on the team.

Focus on hitting targets. Start hitting targets. Get into the habit of hitting targets.

This weekend I again missed hitting a target I had set for myself. Some of it was to do with the fact that I faced some issues as I updated the node modules of the project. But surely not all of it.

I should think about why I am not following my own restrictions.

I am right now reminded of the penguins from Madagascar and their skipper saying. "Don't give me excuses, give me results"

In reality, I am completely burnt out.

The question is, what other option do I have but to carry on.  

Back to writing

As I published my last blog post, I realised I had not written anything in 2018.

Yes, that sums up 2018.

2019 should be different for the one reason that I am learning touch typing and have become slightly faster and better at typing.

I started writing a design brief for an intern that I am looking to hire. The process of writing reminded me of something that I had forgotten. How writing helps one think through the issues at hand and where to focus on.

Hopefully this state of mind continues. I have vowed to write more often earlier as well but never followed through.

Mind games

The odds of success survival of a startup are very low.

The odds of survival of a startup with a solo founder are probably lower.

The odds of survival of a startup with a solo founder and no team members, also dealing with issues on the personal front are probably zero, or almost.

Every day I get up, one part of my mind reminds of these odds, the time that has gone by and how these odds have not changed but probably gotten worse. How a year has passed and I still don't have answers to questions.

Every day this part of my mind tells me to let it go for now. Join a job take a break from entrepreneurship. A break will do me a world of good. Figure out and settle other questions that occupy the mind space

Tempting..

But then the other part of my mind reminds me. I did try to settle other questions that occupy my mind space but despite my best efforts, they remain unresolved.  What I have is time wasted trying to answer those questions. Time which could have been utilised answering questions that my startup faces. So yes, the odds are against me, but it is the small actions that one takes each day that change the odds.

So yes, for me every day is a battle between that portion of my mind that reminds me how badly the odds are stacked against me and that portion which says, yes the odds are stacked against you, but your action today will change the odds in your favour.

 Keep at it.

Let's see how long this lasts.

The One Metric

In a conversation today, I said the biggest plus of YC SS was the weekly office hours, which got one to focus back on whats important. But as I was reflecting it over now, I realized that the first thing YC SS did was to make you identify the one metric that needs to grow.

This simple step in itself is so important. Identifying this will drive what questions you ask users, what information you seek out of them. Basically, it will drive the direction which the iterations of ur product take. Overtime, as you learn from users, either of 2 things happen. You realise that you are measuring the wrong metric or your metric should start improving.


While I am building Trici primarily for developers, many have noted that it can be useful for other use cases as well.The beauty of the one metric is that whatever the use case, it still accurately indicates the health of your product.

Convenience and Choices

Convenience plays a big part in choices we make. Given a choice, one would by default choose something that is more convenient/cheaper etc. This should make choices simple and it does in so many cases. But as we know that is not always the case. Sometimes bad choices disguise themselves with convenience and we make a mistake and learn. The tricky part is when you have two seemingly good choices. On the surface one seems obviously better than the other and while there is a voice in your head which is still unsure, you make the choice that seems better. As time passes, the voice in your head grows a little louder. You obviously made the right choice so why is the voice in your head still there.

This is because the seemingly good choice seemed better only because of convenience. In fact, if you remove the element of convenience, what seemed like a good choice may not even seem like a choice anymore because that is not what you really wanted. This becomes even more interesting because it is not always clear what you really want. Which is why advertising is such a big industry. When you see something everyday, it gets programmed as a want in your head.

If there is a voice in your head it is worth thinking why its there.

Trici You Beauty!

I am using Materialize CSS library for my product. Just now, I was doing some minor changes to the UI of the product when I noticed that some of the styling was not working as documented on Materialize site. I then came to the conclusion that this was because I had not updated my Materialize css build to the latest one, so I decided to go ahead and update.

I downloaded the SASS build of Materialize which I would then customise as per my requirements. Over the last year, I have customised the css as and when needed, but realized in December that I need to have a custom SASS build rather than just a customised css file. So I had downloaded the SASS build of materialize and then incorporated all the changes I had done over the months in css to Sass by going through the diff of changes, git commit history etc. This took some time but now I had a customised Sass build.

I checked this in a separate repo and used it to build a new dist folder with the customised css, js and fonts. And henceforth any changes needed were made to the Sass files, a new dist created and then that dist used in the actual react app. This was fine till today when I noticed that I need to upgrade the Sass library itself. This meant I would have to and do all the changes to Sass that I had done earlier in December.

With a sprained neck, and a fucked up sleep cycle, I was totally not in the mood to do these again. There is so much work left to do, and the realisation that I have to do all of that alone really made me wonder what am I doing with my life. Is what I am building even useful? Usage of the product has been going south for many of the initial users. There are some positive signs but when you are demoralised, glimmers of hope are not sufficient.

With this state of mind, I made myself some tea and sat down to do the changes, pushing myself to keep moving. If only there were a tool which would make this easy for me. And then I opened Trici and searched through the Focus Sessions for December 23, the day I had initially made the changes to Sass files. It turned out I actually had a Focus Session where I had captured what changes I had done on the Sass files. I had searched earlier but must have missed this one. Suddenly, what seemed to be something that would take time was achievable in a matter of minutes. I knew exactly where and what changes to do .

And then, the demoralised me was all of a sudden upbeat. Just when I was doubting whether Trici was useful, its utility presented itself to me.

I don't know whether Trici will go onto be a successful business, but I am sure that it will definitely make lives of developers much easier. And thus, I am going to open it beyond the small set of private beta users. 

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.

Reflecting on the last few months

In the week gone by, I finally published a version of the Tweet Smart Chrome extension which is visible to the general public. On hitting this milestone, though a bit late, I ended up reflecting on what was the progress in the past few months and whether I could have saved time by doing things differently. The fact that there doesn't seem to be many people enthused by the extension made me question my own judgement and made me wonder whether I had built something that people did not want. I keep professing The Lean Startup principles to everybody, but here I was with a tool that not many people seemed to be enthused about and I spent a considerable time developing it. Couldn't I have just learned that without all that coding?

I have a terrible habit of questioning everything, including my own judgement. It is a trait which became a habit when I first started out on my own. Life is inherently uncertain, but living in a relatively secure and certain society, one's instinct to question the way things are weakens and gives way to an instinct of assuming. This works well when one is on a relatively well trodden path. But the moment you plunge into the sea of unknown - with the knowledge of the destination you want to reach but without any idea of how to get there - this instinct of assumption gives way to an instinct of questioning and inquiry. Because as time passes and you try and measure your progress, you invariably find that you have no idea whether you are heading for your destination or just drifting along. The metrics and principles to measure progress in the environment of uncertainty are different.

Back in 2009, as I quit and started on my own and as time passed, I started to realize the many assumptions that I had about how startup life would be. I have previously blogged about some of my epiphanies such as here. Even before The Lean Startup became the movement that it is, I came across the idea and latched onto it as it provided a very good template of how to think, understand and evaluate in conditions of uncertainty.

Anyway, as I questioned myself about my endeavors for the last few months I came to the following conclusions:

1. The idea to build tweet smart came as I saw that a lot of people number tweets in their tweetstorms as 1/n,2/n etc without knowing in the beginning what that n would be. When I released the chrome extension to the general public, I did that by tweeting about it, sharing with a few friends on email as well as posting on the notcrud.com community. The feedback from friends who used it was positive. But given that there are only six users till now made me feel that I had built something that people did not need. However, still doing a search of tweets containing "1/n" I found that there were a few people who still tweet that way. So the need seems to be there, but perhaps I have reached out to the wrong set of users. Or maybe its too early to say that what I build is not needed. I need to reach out to more people in a targeted way.

2. I suspect many people would be accessing twitter on their mobiles so perhaps it makes sense to finish the android app and then reach out to people. I tweeted out to 3 people who had numbered their tweet storms as 1/n but did not get a response from them. It could be because I told them that I had built a chrome extension which is not very useful if you are using an android app. Of course it makes me question whether switching to the android app just to number your tweet storm would be an acceptable proposition for people.

3. The central goal behind building this was to learn new technologies. I had never built a chrome extension before. Neither an android app. And had never built an end to end product while using linux. While this certainly is not an end to end product, I can say that I am now much more comfortable using ubuntu than I ever was and can approach a team working on these technologies with a certain confidence, which was lacking a few months ago due to the years of working on .NET and Windows.

4. I chose React to build out the extension as it's the new rage. And rightly so. I loved it. But as my aim was to build an extension and an android app, perhaps there was no need for me to build the feature to run on a website as well. To do that I wasted time to get it to work by building remote api's using Express. However, as the code of the extension calls the twitter api directly, there was no need for me to build the remote api I built. At Babajob, I would have questioned and stopped something like this if my team was taking this approach. However, working alone, I got did not critically analyze my decision and just went with flow, which was a mistake. It was waste in Lean Startup terms.

Anyway, the extension is published in the Chrome Web Store. I have set myself a target of 1000 installs by mid January. One of the toughest things to do when you build something is to take it from Zero users to a certain number of active users. That means you really built something useful. My hypothesis is that I can do that with TweetSmart as I feel it solves a pain point.

In my first startup, CATNINJA, I got around 450+  people to install the facebook app that we had built in a span of two months. We were largely able to do that because of people sharing to their wall from within the app and we got people to use the app by using FB ads. That was back in 2009. At Babajob, when I joined in 2011, the company already had a decent traction and people using it.

Thus, I have had this feeling that I have not yet experienced how to grow from zero to 1000 users (I chose 1000 as a threshold because by that time, I expect there should be enough people giving feedback on how to improve your product.) So I look forward to go from zero to 1000 and experience first hand the pains when doing so!

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!   

An idea for Grofers

I just got an order delivered from Grofers. It was the second time that I used the service and I already know what I like about it the most. It makes me feel less guilty.

No, I am not the fat, lazy husband that they depict in their ads, feeling guilty about not contributing to the household work. I am an individual who is conscious about the excessive use (or should I say abuse) of plastic bags in our daily lives.

I generally try to avoid using plastic bags as much as I can and am mindful of when I end up asking the shop for one. Most of the time, it when buying groceries that I end up asking for a plastic bag. I have thought about why this happens and it mostly happens because most of my grocery shopping is unplanned spur of the moment thing, which is why I am not always carrying my own bag when I end up at the local kirana store and end up asking for one.

With Grofers, the spur of the moment shopping happens on the app rather than going to the store. And they deliver the goods in nice environment friendly bags. So when the bread and eggs they delivered today did not come in a plastic bag, I was happy. The one use case, the spur of the moment grocery shopping, where I invariably ended up using plastic bags, now had an alternative user experience where I could get what I wanted within a reasonable time without having to use plastic bags. I used the term user experience because from a design perspective buying from an app should be as friction less as buying from a grocery store.

However, as I emptied the environment friendly Grofers bags, I realized that I already had the couple of bags stowed away from the last time that I ordered and that I really did not need the bags from the second order. It made me wonder, why does Grofer not take back the bags and recycle/re use them. I mean the delivery guy is right there and I could have handed it to him. Environment friendly is not simply less plastics but also recycle and reuse. Perhaps, Grofers could hand out reward points to customers who return bags and thus encourage environment friendly behavior.

A Developer Switches from Windows to LAMP Part 3: Project Dagobah

The best way to learn any new language/platform/library etc. is to get your hands dirty playing with it. Build something useful , not merely a todo list, but something similar which has a utility, yet does not have a large scope in terms of use cases. But do it end to end: i.e. don't just have a working version on your development machine, deploy it to a server and make it readily available to the whole world. 

In April, from among the many ideas that I had, I chose to build a tool which would help you number your tweet storms. Even this phrase "number your tweet storms" is a result of multiple revisions. I did not even know what a tweet storm was back in April! Of course, there was a massive and a much needed break from mid April through May as I went back home for my sister's wedding and then went on a trek to the Himalayas. So I really started work on this in mid June after I was back in Bangalore. I will write in more detail about how I went about developing it, but right now I want to announce the first release of TweetSmart. As of today, it is only a web application. But very soon I hope to have built it into a chrome extension as well as an android app. 

This post, however, was not meant just for the announcement of the release of the app. It is meant to be a high level recap of my experience developing and deploying my first app on Linux, or to be more specific, Ubuntu. 

I originally envisioned TweetSmart as only a Chrome extension. Thus I started with Getting Started with Chrome Extension Development. Building a simple Hello World extension was easy. But I now wanted to build the TweetSmart compose box and that meant a a lot of javascript code. An immediate choice I had to make was to choose a javascript framework such as Angularjs, Emberjs etc. to build this. Having a bit of experience with Angularjs I was inclined to choose Ember but had heard a lot of good things about React. I decided to spend sometime familiarizing myself with React and understand its benefits. In the process I learnt about Flux as well. The uni-directional data flow in Flux architecture made sense to me. I also read many posts by people who were astonished by how much cleaner their code was due to using React and Flux. So I decided to proceed with Flux+React and not get bogged down by trying to make the perfect choice of framework. 

Till now, the choice of Flux+React has nothing to do with developing on Linux. I could very well have developed this extension on a Windows machine while using React+Flux. However, the first place that the difference becomes apparent is the choice of the IDE. On Windows, I would be using Visual Studio. On Ubuntu, I had started to learn Vim and thought the terminal and vim are going to be all that I need to code. However, a very important aim while coding is to be fast - i.e. use tools and extensions for productivity. E.g. you can significantly reduce the number of keystrokes in Visual Studio by using code-snippets for common code constructs such as if-else, function(){} etc. I am sure expert vim users would know a way to do that in Vim, but as a newbie, it was taking me time. 

As it is important to ship the MVP as soon as possible,  I looked at options where the learning curve was slightly less. Interestingly, Microsoft had just come out with Code, a new code editor for all platforms, but since it was pretty new on the block I looked at other options - Atom from Github and Brackets from Adobe. Both of them are very similar but it seemed Brackets had a more active plugin development community with much more plugins, which made me select Brackets. 

I felt at home with Brackets and quickly started adding code snippets which I would use frequently, such as rcc for React.createClass. I also installed plugins such as Emmet and Beautify to speed up coding. However, as I later realized, since I was using React, the Emmet plugin did not prove to be very useful there.

Next, I wanted to set up a local web server and chose Apache over nginx for some random reason I don't even remember. However later on, as I was building an API using expressjs, I had to use node behind an nginx server and thus I ended up using nginx and removed apache. I did this on my local system as well as my production server, a micro ubuntu instance running on AWS. It was a nice change from using the Inetmgr to configure the IIS, though not without issues. 

As I realized that to integrate with twitter I would have to build my own api, the question of which framework/language to use came up. The options in my mind were ruby with sinatra and python with flask. But I had a conversation with a friend who suggested to go with node and expressjs. And I happy that I did. 

So that is a high level recap of some of the decisions that were made when using ubuntu/linux. These might seem very trivial to many, but for a person who has been coding using the IIS, Windows, ASP.NET and Visual Studio, these were new choices which took a bit of time to research and arrive at a decision. 

I am definitely now more at home using ubuntu, desktop as well as server. I have much more confidence that I can quickly get up to speed with a team working on a variant of the LAMP stack.  I can only get better from here. 

Upwards and onwards. 

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.   

Posting from Android

I dropped my Lumia for the umpteenth time and after months of working on a cracked screen,  the device finally gave up and stopped  responding.  As I am currently travelling,  I did not have the time to get it repaired and this forced me to finally do what I have been contemplating for months.

I bought an android device - Xiaomi to be specific. I am quite liking the variety of apps on the play store.  I am writing this post using the blogger app while I wait for a doctor at a Dehradun hospital. This is  also the first time I am writing a blog post by swiping rather than the usual typing. 

Posting to this blog via the phone might open up interesting possibilities,  perhaps leading to shorter but frequent posts.  We will have to wait and see.  For now,  I am excited that I finally have an android phone which I can use for  developing apps.  

My trek begins this weekend and I am really looking forward to it.  Once done,  I look forward to getting back to finishing some of the hacks/mini projects that I started.