Five programming fallacies

[[129427]]

I'm a hacker. I've been coding since I was knee-high on an old Commodore 64. To this day, nothing fascinates me more than putting on my headphones and hacking away at things. So by the time I started my first business, I knew a lot about programming. Is this a myth? Let me explain:

1. Code is important

I've worked in many places and have found that a common phenomenon among successful companies is that the early code looks like it was written by a bunch of programmers who got drunk. This may sound counterintuitive, but it's because you're busy trying to grow the company, so you don't have time to pursue the best software. On the other hand, failed companies spend a lot of time fixing their code base.

Here's an analogy: If you're a sushi chef, as part of your job, you collect a set of the best knives. You spend time and effort to complete your collection, and it improves your competitiveness as a chef.

But no matter how much time you spend every day polishing your tools, you are not a blacksmith. Your job is still to make sushi. Even if you have the best knives in the world, if you can't make good sushi, then your customer service will be bad. Your restaurant business will never succeed.

The same is true with software. When you run a company, the purpose of your business is to satisfy your customers. Code is a tool to that end, not an end in itself. You can and should care about your code because it helps improve customer service. But if you mistake the tool for the end, you are doomed to fail.

Lesson learned: Your customers don’t care about test coverage, technology stack, version control system, or what algorithm you use. Your job is to solve your customers’ problems, as conveniently as possible.

2. …focus on implementation, not ideas.

This may seem to go against traditional startup guidelines: Release fast! Execute! Iterate! Execute without creativity! Fail fast!

All of the above are great advice. However, "no creativity needed" does not mean that we can correct a bad idea through excellent execution. Success is to find a good problem and then solve it well. Therefore, having a good idea but not implementing it well or implementing a bad idea is not good, of course, the former can still be saved.

Many programmers are stuck in an implementation death spiral, spending a lot of time creating features or fixing bugs, believing that adding one more feature will make it a success. I tell you, this is an illusion. You just need to solve an important problem, otherwise it makes no sense to keep adding features to the product unless the feature you add actually solves the need.

It is better to have a good idea that is not well implemented than to have a bad idea that is implemented.

Lesson learned: If you’re adding a feature to fix a broken product, first ask yourself if it actually solves the problem.

3. …code is written for computers

I never understood why this mistake is so persistent. No matter how many times a programmer gets into trouble because of a colleague's poor documentation and communication habits, the conclusion they draw is often that programmers are not naturally good at such things and should not do them.

You are totally wrong.

If you are part of a team, the single biggest barrier to team efficiency is communication - it's no exaggeration to say that teams face an O(n2) problem. If code is your primary output, then you need to change the way you think about programming: code is written for people to see, and then happens to run on computers.

Many times, I have seen programmers spend hours diligently writing code, but skip the ten minutes to update the code documentation. This is because they think: "Why use a butcher knife to kill a chicken? I can leave this to future generations. My time is precious." In a sense, their thinking is ridiculous.

Lesson learned: Code is written for people to see. Don't write code without documentation.

4. …This is the last step of coding.

Do you think that once you write this feature and put it into production, you are done? Wrong. Every feature has a life cycle. The code you write today, if successful, will be praised by many generations of programmers after you. You may have to form a team just to take care of the code you write today.

Think about it. If your job was to take care of code written by someone else, would you want to do that?

The key to solving problems is to have a sense of crisis: writing the first version does not mean the end of the code. Be sure to do a good job of documentation, annotation, and organization.

Lesson learned: Do not do to others what you do not want others to do to you.

5. …a programmer’s job is to write code

Most programmers think that the best way to use their time is to sit in front of a computer, put on headphones and type code. However, if every line of code you write must be maintained and supported throughout the life cycle of the product, then the algorithm is different.

When you write code for fun, you can do whatever you want. But if you are working in a team to produce a product, your first obligation becomes maintaining the existing code. Other important tasks are: coordination, communication, planning and guidance.

Lesson learned: A programmer's job is to solve problems. This doesn't always mean writing code.

You are not only a programmer, but also a product manager.

Sometimes you might think: This sounds like a job for a product manager, not a programmer. But if you’re getting paid to write code — especially at a startup — think of yourself as a product manager. If you want your product to be successful, it’s crucial to think about the big picture. It’ll be good not only for your startup, but for your future career.

***, if you have any different opinions, please feel free to share them with us.