4 Mistakes I Made as a Programmer, but I Had To Become a CTO To See Them
By: Jakub Górowski
Tags: Software Engineering, Web Development, Programming, Software Development, Startup

The user (?) Photo by Sam Carter on Unsplash

1. The User Is an Idiot

No, they are not.

Yes, users use the app in an unexpected, often weird, way.

Yes, users can ask questions that seem really stupid.

Yes, sometimes users demand features that seem pointless.

Yes, users have difficulties with functions that seem to be self-explanatory.

The user is not an expert. My doctor doesn’t require me to know the difference between low-density and high-density lipoproteins. So, why did I used to assume users should know what kind of browser they use? It is obvious to me and you, but my mom thinks Google and the internet are synonyms. She would say she doesn’t use any browser because she uses Google 🙈.

Sometimes to make the user happy, I had to override framework parts to change its default behaviors. Sometimes I had to add support for browsers I didn’t want to (greetings for Safari users 😅 ). It is silly when I’m talking about it today, but those days I really thought it was the client’s fault when I had to make some workarounds in my code just because of their custom requirements.

Choosing the best possible variable name. Photo by Clay Banks on Unsplash

2. My Code Is an Art and Has To Be Perfect

Clean code, unit tests, great documentation — these are undoubtedly important things. As a programmer, I always wanted to write clean code using modern patterns, and I frequently checked if all dependencies in a project were up to date, etc. I wanted to be the Good Programmer.

When my product manager asked me to drop the unit tests to increase development speed, I felt angry — didn’t he realize how important unit tests are? We didn’t have any other automatic tests, so UTs were our only hope to make the product stable and regression-free.

This decision seemed to be shortsighted for me. Also, he suggested we should stop writing documentation and convert code to less complex architecture (we could do this since we were at the beginning of the project).

Okay, I agree this will speed up development for a while, but we’ll have a lot of problems in the future. We’ll waste a lot of time fixing regression bugs, and the new architecture will be too simple when the project grows up! And how will we introduce new programmers to the project without a good readme?

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

The project failed a few months later because it dramatically exceeded the 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 small budget and the need to create an MVP in a short time.

It is great to make code which you can show to others and be proud of. But it is even better to finish projects successfully. After all, programming is not art.

A mindset of my old team about trying something new. Photo by Ryan Cheng on Unsplash

3. I’ll Use “X” for This Project Because I Know It

In my previous company, we created every project with the same tech stack: Symfony and Angular. Why? Is Symfony the best backend framework? Nope. Maybe Angular is the only way to create a modern frontend? Nope. We always chose that set of technologies because we didn’t know others as well as these. That was our comfort zone, but is it wrong to select well-known technologies for new projects? It depends.

In many cases, your next project is more or less similar to previous ones. It would make no sense to spend a lot of time learning new tech since you already have proven solutions. But sometimes, it can be the wrong decision to make.

I remember the project where a well working WebSocket was the most important requirement. What did we choose to create our backend? Symfony, of course. Maybe today it is easier to create WS in PHP, but those days it was a nightmare. We spent a lot of time making it work. I mean A LOT. We were aware of how much time (and money) it will cost to build WS based on PHP, but we threw away the idea to use Node. Why? I really don’t know. In Node, we would build API 10x faster but that wasn’t our team’s tech stack.

I’m really happy that programmers in my current team are more open-minded than I was. Last week we decided to completely switch the technology used to build part of our system. I'm sure this decision will save us a lot of time, even if it means learning some things from scratch.

What I thought about product manager’s decisions. Photo by Michal Matlon on Unsplash

4. My Product Owner/Manager Is Wrong, I Would Do It Better

When I was working as a programmer, my relation with the product manager was… tough. Whenever he was telling me about new changes in task scope, I was like:

Why can’t you just do your job and define the scope before I start working?! Is it so difficult to decide in advance how that feature should work?

That was so naive, but I really thought it was easy. Now I fully understand how challenging can be to plan every detail of the project. You have to take into consideration the limitations of the technology and budget (which are the same thing actually), you have to think about users who will use your product, you cannot forget about business and marketing requirements. Sometimes, some of the requirements aren’t known at the beginning; sometimes, business circumstances change, and sometimes you have to build something first to figure out it can be done better.

Another thing — product managers can make mistakes. This is as simple as that. Programmers make bugs, PMs also. It is so obvious when I think about it now. I would be a better programmer if I realized that before. Instead of trying to show how wrong they are, I should focus on finding solutions.

It is ironic and sad, but at some point, I forgot that I and managers have the same goal — make a great product. They just had a lot wider knowledge than me about budget, business circumstances, requirements from the client-side, deadlines, and priorities. That’s why I didn’t understand some of their decisions.

Summary

For some of you, those four things may be obvious. If you’re working in a great, organized agile team with a good leader, and you have in mind the basic rules of UX — I’m really glad. I assume you can be a much better programmer than I was. Because “be a good programmer” isn’t only about technical skills. It is even more important to understand what is the value you can bring to the company and how to do it. Here is how I understand the senior developer term now: