On coding

It is extremely rare to write code to solve a problem and be done with it. Problems are often half formed and coding at any point in time reflects your understanding of the problem at that time. Often you should move from complexity to simplicity in the way you solve a problem. The initial set of ideas to solve a problem most likely will be complex. The code you write will look complex. It will have data models that are hard to remember and connect in your brain. You will struggle every time to fix a bug.

The sign of using a debugger to fix a bug tracing through reams of routines is an indication of the complex answer you have given to a problem. If you have thought through a simplistic model, your brain can hold it. But it is difficult to arrive at a simple model when you are exploring a problem space. The reason is your brain is not yet familiar with the new landscape, the new symbols, the new lingo, the new data model, connections, and it is a struggle to fix things in that mess.

That is when you rethink your strategy. You have to have a simplistic path way to the solution. You rethink the concepts that you have formed. When the concepts that make the solution become clear as to what they are , why they are there, their functions and their limitations, their relations between one another, that is the time to recode. Throwing away large chunks of code and rewriting that in a way your brain can easily relate to is a great relief and saves a lot of time later. You can build on it more easily than working over complex piece of code.

Often you start with some simpler models about the problem but end up drifting into complexity adding more and more functions, overloading a class with lot more functionality, being more procedural to solve everything, than constructing simpler building blocks and clearly identifiable functions with each of them. This happens with time pressures, laziness to rewrite parts and the zeal to see the output.

Coding is a continuous process of going from complexity to simplicity in your mental model about the problem. You should not worry about rewriting whenever you sense fatigue with your current code. There is always a simpler and lesser way to solve a problem and you should strive to reach that point.

In this context, being object oriented helps. Reusing and extending on functionality to build a higher order thing is a great help. This should again be considered only to represent your mental model of the concepts rather than simply declaring everything as a class to conform to OO.

If you have clearly organized your concepts in your head, then you will divide up your code based on that. If you have not done that homework, then it is better to just sit with pen and paper and work on getting that mental model right. The mental flow of what the problem is and what the concepts are to solve that problem, eliminate the unwanted pieces, have the absolutely necessary pieces.

Only when you are convinced about the understanding of the problem and the models that can represent it adequately you should sit to code. Otherwise, you will end up writing a lot of code, and in your enthusiasm to follow best practices like modularity you will end up having a lot more wrong divisions of code making it a mess.

Plenty of paths

Let’s say you begin with some idea in mind. You mull over it until you are convinced about its success theoretically. Then you go about building a business or a product or both around it. Then you figure out it falls short in attracting the customers you originally thought it would.

This seem to be the case when you are doing a Startup. You are all geared up to build stuff, slog, read things you have never come across before, get excited about technologies which you have barely heard of. And then you find there are no takers.

It appears like the act of building precedes the act of finding takers. But to build something with such intensity you need to have identified the takers. If you are a build enthusiast you ignore a large part of the takers and end up building some large piece and end up finding there are no one enthused as much as you about it which later comes to include you as well.

If you are the one who finds takers before you build, you are definitely in a better position than the build enthusiast, but still you fail as you misjudged the takers.

And it comes back to saying that you misjudged the takers either by interviewing a low number or by asking the wrong people or by extrapolating the numbers in your zeal to see things scale or by lack of knowledge of the domain or by bad co-founders or bad execution or lacking the technical edge or your compromising attitude or your hurry to bring it out and so on and on.

Plenty of reasons to end up somewhere else than where you thought you would be when you began the whole thing.

So it is not about trying to find fault with building something or finding takers before build. Both are needed and most of us do that in our own way. No one has that uncanny eye to see the right from the wrong. There seem to be plenty of paths from where you begin and where you end up.

Finding what to build that will have takers is THE problem you signed up to solve as part of a Startup and unless you entered here with this problem in mind, you will find every problem you work on leading back to the above problem.

Know where you are

