10 Tips on How to Be a Great Programmer

In a recent interview, I was asked: how can one become an excellent programmer? This is an interesting question, and I believe we should follow certain guidelines to become great programmers, regardless of our natural talents. These principles apply not only to programmers but to all professionals.

1. Learn How to Ask Questions

Different types of programmers ask questions in different ways:

Perfectionists : When asking about open-source tools, they may have already debugged the code and found the real cause of the problem. Even if not, perfectionists write problem introductions, reproduction steps, and even suggested solutions. In fact, perfectionists have no problems, only answers.

Lazy people : Here's the code. What's wrong? Help me please.

Managers : For this type, time is money. Questions must be brief. Because questions must be short, important details are often missing, which only leads to programmers asking for more details. This can go back and forth for a long time, and it may take 1-2 weeks to get a real answer.

Complainers : These people don't ask questions; they just complain until the problem disappears.

A well-prepared question (concise but with enough details) will produce better answers.

2. Learn How to Avoid Asking Questions

In most cases, it's better to avoid asking questions and figure things out ourselves. Not always, of course. Many things cannot be known by asking domain experts, and you will find the quickest, most effective path to success. But usually, trying to learn on your own has benefits:

Learning it the "hard way" is a better memory technique - we remember what we learn better.

Learning something for yourself is more meaningful.

By postponing questions (at least for a while), you can gather more relevant information to provide to those who might answer your question.

By learning before asking questions, you'll ask better questions.

3. Don't Compromise on Quality

A Reddit article about the broken windows theory states: "When we take shortcuts to deliver something in the shortest time, our code reflects our carelessness. Our developers (from the same team or future teams) will think: it's okay if the code quality is a bit sloppy. Little by little, our application will start to deteriorate irreversibly."

This is not about perfection. Sometimes the broken windows effect can be delayed. But usually, allowing windows to be broken and stay broken creates a feeling that nobody cares. Not our programmers, not our clients, not our users, not our project managers. This is an attitude, and thus the core of professionalism. As Benjamin Franklin said: "The bitterness of poor quality remains long after the sweetness of low price is forgotten."

4. Programs Should Be Deterministic

In an ideal world, everything in software is "deterministic." We are all functional programmers, writing pure functions without side effects. Like String.contains() . No matter how many times you execute:

assertTrue("ABCDE".contains("BC"));

The expected result is always the same. All state will have no effect on this calculation. This is deterministic .

We can do this in our own programs, not just in standard libraries. We can try to write as many side-effect-free deterministic modules as possible. This is not about which technology we choose. Deterministic programming can be done in any language - even functional languages have more tools to prevent accidental side effects through more complex type systems. But the example shown is a Java example. Object-oriented allows determinism. Procedural languages like PL/SQL allow determinism. If you want to use a function in an index, the function must be deterministic:

CREATE INDEX upper_first_name ON customer(upper(first_name));

-- Deterministic function here: -----------^^^^^^^^^^^^^^^^^^

So this is a specification issue.

5. Don't Fear Unexpected Problems

Murphy's Law is something programmers should always pay attention to. As software engineers, we know programs will unexpectedly fail or have errors. Because our world is not deterministic, the business requirements we work with are not either. We will inevitably enter the world of non-determinism ("the real world") where things go wrong. So don't fear it. Train your inner pessimism to foresee all kinds of things.

6. Never Worship Authority

Many programmers like to think of themselves as mathematicians, where only the purest thoughts can exist, and they must be correct.

But that's wrong. Our profession is built on mathematics, but unless you enter the world of category theory or relational algebra, we are in the practical world of real-world business requirements. Quite frankly, it's very imperfect. Let's look at some of the most popular programming languages: C, Java, SQL. Do you really think these languages are purely mathematically oriented? If so, let's discuss segmentation faults, Java generics, or SQL three-valued logic. These languages are platforms built by pragmatists. All have some very cool theoretical backgrounds, but in the end, they have to get the job done.

Everything built on top of languages is the same: libraries, frameworks, design patterns, even architecture. Nothing is right or wrong. Everything is a tool designed for certain contexts. Consider that tool in its context. Never view the tool as an end in itself. We don't do art for art's sake.

So don't doubt: XML, JSON, Functional Programming, Object-Oriented Programming, Design Patterns, Microservices, Three-tier Architecture, DDD, TDD. All of these are good tools given certain situations, but they don't always apply.

7. Practice

How can you become a good programmer? Through practice. Great software is not written in a day, and popular people are not the only heroes of our era. I've met many excellent programmers nobody knows about because they live private lives and solve problems for small companies.

But excellent programmers have one thing in common: they practice. They practice. They work every day to get better and better.

Want to get better at SQL? Do it! Try writing one SQL statement with some new features every day. Use window functions. Grouping sets. Recursive queries. Partitioned outer joins. MODEL and/or MATCH_RECOGNIZE clauses. It doesn't have to be used every time, but the practice is worth it.

8. Focus on One Direction

There may be very few "excellent" full-stack developers. But compared to that, most full-stack developers are rather mediocre. Of course, a small team may only need a small number of these, and they can cover a lot of business logic to quickly launch new software. But everything will be very sloppy. Maybe that's good enough for the minimum viable product stage, but in the long run, there will be more complex problems that full-stack developers don't have time to properly analyze (or foresee!).

You should focus on one direction and do it well.

9. Maintain Interest and Curiosity

While you should mainly focus on one direction, you shouldn't completely forget other areas. It's impossible to deeply understand all of SQL, extensions, low-level performance, CSS, object-oriented, requirements engineering, architecture, etc. (see tip #8). But you should at least understand the essence of each. You should know when SQL is the right choice (and when it's not). Why low-level performance tuning matters (if it matters). How CSS works in principle. The advantages of object-oriented, FP, etc.

You should spend some time playing with these (and more) concepts and technologies to better understand why they're important. Know when to apply them, then find an expert to actually do the work.

By using new paradigms and technologies, you'll start thinking in completely different ways, and it's very likely you'll be able to use it in one way or another in your daily work.

10. Keep It Simple

Einstein said: "Everything should be made as simple as possible, but not simpler."

No one can handle huge complexity. Not just in software, but in any other aspect of life. Complexity is the killer of good programs, so simplicity helps good programs a lot. This is easy to understand. But difficult to implement. Simplicity takes a lot of time and practice to identify and generate.

One of the simplest rules is to use methods/functions with only a few parameters. Let's look at it. The String.contains() method qualifies. We can write "abcde".contains("bcd") and without reading any documentation, everyone will immediately understand what it is and why. The method does one thing only. No complex context/settings/other parameters can be passed to the method. No "special cases" or any warnings.

Similarly, generating simplicity in libraries is easier than implementing simplicity in business logic. Can we achieve it? Maybe. Through practice. Through refactoring. But like great software, simplicity is not built in a day.