How to become a better programmer

Today, software engineering resembles medicine in the 18th-19th century.

We are trying to make useful software in an honest attempt to do the best job possible. We often succeed. Yet, two similar teams often working on the same kind of problems get shockingly different results.

Is there anything we can do to improve our chance of success?

What do we want?

We want working software. That’s a given.

We want to achieve it without working overtime. We want less stress at work, no long debugging sessions, no needless meetings, and no formal approval of our code changes.

A perfect IT project is easy to imagine.

Picture this.

You log in to the work environment after returning from a morning run and drinking your first cup of coffee. Of course, you work remotely. It’s 2022, after all. You go to the office when you want, not every day.

You have a short call with the team to discuss the plan for the day. You decide to pair-program with a colleague, so you hop on a different call and work together until lunch. After lunch, you finish the code changes and deploy them to production. Everything works perfectly. The rest of your team does the same. On a good day, you finish more work than many other teams in an entire week.

In the afternoon, you have another call with your coworkers. You discuss the changes, so everyone is familiar with the current state of the code, and you update the documentation together.

Later, you have a short knowledge-sharing session. You show the people how to speed up SQL queries. Your colleague teaches the proper usage of a front-end chart generating library.

You like spending time with your coworkers after working hours, so you invite them to a game of squash.

Seems impossible? Where is bug fixing? Where is firefighting? What about 5-hour long meetings? What about leaving the office happy you won’t see those people until the next day?

We are taught wrong

It may be difficult for many of you to believe in the story because we are taught that firefighting, wasting time in meetings, and endless hours of debugging are normal.

How many tutorials have shown you how to test the code example they presented? We don’t do it in tutorials. I often skip the testing part from my tutorials, so you can blame me too.

Even the testing tutorials show the worst possible way of writing tests. If you follow their advice, you will hate tests, they will slow you down, and you will scream “Stupid!” every time someone mentions TDD.

You were thought wrong.

How often do you see an article about writing documentation for your project? Only a few such tutorials exist. Many of them present outdated and ridiculous practices like drawing a UML diagram. No surprise programmers are scared of writing documentation.

You were thought wrong.

If teaching programmers correctly were the only problem, we would quickly learn the correct practices on the job. Yet, usually, it doesn’t happen.

Wrong incentives

We praise people who fight bugs, create baffling architectures, and keep vast amounts of knowledge in their heads.

Almost no company recognizes people who prevent bugs from happening in the first place. Only a handful appreciate people who design the simples solution. Nobody cares about documentation.

In a perfect world, the person who gets the most pay raises and promotions should be the one who never has to work on a weekend or at night because of a bug in their code.

Why do we praise people for doing their job incorrectly and fixing it later? Unfortunately, promoting the proper behavior requires working at a company where all people understand programming. Good software doesn’t happen by itself. It requires constant effort.

The simpler the solution, the more work and experience it requires. Not everybody sees that.

What else?

Often, people hoard the knowledge to advance their careers. The person who gets constant questions from other programmers should write down every answer. If they can’t write comprehensively, someone should help them.

Companies treat the knowledge hoarders as the crown gem. In reality, such people are a liability, not an asset. I dare you. Try explaining the problem with knowledge hoarders to a manager who often uses the same tactic to stay in power. At best, they will laugh at you. At best!

How to become a better programmer

Don’t be the worst.

Avoiding stupidity is often easier than being a genius.

I have just described three behaviors impeding IT projects. Do everything you can to avoid them yourself and weed them out from your team.

If someone hoards knowledge, ask them questions and write down their answers. Over time, you (and everyone else) will need them less. You do it because you don’t want to bother them with silly questions constantly. True experts will appreciate it. They will love you if they have no time to do anything and you take the burden of writing from them.

If they see their knowledge as a way of staying in power, they may object. Probably they will do it indirectly. They may say something like: “Don’t bother writing it down. I will create the documentation for it.” Yet, they never deliver the promised documents.

I should write “Don’t be the knowledge hoarder yourself,” but let’s be honest, if you were, you would stop reading several paragraphs earlier.

Don’t overcomplicate the architecture for the sake of using cool technology. That’s a difficult one. Seriously. People are masters of making an emotion-based decision and justifying it with logic later.

I did it too. In one of the previous projects, we used Kafka only to add it to our CVs. Our entire use-case could be replaced with CREATE TRIGGER log_insert AFTER INSERT ON x FOR EACH ROW ... in a relational database. We used Kafka anyway.

Nobody is immune to hype-driven development.

Last but not least, learn TDD.

You will need a few months to learn it. It will be awful. You will be slowed down by writing tests. But once you understand it, you won’t need long debugging sessions anymore. You won’t spend hours testing your code manually. You won’t worry about a deployment in production anymore. You won’t understand how anyone may work without TDD.

TDD is worth the time investment.

But the people

If you’re on the wrong team, people will ridicule the change in your behavior.

If you suddenly become a test-driven development person, they will complain about wasting time. Keep doing it. Does it make sense to spend time doing manual tests more than once?

If you start writing documentation, they will point out every outdated part to diminish the value of the documentation. You may hear, “Documentation gets outdated. It makes no sense to write it.”

It does make sense to write the documentation, and it does make sense to keep it updated.

If you insist on simple architecture, they will ask whether their idea is too difficult for you.

But… it will happen if you work on the wrong team.

“Go where you are celebrated, not tolerated.”

Definitively, don’t stay where you aren’t welcomed.