Four programming mistakes that I only realized when I became a CTO


I have been working as a programmer for over five years. Not that impressive, some of you probably have three times the experience, but I liked thinking of myself as a senior developer. Sounds serious and solid, right?

I was once offered to become a Chief Technology Officer (CTO) at a medical tech startup. After working for a while in this new position, I can look back and say that I was not a senior developer. Don’t get me wrong – I still think I have excellent knowledge of programming, especially web development; but if so, why don’t I think I was a senior?

All of this is due to four misconceptions that I had.

User (?)

1. The user is an idiot

No, he’s not an idiot.

Yes, users interact with the application in unexpected, often strange ways.

Yes, users can ask questions that seem really silly.

Yes, sometimes users are asked to add features that seem pointless.

Yes, users have difficulty with features that seem self-explanatory.

The user is not a specialist. My doctor does not require me to know the difference between low and high density lipoproteins. So why am I used to assuming the user knows which browser they are using? This is obvious to you and me, but my mom thinks Google and the Internet are synonymous. She would say she doesn’t use any browser because she uses Google.

Sometimes, to satisfy the user, I needed to override parts of frameworks to change their default behavior. Sometimes I had to add support for browsers that I didn’t want to support (hello Safari users). This seems silly to me today, but at the time I really thought that if I had to create workarounds in my code to satisfy the client’s requirements, then this the client is to blame

Choosing the best name for the variable.

2. My code is a work of art and must be perfect

Clean code, unit tests, great documentation are, no doubt, important. As a programmer, I have always strived to write clean code using modern patterns, often checked the relevance of all dependencies in the project, etc. I wanted to be a Good Programmer.

When my product manager asked me to abandon unit tests to speed up development, I felt angry – doesn’t he understand how important unit tests are? We didn’t have any automated testing, so unit tests were our only hope of ensuring stability and no regressions in the product.

This decision struck me as shortsighted. In addition, he recommended that we stop writing documentation and convert the code to a less complex architecture (we could do this because we were at the very beginning of the project).

Yes, I agreed that this would speed up development to some extent, but I was sure that this would pose a lot of problems in the future. We will spend a lot of time fixing regression errors, and the new architecture will be too simple when the scale of the project starts to grow! And how are we going to introduce new programmers to a project without a good readme?

We spent hours discussing how bad this solution is and how much it will cost us in the future.

This project ended in failure a few months later because it was well over budget.

Years later, I have to admit the truth: our team made a huge mistake. We thought about the future and forgot about the present. We completely ignored the circumstances – a limited budget and the need to create an MVP in a short time.

It is, of course, great to write code that you can show others and be proud of. Better yet, complete projects successfully. After all, programming is not an art.

The attitude of my old team towards trying something new.

3. I will use “X” for this project because I know him

At my previous company, we created every project with the same technology stack: Symfony and Angular. Why? Is Symfony the best backend framework? Not. Maybe Angular is the only way to create a modern frontend? Not. We’ve always chosen this bundle of technologies because we didn’t know others as well as these. This was our comfort zone, but is it really wrong to choose well-known technologies for new projects? It depends on various factors.

In many cases, your next project will be more or less similar to the previous ones. It would be counterintuitive to spend a lot of time learning a new technology because you already have proven solutions. But sometimes this choice will be wrong.

I remember a project where the most important requirement was a well-functioning WebSocket. What have we chosen to create the backend? Symfony, of course. It might look simpler to implement WS in PHP today, but it was a nightmare at the time. We spent a lot of time making it work. Lots of. We knew how much time (and money) it would take to build WS in PHP, but we gave up on the idea of ​​using Node. Why? I can not say exactly. On Node, we would build an API ten times faster, but it was not on our team’s technology stack.

I am very happy that the programmers in my current team are more open to everything new than I was. Last week we decided to completely replace the technology used to build part of our system. I’m sure this solution will save us a lot of time, even if we have to learn something from scratch.

What I thought about the product manager’s decisions.

4. Product owner / product manager is wrong, I would do better

When I was working as a programmer, my relationship with the product manager was … strained. Every time he told me about new changes in the content of the problem, I thought: “Why can’t you immediately do your job and decide on the problem before I start working? Is it so difficult to decide in advance how a feature should work? “

It was so naive, but I really thought it was that simple. Now I fully understand how difficult it is to plan every detail of a project. You need to take into account the limitations of technology and budget (which are actually the same thing), you need to think about the users who will work with your product, and you must not forget about the requirements of business and marketing. Sometimes some of the requirements are unknown at the beginning; sometimes business circumstances change, and sometimes you need to create something first in order to understand that it can be done better.

Another aspect is that product managers can make mistakes. Yes, it’s that simple. Programmers create bugs and PM too. It seems so obvious to me today. If I was a better programmer, I would have understood this earlier. Instead of trying to prove how wrong he is, I needed to focus on finding solutions.

It is ironic and sad, but at some point I forgot that I and the manager have the same goal – to create a great product. He just has a lot more knowledge about the budget, business circumstances, client requirements, deadlines and priorities. That is why I did not understand some of his decisions.


For some of you, these four points may be obvious. If you work in a great, organized agile team with a good leader and don’t forget the basic rules of UX, then I’m sincerely happy for you. You can probably be a much better programmer than I was. After all, technical skills are not enough to “be a good programmer”. It is much more important to understand what value you can bring to the company, and how to do it. I now understand the definition of senior developer as follows:

A senior developer is not someone who understands every aspect of technology. This is the person who will help your company create a quality product, even if it requires him to step out of his comfort zone. Solutions are more important than problems.


Looking for VDS for debugging projects, server for development and hosting? You are definitely our client 🙂 Daily billing of servers of various configurations, anti-DDoS and Windows licenses are already included in the price.

Similar Posts

Leave a Reply