How To Become A Really Good Programmer

I was asked in a recent interview how I think you can become a really good programmer. That’s an interesting question and I think we can all become great developers, regardless of talent. To do this, we just have to follow a few rules, which – I believe at least – are actually based on common sense. In fact, some of these rules are important not just for programmers, but for every professional. Here we go:

Asking good questions

Essentially, the following types of programmers exist when it comes to asking questions:

  • The perfectionist . Especially when asking a question about an open source tool, the perfectionist has already debugged himself across the code and identified the real cause of his problem. Even if he has not done so, the perfectionist will certainly write an introduction to the problem, name the steps that are needed to reproduce it and tend to suggest a workaround. Possibly, as already said, he will make another suggestion for a solution. The perfectionist actually has no questions. Answers only.
  • The chatterbox : This person doesn’t really ask questions; actually he only sorts his thoughts in public and occasionally inserts a rhetorical question mark here or there. What looks like a question is actually just a series of thoughts. If you wait with the answer, the chatterbox will either find it by itself or ask the actual question in e-mail 37. Or not. Or maybe if we give it a try. And you know what? It turned out that the requirement was totally wrong, I have now solved that differently. Oh, oh yes, I completely changed the libraries. Hehe. No more questions.
  • The slacker : Here’s the code . What is wrong with that? Halp plz!
  • The manager : For this type of developer, time is money. The question must be short, the answer must be given ASAP. There is a certain irony in this approach, as the particularly brief question (read: incomplete, imprecise) usually lacks a number of important details, which leads to inquiries. The manager, of course disappointed that the reaction does not contain an answer but a new question, now writes another short message and asks for an answer even more urgently. It can then go back and forth for a while. In the end, it can take a week or two before the actual answer is finally there.
  • The plaintiff : He doesn’t ask any questions. He is complaining. Until the question disappears. Perhaps. And if not? All the better – more reasons to complain!

Don’t ask questions

In fact, it is usually better to try not to ask a question in the first place. Maybe you can find out the answer on your own? Of course not always; some things just can’t be known. Asking an expert in the field is then the fastest and most efficient route to success. However, it often has advantages to find out something for yourself:

  • You learn the hard way. This makes it easier to remember – we remember what we have learned
  • It feels better to figure things out for yourself
  • You don’t make “noise”. Do you remember the chatterbox? If the respondent has little experience answering questions (and thus does not know that he should not give his answer immediately), he may want to answer each incomplete sub-question individually. He just doesn’t see the reasoning behind it. That doesn’t help anyone.
  • By putting off a question (at least for a while), you can gather more relevant information that you can then pass on to whoever is supposed to answer the question. Think of the perfectionist. Find out the details first, then ask questions.
  • If you practice asking good questions, you will get better at it. But you have to take a little more time for that.

Don’t leave any broken pieces

When we take certain shortcuts to deliver something in the shortest period of time, and our code reflects how careless we’ve been, developers coming after us (from the same team, a future team, and even ourselves!), Will reach an important Conclusion: it’s not important to pay enough attention to the code we produce. Little by little our application will start deteriorating in what it becomes an unstoppable process.

It’s not about becoming a perfectionist. Sometimes a repair can (or must) of course be postponed; but it is often the case that we put ourselves in situations that no one is happy with when we break pieces and don’t sweep them up. We programmers are dissatisfied, our customers, the users and the project manager. But that’s all a matter of attitude and thus forms the core of professionalism.

No matter what it’s about: That’s right. The “low price” in this case is the quick victory that we get from sloppy programming.

Target deterministic software

In an ideal world, all software would be “deterministic”. We would all be functional programmers, would write pure functions with no side effects. Like String.contains () . No matter how many times you run the following code, the results are always the same:

assertTrue(“abcde”.contains(“bc”));

Expectable results. The universe and all of its states have absolutely no influence on this calculation. It’s deterministic .

We can do this in our own programs, not just in standard libraries. We can try to write deterministic modules as often as possible without further effects. It is not about the question of which technologies we choose, deterministic programming can be implemented in any language! Even functional languages ​​have various tools to avoid unwanted effects through the use of more sophisticated type systems. The example I have shown is in Java, however – object orientation also allows determinism. Hell, even procedural languages ​​like PL / SQL allow determinism! A method, a function or a process that causes undesirable effects definitely falls under the “broken pieces” that we leave behind. Perhaps it was just easier to maintain these unwanted effects in the hope that they would be removed at some point.