How to improve your programming style?

Confession 1

I am a developer. From my employers, I constantly hear that I work slowly and often complicate things without a good reason. And I had to do something about it. To avoid.

All my programming experience is made up of university work and a couple of years in various companies. The people who criticized me repeatedly told me that, on the whole, I understand the subject, so I am far from a clinical case, as one might think. However, obviously, I have developed completely the wrong programmer habits (at least in the eyes of the employer) and I need to urgently change them. Everywhere, wherever I worked, my decisions, using hierarchies of small classes with delegated behavior, were considered bad. They say that it is the right way to write, but it is not. Because all this “as it should be” can cost me a job.

I started reading books. In them, I saw everything the same thing that I was trying to escape from. For example: for one single work, I used a similar code from another project, for which I brought it to a common interface. My colleague, examining the error, came across this code and asked me why I did everything so difficult for a one-time job. But for me this is not a one-time job! Both projects are very similar and the same abstract code could be used in several more.

I note that the people who criticized me have always been much more experienced than me. Therefore, there are two options: either something is wrong with all experienced developers, or something is wrong with me.

The person, having left this message on one of the popular English-language resources, asked for help. Acknowledging a problem is half the solution. A person does not sincerely understand what they want from him and with all his soul wants to improve.
')
The decisions of the world community were divided into four groups:
1. “Score”, because experienced programmers are just fools. And if they have worked for a long time, this does not mean that they are experienced (many votes).
2. Ask the critics how they would structure the code (as many votes).
3. Ask for programming in a couple / go to the courses (few votes).
4. “Well, write easier!” - there is no guarantee that the requirements for new projects will well fall on a carefully designed interface (1 vote).

All these tips do not go beyond the area in which the question is formulated, and therefore cannot solve the main problem - “So what can I do to improve my programming style?” Point 4 is the closest, but far from it. The problem is deeper.

What to do?

Role-playing games. Part 1

You and your counterpart have opened an automation business for something. Specifically, you of the two of you are the director.

What is your counterpart's hourly rate? Take a calculator and divide the number specified in the employment contract by 160. If you perform these actions during working hours, then divide the result by another 60. That's it (+ 20% discount rate in the FIU + 0.2% for injuries + 6% USN ( half can be credited from the taxes of the PFR) = + 23.2% minimum) you have heated your employer, having fun here with me. Do you know what a million rubles looks like? Remember the volume (and, especially, quality) you have written over the past year - this is the million. Is it worth buying your labor? Would you, as a director, buy?

Sooner or later, you will approach another person with the simple question “When will it be ready?”, With the rational proposal “Work faster” (because you are dear to me) and with the wise advice “Make it easier”. You are heartily amused by the explanations of the double, why deadlines are delayed, because before becoming a director, you yourself “otmazyvatsya” in the same way and know what is behind this.

Now your twin is in the same situation as the man from the first confession. The question is whether your second self recognizes himself as part of the problem or will write everything down to the boss and other external circumstances.

And now, attention, a big secret. For you, as a director, he is no secret, and the obvious thought is that you don’t need programmers . You need to solve the problem. Maybe it was worth ordering the program in another place or buying a ready-made module or not automating anything at all, but hiring people for a low salary. At the moment you have already spent 600 thousand and have not received any suitable result.

Big Secret One More Time: no one needs programmers . And programs too. That is all. People are interested in them, their problems and some other people. It just so happened that some of the problems can be solved by writing code. If the same problems were solved by cutting off wooden planks and painting them green, and that would be cheaper, they would have done so.

If you are ready to memorize only one thought from the whole article, then remember this: Programming is not self-worth, but programmers are maintenance personnel.

This thought can hurt you - everything is fine. The sooner you accept it, the more valuable a specialist you can become. In our culture, it is believed that it is better to be a master than a servant. But if you think about it, then society and you are in some ways. In this relationship, you can take the role of a “voluntary servant” and the society (represented by the employer and satisfied customers) will generously reward you for your care.

Role-playing games. Part 2

Let's enter on the other hand: your double is the director, and you are the developer.