I am constantly bombarded by noise. Texts, Videos, Links, SMS, Calls, Chats plus a host of Apps. Some are OK, but a lot are simply noise adding to the mental harassment. 

I do not know if you all feel this, but I do. Every day, Every moment.

It was not like this when I was in school. That was in the 80s.

I had few friends. Quite close we were. We used to play all the time, read books from the local library, swim in a river, play Table Tennis and of course a lot of Cricket. 

School and then my Engineering also. Quite silent. No Facebook and WhatsApp, No mobile, no email. Spend time with friends, code in the lab, read in the library, watch movies.

Same continued at work. I was fixing kernel panics and coding drivers for a Unix flavour. So we used to use ‘chat’ on the VT100s on command line with fellow workers. We used emails quite a lot among us. The world was yet to wake up to Hotmail and the like. FB was out of sight and so was Google and so was the internet browsing at large. 

Then there was this explosion like a big bang in the late nineties and accelerated crazily through the dawn of the millennium.

I was deep into Telecom, protocol stacks and moving up the system ladder into the world of applications, building crude versions of WhatsApp and Angry birds on the earliest of the smart phones. We were all wondering what the killer app would be only to realise later that it is not going to be one, but many.

Now 2015 and I am surrounded by tons of noise. 

Not everything is added by others. I go voluntarily and hang out. Earlier this was a calm period for my brain or some void. Now it is filled with noisy bytes.

And I am sure this is going to increase enormously as we go along.

The best part of one’s life is when your time is channelized to the right things on hindsight.

This is easy to say, but highly difficult even without the digital noise.

With internet, it is a humongous task.

Everything has its negative. The greatest invention of humans has its negative in completely losing ourselves. Our time.

Machines have already triumphed over Mankind. 

I feel there will be few people awake out there.

But I do have some hope. We created this. We can wriggle out of it as well. Somehow.

On coding and timelines

Coding and creating apps or software out of it needs time and space. It should be treated as an art like painting , sculpting or writing a novel. By this I do not mean to compare in the sense of the abstract or subjective nature of other art forms. But mainly from the point of view of giving its due time to completion. Like you cannot put a gun on some ones head and generate a great novel, you cannot do the same with writing code also.

It is a misunderstanding that you can have an army of people to manage and manage the managers and generate beautiful and meaningful software products. Corporations have people mainly to handle people or customers. But when the same thing extends all the way to putting a gun on the head of a developer and make him sling code, monitoring it with spreadsheets and project plans, the whole thing loses its beauty. It is like making a beautiful painting with a team effort. I am not again saying this in the sense that software should be developed only by individuals. I mean it mainly that it would be beautiful to have highly skilled and experienced individuals write good apps all by themselves if it is possible.

Coding is not the same as hunting. When you face a mortal enemy you need support. Or when it is voluminous you need assistance. But coding is not about any of these. It is about finding the most elegant and beautiful way to solve a problem using a programming language. This is better done by a very few experienced and skilful programmers than a group of hunters going about without a clue.

Making a team write a software is not analogous to a conductor playing out a symphony with a troupe. In this case the notes for each of the musician is laid out , rehearsal is done and the conductor has got the final outcome in his head. This is not at all the case with software developed by a team. It is probably 10% of it. A large portion is simply chaos and unwieldy with a ball of mud after a while. When you have just an individual coding the software who has the experience and  vision of the final outcome, it becomes a lot easier to cater to the 'ups' and 'downs' as it happens while keeping the code still beautiful. May be there can be a few more skilled individuals working together. But when you start to have 'projects' with a lot of people who do not code tracking it, the coding is seen as a factory output. When? How long? Why so much time? Why can't we cut short here? Why should we do this feature? etc.

