How to learn to write code quickly – experts answer
It seems to me that it is important to know and remember a lot. The more you get into your head, in the broadest sense of this expression, the easier it is to write code. And the easier it is to write, the higher the speed.
Questions at interviews such as “what this function does” seem silly, but they check exactly what you, having experience with a certain language, should definitely remember. It is clear that in the final analysis everything can be google, but this gugglezh also slows down the process.
In addition, you need to quickly not just write code, but think it over, write it and bring it to its final working state. Even if somewhere this includes, for example, climbing into adjacent systems. Or if a terrible heisenbug crawls out along the way, which should not exist at all and for debugging it is necessary to get deep, deep into the operating system, deployment scripts, code of a framework or someone else's module written in another language.
I also believe that in order to write code quickly, it is advisable to use tools that allow you to write less and test faster. This is generally very useful, since a smaller amount of code will reduce its complexity for the one who will deal with it next time. If anyone does not understand, this is a stone in the garden of lovers of a large number of layers and object orientation 🙂 Well, the authors of Bitrix-like sheet with 3000 lines of code without a single function, of course, too. The most enjoyable thing is not to write a piece of code, but to delete a piece of code while maintaining functionality.
In addition, to write code quickly, sometimes it is better not to write it at all. Because excess load often slows down rapid development. It’s easy to take on board a bunch of beautiful technologies and then wonder why everything has become so complicated. It is easy to start making virtually optional features “for later” or dig into another unnecessary task and as a result not finish the necessary one. To avoid all this, you need to follow a simple rule: if you are not 100% sure of the need for something (features, technology, framework, authorization server), then you can and should do without it. You need to carry something aboard only when you are sure that without this you can’t do anything. Because it’s easy to drag, but then throwing it out is much more difficult.
And also your IDE, which is trying to helpfully think out for you, hide types, and generate sheets of code with a single keystroke – not an assistant, but an enemy. Sheets will not go anywhere, even though you will not write them with your hands. And you will eventually become dependent on the IDE and stop remembering where what lies. In the end, the most hardcore guys, such as developers of the Linux kernel and system software like Ceph, write code in Vim. At the same time, there is even practically no documentation in the kernel code. Why don't these guys need an IDE? Yes, simply because they already remember everything that they need. Therefore, they are cool.
The frameworks that place magic on every corner are also not your friends, since in this case the law of holey abstractions works. The more dependencies a program has, the higher the likelihood that one of them will break in the most unexpected way. The simpler the system and the less dependencies it has, the better.
In general, practice and knowledge, otherwise nothing!