The director is about to visit you, and the factory of abstract automators has not yet been added, the SQL queries are not debugged and in general for half a year it has been understood that everything should be wrong.

Dilemma: no one wants to work anyway. Everyone wants to be proud of their work. Therefore: (logical trap) Yes, I do it slowly, but correctly .
If everything is clear with “slow”, then what is “right” is not at all obvious. In fact, everything is simple. “Correct” is when a usable program or service appears in the allotted time (±). If your other notion of "right" does not lead to the appearance of a usable product within a reasonable time, then your "right" is no good. There is no room for maneuver. Recall that programming is not worthwhile.

Work takes all the time allotted to it. If the developer is given three times more time, he will not write three times better. He will write three times the code of the same quality that he usually gives. Therefore, by all means try to get something working. At any price. Your goal is a working program, no matter how written. There are many so-called. called "dirty problems" - these are problems that are not clear how to solve, until you try to solve. Example: crash test machines. “Dirty” problems will surface during the first pass and can be taken into account during finishing work. It is desirable, by proxy.

Second Big Secret: code is always bad. There is no “beautiful” code. The smaller the code, the better. Any code contains errors, compromises and performance problems.

• Less classes, fewer functions, fewer buttons, fewer links, and generally less.
• Do not write a generic function if its functionality has not met at least three times in different places.
• Do not write class functions and methods before they have a user. Those. first, a method call appeared somewhere and only then the method itself appeared.
• You do not need three levels of inheritance with a template class in the middle.
• The standard module is fully capable of solving your problem - read the documentation again.
• SQL is not the only repository in the world. A lot of things can be easily stored directly in files in JSON.
• Do not think about the system "for growth". Other requirements are a different system. Do not try to build a skyscraper in the village - this is architecture
• This algorithm O (n ^ 2) can not be optimized to O (n logn), because in this place n is never greater than 5, because it means the number of fingers involved on the hand.
• Instead of writing a table generator, you can put it once in HTML - it changes slightly every six months.
• SVN is a great version control system. Especially when non-programmers who work with you on a single project use it with you.
• Do you really need pixel-by-pixel illumination to render a mat or a standard GL_SMOOTH enough? And, by the way, we will show it at the exhibition on a 7-year-old laptop with integrated graphics.
• True, do you think that the loop on iterators is faster than on indexes, especially if you compare the first and second with the time of disk access?
• Similar classes in two projects are not a reason to connect one with another. Consider it a coincidence. If you make a general class, then from now on, with any change, you will have to think about two projects at the same time. Is it worth it? Hardly.
• A board with a marker + a camera phone perfectly replace the UML diagrams and most of the interface prototyping programs.

A programmer who takes into account the commercial implications of his decisions is worth its weight in gold. Steve McConelle

Confession 2

Hello. I am the head of the development team. From my developers, I constantly hear that they do not have time. I understand that my developers could work faster (and even noticeably faster) if they didn’t complicate everything without a good reason and would often look into the documentation. And it’s time for me to do something about it. To avoid.

All my programming experience is made up of school “pen attempts”, olympiads, university works, additional education, teaching, home projects and 8 years of successful work in small, medium and large companies. In general, I understand the topic. Obviously, I developed “those” programming habits (at least in the eyes of the employer) and consider it necessary to share them. Everywhere, wherever I worked, my decisions never suffered from a mania of "reuse". It is said that writing is not good, but it is not. Because all this “as it is necessary” can cost work not only to me.

I read books and read on. There is everything in the books. I write code almost every day (including weekends: I like writing code) and almost every day I read the documentation. I did it all at once. But I know for sure that patience is the shortest way. I'm not in a hurry, because quickly - it is slow, but every day. I am untied from the language, paradigms, technologies, and the rest of the technofetish. I just like to make useful programs for people. Solve problems.

I note that people in similar positions (and the most productive developers), adhere to similar thoughts. Therefore, there are two options: either something is wrong with all experienced developers, or something is wrong with ...

PS
Third secret Begin to write commit commit custom value of the added code. Not “added two methods”, but “Now the user is faster / easier / less ...” or “the function has appeared / the reaction has changed”. You have nothing to write? You have done nothing in a day.