Part of the issue comes from the case that the person who codes do not understand the big picture. So you need the other who understands the big picture. But he cannot code. It is like the story of a lame guy walked around by a blind guy carrying him on the shoulders. The lame guy keeps telling where to go or navigates and the blind guy moves in that direction carrying him. While practicality does not allow the luxury of a single person who has the vision and the skill to make it happen in many situations, it should be seen at least to the extent that the vision and the timelines to achieve it should in no way compromise on the elegant nature of the code. In fact, part of the vision should be to 'also produce an elegant code'. Having a manageable, readable and clean code is like half the distance crossed already in your effort to build a product. A well written code saves a lot of time when you start to scale in terms of features down the line.

Iterative nature of adding features is good, but the iterations of coding should be done in such a way that one builds over the other easily. It should not be a thoughtless , hurried release and then throw away to do the next.

The best coders use less code to achieve more. DRY (Don't Repeat Yourself) principle is of utmost importance. When you can write code in a way majority of your features are resting on few building blocks which in turn rest on even more fundamental blocks of code, it is a clean construction. You can communicate your code very easily to others. Human brains operate on abstraction. When large parts of your code can be abstracted to some usable, easy to remember function it becomes very easy to get the picture and the flow. And further dissection can be done cleanly into smaller parts, it is a delight to maintain, enhance and operate a piece of software.

Writing bad code and getting a market share for your software is like conquering new territories in the colonial era only to leave them soon. You better not do it. 

How knowledge becomes a blocker when you design products for end users

If you are the one having a background of working for big companies in the past, having worked on large projects, having met a variety of customers, written 100s of functional, architecture documents, travelled across the globe, having built small and medium sized products, having handled small to medium sized teams, having worked on numerous state-of-the-art technologies,

does it all help when you build a brand new product for end users like you and me?


I feel they block you from seeing the simplicity you need to reach ultimately in your design.


They block you to the extent that your brain constantly brings in ‘complexity’ of extreme nature ultimately making you roll into your comfort zone of what you were always doing. If you are a techie, you think the ‘How’ to solve it rather than what is needed for that end user or who is that end user. If you are a business guy, you weigh everything with money and business models and break even and so on without understanding how beautiful something can be conceptualised which makes life easy in selling.

The end user is that ordinary person who would like to look at things that are ‘cool’. Things that give them some value no matter how big or small. For example, my 5 year old goes on using the ‘Talking tom’ app pushing the cat, rubbing it and seeing the facial changes and the sounds coming out of the cat in the App. This is such a thrill for him. It is not to say you design everything like a game or entertainment, but you got to find those ‘nice’ and ‘beautiful’ things beyond the mundane even if you are designing a spread sheet.

The small things that are haunting have a big effect than the big things that you have no choice but to use. You want to get back to those as often as possible.

This is why I feel you need to completely unwind and become a ‘empty cup’. This is not a button you press and you are degaussed. This takes time and an enormous amount depending on how much assumptions you have built about yourself over time. If they are too many, unwinding becomes that difficult. It may sound like the philosophy of OSHO.

Dropping what you have done and taking a fresh look at the problem in hand, every day, every moment is all that is needed. Constantly questioning your own assumptions and trying to break free and see you are in an unbiased state is often needed. If you continue to do this you will eventually have unwound with a pair of fresh eyes.

Why is it difficult to understand code?

If you are asked to read and understand a software that spans 10000s of lines of code, it is impossible to do it. Even if you spend months, you may be able to fit some pieces but will not end up getting a hang of what the code does.

This is the real bane of software. In fact this is true even for some one who has had a long gap and end up staring at his own code.

This is true, no matter how much of annotation, commenting, documentation that is there.

Code commenting and documentation is only a small step in the direction of understanding one’s code. The reason is, a code is something that changes so drastically during its early phases. Almost all the parts of the code is volatile like a molten lava. Needs change, perceptions change, how you solve something change. It is hard to keep up the documentation or commenting in line with the code change and it will almost always be erroneous.

Coding a large software is like carrying a model in your head which is having several moving parts. It is like how Einstein would have carried his view of the universe and all the lingo of general relativity and associated visuals, albeit in a small way. No other person can understand it unless they get this model right. No matter how much of a documentation is out there.

Over time, if the product survives, portions of the code gets stabilized. If the design decisions, the perception of customer needs are reasonably accurate, the initial core of the code remains somewhat intact. This is really the time to ‘document’ the code. This is when the model in the head of the programmer can be laid out in diagrams and words and comments and algorithms to make sense to others who may enter to maintain or enhance it.

I would say the initial period of development of anything should be by a team which is sitting next to each other. Until it reaches the ‘inner core’ level of stability there is no need to document anything. Everyone simply codes. Everyone talks and listens to one another and grow the model in their heads.

Teams spread across require specs to be developed and integration etc. to be planned. These are like turning an already muddy water. If there is a choice, never have your initial development spread across teams. This is because, unless two brains are in synch in terms of the language spoken, visualizing the model there is always a gap to be filled up and time to be wasted and mistakes to be made and frustrations to be built up. And two brains to be in synch is not a question of skill, but a question of attitude. Hard to get.

Even if there are documentation after reaching the stability, it is nothing like having the original team around. If you happen to lose the key members, ensure their video lectures are captured that gives the ‘model’ that was visualized, key algorithms used, key decisions, assumptions made all along. This can help the developers to latch on to the context of looking at the code.

What is so difficult in building a successful product?

After spending years on building a product, pivoting, iterating, which is yet to be launched, I can share some of my thoughts about this question.

Idea is the first step

You have a interesting thought of doing something in a way that is elegant, cool and effective over how it is being done today.

This is the starting point.

Exploring the idea

Here you start expanding, imagining the different aspects of the idea itself. It is a very free format thinking that happens throughout the lifetime. This can branch off into other interesting ideas and often you may leave the original idea and find something more meaningful and interesting.

This phase can involve prototyping, talking to customers, finding new use cases, finding customer segments, finding new ways to solve the problem, innovative thoughts, usability aspects, customer delight, engineering challenges, marketing challenges, scale and so on.

This phase can go round and round in iterations. Often people say to get traction, you should start building something with few potential customers in mind and then keep iterating until you can see that the existing set of customers are able to use it easily, find it is useful and move on to increase the base.

It is often a way you iterate your product while listening to its first set of users and adjust / re-adjust to see that it is exactly meeting the real problems of the users. It is quite possible that you find the problems you originally thought or not the real problems and the real problems are way different.

For example, when I built a collaboration tool for businesses and showed it to few business people whom I had in mind while building it,  I realized most of them do not use computers and they just keep track of their biggest orders without worrying about other smaller ones. So the problem of a what I perceived as a collaboration on various orders that are happening simultaneously suddenly fell apart as they just focus on few big ones for which they do not need a tool.

Of course, it is quite possible that such a need may be there with a retailer who is dealing with a huge amount of inventory and collaborating with his suppliers. But you suddenly find that the product you envisioned as a broad collaborative tool that can work for any one is narrowing to a segment.

This cannot be figured out easily until you are deeply connected to a domain like healthcare or education or others. If you are a generalist being a software guy, your field of vision does not have those specific problems outside computers. You end up imagining those domains and often get them wrong in terms of the real problems faced by the people who are there.

That is why products that are built for domains do not work for other domains. Or those that are generic in nature like a email which works for everyone does not solve the domain specific problems without adequate customization.

It all depends on which direction you decide to travel. A Google or a Facebook deals with the domain of information and communication which is a horizontal concern. If done well, they can be used in a domain agnostic way. But the catch is, finding such a broad based problem and seeing it work for all requires understanding the most fundamental needs of humans and trying to find the most simplest way of solving it. This can be done but requires a lot of research, lot of experimentation and perseverance.

So this part of exploring the idea and bringing it to a way for end user consumption is a long iterative phase. You cannot call your successful here just by raising funds or bringing in the first 100 customers. It can die even after getting your first 100 customers.

The most important thing to do in this phase is to constantly iterate and validate until you are confident that it works for the small subset and it can scale to a larger set.

Building the product

The actual product comes into existence only when there are customers already using it and demands more and more out of that little thing you originally started with. This is the phase where things start to get bigger. Engineering , customer support comes to the fore. Till this point, you have to be nimble and should not bother about anything else other than getting the product and the market fit right.

This should be the least worrisome phase in my guess if I ever get to this.

Some mistakes we make

We often think that the product should be built with a lot of focus on engineering. While this is not wrong, it is important to see who the hell is going to use this and how big is that ? If this is not addressed the effort put in to make something goes waste. Early on getting the feedback of target users is a great thing to have.

If you are building something very generic, often you will struggle to find this target user. You end up thinking every one can be a user. For example, if you are designing a new email thing, you may think everyone who is using email today can use it. But where you may fail is, if you are not showing something unique and differentiated then existing people would not move into yours. On the other hand, if you build something special , say it is more useful as a CRM type of email solution, then you better focus on businesses who are overloaded by their customer communications and would like to try your thing.

Going for funding initially is also a waste of time. This can distract you a lot from what you want to build. The best is to build something, find some target customers who can try out and correct things, iterate and keep trying to find what is so unique about what you have built and how easy it makes the life of your target users. Because time is a precious commodity, you may want to use it sparingly for stuff which drives you out of the main goal which is stated in the beginning of this paragraph.

Going for patenting is a waste of time. How much ever innovative your idea is, being a software thing, unless you have invented a algorithm that is so fundamental to solve that problem, spending time and money on patenting stuff on the overall idea and the way you solve it is a absolute waste of time. You may find that there are so many variants of your idea already floating in several states of maturity. Patenting is a time sucker. If you have time, then go for it. It helps to understand and broaden your thoughts without a doubt, but it does not help you to validate your idea ever. I also feel being a startup, patenting cannot be enforced even if some one violates because you simply do not have that financial muscle. On the other hand, if you have done something smart and even if you do not have customers, you can be a potential buy out by a corporation that is desperate to get a head start in that direction.

Update 1 on patenting - One of my friends told he had to face a lot of trouble when they designed a internet based backup product from lawyers representing other companies as they did not patent some of them. It was a horrendous experience. So, I would say that if you have a non-obvious way of solving a problem which gives the best result, then it should be considered for patenting.  So, my original statement of 'patenting as a waste of time' should be figured out by you as to how non-obvious/novel or trivial the thing you are trying to do.


Giving up too early - Either you do not keep good health or a good bank balance or you simply do not have the persistence to try out things. It is important to keep yourself steady on health, finance and mental strength to be there , float, try out and see what opens up for you . If you read Papillon or South you will know what I am talking about. It is all about endurance and your ability to float against all odds. You need a large dosage of hope and be able to guide you to see the light at the end of the tunnel. You may be lucky to start seeing it early or can go on forever. That is the reason why you start somewhere , read the pulse of the target customers, pivot, iterate and so on. Often it is possible you may land up with a big idea in the process if you keep at it. Or in the least, you may know the area better than any one else leaving you other possibilities.


I feel if you keep at it, you will get it right some day.

Listening to the wrong folks for advice.

Like the way you figure out the right customers for your product, you also need to figure out the right set of people who can advice you on. You need to keep miles away from people who have never built a product or taken it to customers all by themselves. Every one has a view of the world and it is completely your discretion to identify the noise from the signal. Most of it is noise. Almost all of them. The signal can only be seen by you.

No one can tell that a idea will bring you million bucks or it will fail. It is as hard as finding water on Mars.

Glamour quotient

Building a product that works for a broad set of people in the world is not a glamorous thing. If you came in looking at the glamour of a startup as touted everywhere, you are doing a disservice to yourself and to the world. I feel it is a deep meditative thing. You are absorbed entirely and you cannot be filling your brain with anything else other than getting the best out of your brain for the problem in hand. It is really tough and cannot be anything that you have ever accomplished before.

It is the next toughest thing than all the previous things you did in your life.