What is a good code, or how to become a popular developer

This series of articles is intended primarily for novice developers or for those who do not understand why they are still “running” in juniors, and not seniors.

I will begin, perhaps, with philosophy, namely, with the words of Socrates: "Here's my advice to you - never listen to anyone's advice."
')
A couple of reservations:

• The information in this article is advisory in nature, and in no case should it be regarded as a call “it is necessary to do this only, and everything else is wrong”.
• I will give definitions in my own language, simply because I disagree with some generally accepted ones.
• Since the last years I have been specializing in the stack of .NET technologies in C #, then, accordingly, all the examples in the following articles will be in this language.

I am sure that the question “What is good code?” Arose from the very beginning of the emergence of such an industry as programming. And in the process of formation of this industry, the evaluation criteria changed quite seriously. Here are some of them:

A good code is a code of the minimum size, in other words, the use of the minimum number of operators that is necessary to achieve a result.
Good code is the code that runs the fastest in the system.
A good code is a code that is ... blah blah blah.

I started programming more than 20 years ago and honestly tried to adhere to the rules of writing good code that were relevant for that period of time. Only here is the trick: no matter how hard I tried, I had the feeling that I had written badly and could be done better. And I tried again, mastered new technologies, some have sunk into oblivion, some have developed so much that they have little in common with the original prototype, and still I did not get 100% certainty that yes - this code is well written. And as it turned out, the reason for this is quite simple. There is no good code in the classical sense, because it is impossible to please everyone and everything. But in the process of finding the answer to the question of how to learn to write good code, I received answers to many other questions and, most importantly for a programmer, is professional experience and knowledge. And I am ready to share my experience in my articles.

And here's the first piece of advice : if you want to be a professional developer, get ready for what will have to learn all the time.

Any product has a customer a priori. The customer may be your direct employer, a third-party customer, or you yourself. So maybe, if a software product that fully implements the requirements of the customer - this is the standard that can be called a good code? This is the first misconception of a newbie. In fact, make a product according to customer requirements can any developer. On time - an experienced developer, but only a professional can make a product on time and correctly. Thus, properly written code is one that is easy to maintain and maintain.

Easily scalable product is a product that requires a minimum of funds to make changes (funds are any labor costs: whether it is work / hours of a developer or tester, time spent on project management, and even communication time!)

Having dealt with the first, correctly written code is a code that scales easily.
Note: any rule has exceptions, and in my experience they look like this. The code (program) has two main criteria: the first is speed, the second is scalability. So to achieve them at the same time is a waste of time since they, as a rule, contradict each other. It is often much cheaper to increase speed with additional iron than to hire a group of developers who optimize the program, while optimizing increases the likelihood of building new bugs, etc., and probably the most important advantage is the controllability of the code.

The second advice is your task as a developer, to understand what the customer needs. The more accurately you understand this, the more accurately you will realize it.

The faster and more harmonious the process, the more important part of the team you become:

• Programming is a team view of the industry; if you want to succeed in it, you will have to reckon with this;

• If you think that you are the smartest programmer, and all other programmers are stupid, then I advise you to move out of Antarctica and stop communicating with penguins. I admit that they are not very strong in this area, but if you are still in civilization and are an employee of a small company, then go ahead to the big one. I assure 100% of you are waiting there, however, you will be checked for knowledge and no penguins will ask about them;

• If you are brilliant in programming and consider that a company with a large (well, I’ll clarify) multi-million turnover and higher will be located to you, then you are mistaken. Most likely you will be overboard. I explain it by my example: from me the duties require management of the development team. In other words, I am responsible for the development deadlines and the quality of the development code. But what I encounter when I take in the team of a brilliant programmer:

The first. The product must be delivered on time. A brilliant programmer never meets deadlines, and the reason is simple: he ALWAYS tries to find the best solution, not realizing that the best is the enemy of the good.

The second. The product must be of good quality. A brilliant programmer will always strive for quality to be the best and, unfortunately, this is to the detriment of the time and work of the whole team.

Third. According to the ingenious programmer, the product is the action of himself, and not of all the team members, and his ingenious brain does not tolerate you changing something in his architecture without his knowledge.

Fourth. The ingenious programmer does not understand that if the “BUTTON” text is found in the “BUTTON” control, this is a bug for the customer.

Hence the main advice is your task, if you want to be a professional, then be part of a team, and if knowledge allows, then be its significant part. Help - answers to current questions.

How to distinguish good code from bad?

By code signature. In most cases, good code differs from bad in logic and architecture. Use the design principles of SOLID and always adhere to them.

What should you always remember when developing programs?

Try not to break or deviate from the basic principles, even if you write some kind of test for yourself. You need a class - start writing it with the development of the interface, even if there is no direct need for it. It develops style. Do not be lazy to re-read the literature and try not to learn, but to understand the material.

How much and what does one need to learn to become a sought-after (and well paid) developer?

The ad text: “You need a personal driver up to 20 years old with the skills of an expert in hand-to-hand fighting, the ability to pass the training line of GRU special forces per minute in a diving suit, while simultaneously frying 10 pies on one pan”. Something like this is usually described duties. But this does not mean that you need to do all this. In the requirements, as a rule, specified maximum. Select from the whole circle what you know and know how, add a little artistry and colors, and go ahead - to persuade our personnel managers . But before you do this, still appreciate your sober knowledge of knowledge. And then some people have one very good symptom called “I know a lot”, which immediately indicates that you have a mediocre store of knowledge. On the other hand, if you have a large number of questions and you begin to understand how little you know, then this is already an indicator that your knowledge base is solid and you can claim to be a developer, not a junior.

How much learning is required is very individual, but in any case, the one who learns more knows, and, as I said, programming is an industry in which you need to study all the time. But the average numbers are:

• to reach the level of a novice developer (junior) is quite possible in 6 months;
• reach the developer level (developer) - for 12-18 months;
• advanced developer (key developer) - 2-5 years;
• expert level (seignior) - from 7 years and up.

Where to begin?
In response to this question, the statement of Lao Tzu goes well: "Even the longest journey begins with the first step."

First you need to decide for yourself: do I want to become a programmer and constantly study, there are also many other wonderful professions: a conductor, for example, or a tram driver? If they did decide, then open the books and go ahead. As base books and resources, I would recommend Troelson's "C # 5.0 Programming Language and .NET 4.5 Platform." And a resource for learning more about Jeffrey Richter "CLR via C #". Good luck!

In subsequent articles we will consider specific examples and C # implementations of the .NET platform.

Posted by: ThoughtsAboutProgramming