Is it worth it for a IT start-up cofounder to learn programming?

Back in the summer of 2014, my answer to this question was in the affirmative. It definitely changed my life. But in what direction - an open question. In any case, I gladly (and pain) share the suffering and the read thoughts and personal experiences.

If you are an early stage IT business cofounder or a technical cofounder who is thinking about how to occupy the team of idlers around him while he is sawing the product, this article is for you.

Of course, if a business cofounder learned how to program in 14-16 years and his experience in developing is slightly less than that of his technical partner, this is almost an ideal option. Almost, because such a distribution of forces also has its drawbacks (you can immediately hit the product development without any study of the market), but at least the question of learning how to program or not, in this case is not worth it.

But what to do if there is one programmer in your team and it seems to you that there are no other significant tasks other than development before launching the product, because there seems to be nothing left to sell and there is no place to attract users? Spoiler: it only seems that way to you.
')

My history

In 2014, our team of 4 people (4 cofounders, of whom only one was a developer) worked on the site to prepare for the EGE bitclass.ru. Everything was going relatively well, but by the end of the school year it seemed uninteresting to us to make a site on which, albeit in an interactive form and with gamification, we simply publish the tasks. We started a rather radical pivot. This story is not over yet, and I’ll write about what happened as a result (it turned out to be lampa.io, a social educational platform where not only our editorial staff, but also all those who wish to publish educational materials). So, during this pivot, I had the (erroneous) impression that the only valuable contribution that can be made to the common cause is programming. I felt a burning envy of our only developer, looking at the many colored letters on his black screen. He alone was engaged in the present case.

After two or even three months of unacceptably relaxed life for a start-up wannabe and one online course on the basics of programming, I accidentally visited the site of one full-time development school, read the description of the concept and thought that it was a good idea to really learn how to program. Then I chose the most intensive and hardcore course on JavaScript + Node.js, which I was able to find, and plunged into programming for 3-3.5 months. It was a wonderful time, and programmed almost without days off (officially 6 days a week, 11 hours a day + another 3-5 hours after classes), with breaks only for sleeping and eating, in the company of people who go through the same experience, was very cool. On the one hand, we worked a lot. On the other hand, after a year of working on a startup itself, in which the main difficulty was constant uncertainty, such a structured life was perceived as a vacation. 80-90% of my fellow practitioners began working as programmers, and not even juniors.

As a result, I learned how to program, but the development of our startup slowed down a lot.
Since then, quite a lot of time has passed to reflect on my experience and formulate the pros and cons of non-technical business co-founder learning programming.

Advantages and disadvantages

Let's start with the pros:

1. Your startup will become unsinkable - at the very worst and worst case, your burn rate (the amount of money a startup spends over a certain period of time) can be equal to the cost of living for one person (this, however, has a minus - you can work on an unpromising project for years and spend the best time of life); even if your team falls apart for some reason, a startup can survive this.
   
   
2. At the start, you can move faster if another programmer appears in the team; although, taking into account your inexperience, it will not be possible to count you as a full-fledged combat unit; at later stages, it doesn’t matter much, because you can still find one or more pay programmers.
   
   
3. There will be no painful period when the product is not yet ready, and the rest of the team members seem to have nothing to do. Which leads to doubts, unrest and depressed moods. The main thing - remember: the fact that you have nothing to do is a complete illusion and justification for your laziness or uncertainty.
   
   
4. This is perhaps the most important plus: even as a business cofounder, by performing quite a business function, you become much more efficient. There are a thousand little things that need technical skills for quick execution: quick publication of new content on the site, adding JavaScript goals in Yandex-Metrics, uploading data from the database, testing the new value proposition on the landing page. Each of these actions is not even programming, sometimes it is a couple of lines of code, but you cannot cope with them yourself without technical skills. You should at least know where to climb in order to write this couple of lines of code. So, without technical skills you will move slower than you could.
   
   
5. You will be able to estimate how much time some work takes, which means you will be able to better plan and prioritize different tasks. Before my immersion in programming, sometimes I didn’t even make any suggestions, assuming in advance that it would be long and difficult to do it, although in fact their implementation would take an hour to do.
   
   
6. When arguments end, you can quickly do something yourself. Yes, there should be a consensus in the team, but if you really believe in some feature, but you can’t convince the coowner, you can at least quickly implement it and check the result. And if it does not go - no problem to remove.

But the disadvantages outweigh:

1. Let's start with the obvious. In the time it takes to truly learn how to program, you can do a lot of useful things. About this below. In the most extreme case, you can earn money that will go to the salary of the missing programmer.
   
   
2. The desire to learn how to program, that is, to do everything yourself, may be a sign of the inability or unwillingness to delegate and motivate or uncertainty about the idea.
   
   
3. You have an additional incentive to work a lot, instead of working with the mind (more familiar in the formulation of work hard, not smart). If we assume that the mother of inventions is a necessity, then your potential inventions will be less likely to be born. You will no longer need to invent quick experiments. Why do something quick and raw, if you can immediately make beautiful and right? By the way, the same trap lurks those teams where all the founders are originally programmers.
   
   
4. If you like programming (and this seems to be a prerequisite for it to work at all), then you will want to program all the time; all other activities of the startup, such as customer development or marketing, will suffer greatly from this; It is very pleasant to program psychologically: you create a product, at the end of the day there is a tangible result and at the same time no one tells you that what you have done is absolutely not necessary for anyone. If you communicate with potential users or even just explore the market, you are very likely to get bad news all the time.
   
   
5. Understanding the technical side of the issue limits the flight of your imagination. If you know that you will have to introduce some feature, then you are more likely to come up with some variant of it, which is easier to develop, and not better for users. And this is not always effective: yes, you will spend less than a day on development, but the loss, for example, of conversion due to a solution that is not optimal for users, can block all time savings.

What to do

So what do non-technical founders do in times of trouble when MVP is not ready? There are many options, and some cases just lie on your “critical path”.

• It is clear that you can work on different parallel development tasks. In our project, just with this, everything was simple. Since the product consists of technology and content, it was logical to create content.
  
  
• In many cases, customer development can begin before the appearance of MVP. You can conduct an interview with the target audience not to let them try your product, but to understand how your users live, how this market works now without you and what problems the users have (almost exactly in this place I quote someone else's retelling of the book Lean Startup). The interview should be a lot. And their results should determine what, in fact, you are developing, or at least influence it.
  
  
• You can make a prototype of the main interfaces (ideally “live” - with active zones) and test it with potential users. The advantages of this step seem obvious, but for some reason we do not do this on our projects. I suspect that other teams, in which there is no designer, make the same mistake. It is important to create and test a prototype not so much because you immediately improve usability, but rather in order to better think up the entire product from beginning to end, as well as once again communicate with users and evaluate their reaction to what you are doing.
  
  
• You can check how your idea is interesting to the target audience, talking about it in thematic public in social networks. You can start blogging. So you can increase the audience even before the launch of the product. And if nobody reads you, the question arises whether someone needs what you are doing.

Summary

The conclusion here is this: if you are a business co-launcher of a startup and are thinking about going to learn programming, then most likely you should not do that.