Ten tips for novice programmers

Foreword

Well, when you work with a person who knows a lot about his business. And what if it happens to work with a colleague whose experience is not so great. This is especially true of professional and personal qualities. One must involuntarily suggest, sometimes help him, and somewhere even openly teach. We all started once. All these actions require considerable effort that could be applied for its intended purpose - in developing the project, but without training new specialists it will be harder.

So, in order to minimize these costs, let's "create" a good, and possibly an ideal novice programmer, with high potential and bright horizons.

The ten tips offered here do not pretend to originality and are mainly based on my small five-year experience of development. So, let's begin.
')

1. Be independent

If you have any question, and you do not know how to deal with it, first try to explore it yourself. Do not expect constant help from colleagues - they have enough work without you. Use the full power of search engines, specialized resources (for example, stackoverflow), professional blogs, developer forums, and of course Habr. Most of the typical “rakes” can be circumvented by various effective options, and there are dozens of ready-made solutions for solving basic problems. Just go and get it.

2. Know how to ask

If the independent search for an answer to the question did not produce results and you have been stomping for a long time, then do not be afraid to ask for help from more experienced colleagues.
Before you ask your question, do not rush, try to articulate it as clearly as possible. It is possible that the answer to the question is already covered in the question itself.
If you need to show any algorithm or scheme and point to "dark", problem or weak points, then try to use special tools (for example, UML ) for the image, this will effectively demonstrate the subject matter, as well as give you an addition to the design skill.

3. Constantly develop

We all witness the amazing pace of technology development. This is especially true of our business. Remember that much that was taught to you in the university, unfortunately can very quickly become outdated, become irrelevant. Fortunately, this does not concern the basic technical sciences. Be prepared for the fact that you will constantly have to comprehend something new, understand new innovative technologies and explore new trends all the time, which you will play in the role of a software developer. In addition, the younger generation does not sleep and creates competition. It is also important to understand that in order to efficiently and quickly master the technology, you need to constantly train the learning skill itself and not allow it to atrophy.

4. Do not be afraid to learn to evaluate

Remembering myself, at first I had a peculiar fear of assessing the task at hand. And with varying success, I missed, then I missed. I can reassure you at once, this task is so not simple that to solve it there are many complex techniques developed by more than one generation of specialists, and this is not only in IT. It seems to me that I have pretty scared you. Well, never mind, catch a couple of punches with a rake, give a beer to more experienced colleagues to find out their know-how, and you will have a basic skill of estimating tasks. Over time, gaining experience in solving various tasks, the picture will be very clear, for example, you will easily understand that it will take 6 hours plus 2 hours to take risks to implement the whistle-puff on jQuery. So this is a gainful thing.

5. Do not forget about the whole picture of the system.

When developing a new class, implementing a pattern, or correcting a cunning bug, do not forget about the whole picture of the software being created. Sometimes it happens that as a result of excessively enthusiastic work on some part of the code the visibility of the project is reduced, which leads to potential conflicts in the code, ridiculous errors and provokes the appearance of bottlenecks in the system.
Try to train a common vision of the picture through printed out on paper class diagrams (or its key parts), algorithms, complex data structures and other important components. In the event of confusion, this will help to quickly refresh the general idea and return to a healthy rhythm.

6. Moderately use ready-made solutions.

Probably nowhere else than in IT, such a huge number of bicycles are invented. This has both its advantages and frank cons. It is important to understand that if there is a sufficient amount of time, the task is not difficult and you have a good idea of ​​what you need to do, then you can write your own implementation that will harmoniously fit into the overall style of the project. At a minimum, this will give you an understanding of the processes from the inside, and of course practical experience. However, if time is running out, or the task is successfully solved with complex tools, for example, a popular framework involved in a project or some component from the library, then it is more efficient to use a ready-made solution. Consider that there may be situations in the future that may require optimization or expansion of your chosen solution.

7. Appreciate your work

Do not approach the task as a favor, otherwise you will only be harmed. Appreciate what you create, because you are creating and creating. Do not take a couple of minutes for the design of the code, according to generally accepted standards in the company or team. Clean out your result, be pedantic, cultivate this habit in yourself if it is not already there. For example, if you have “slipped” an interface element a few pixels to the right, then do not take the time to correct it, returning it to its place. Be sure to check and run the result of their activities, do not shift everything on the shoulders of the already loaded quality control engineers. As a result, you will definitely be noticed and appreciated, and that's all, because you value what you create.

8. Do not be lazy

Comments on Habré, watching videos on YouTube and other Skype during idle times at work is not bad, but it is much better to do something useful for both myself and colleagues. Read about an interesting technology that you can potentially apply to the project? Try it in practice - load it with tests in the sandbox, compare the results with similar technologies already used, or write “hello world” in the form of a blog engine or another trivial (but not too) task. It is also good in your free time to create something of your own: whether it is a simple greasemonkey script for your favorite web resource, or an original thought for a startup that hasn't given rest for a long time. In any case, a great advantage after all this will be maintaining the working tone and, as a result, good results in solving new problems.

9. Know how to state your thoughts correctly.

Try to express your thoughts briefly and clearly. No wonder they say that brevity is the sister of talent. If you do not just have to and the verbal "water" flows without stopping, then practice "on cats": write down the idea on paper, try to carefully highlight the basic thesis and, through gradual deletion of "extra" and "embellishing" words and phrases, clear it. Treat this as a game - with excitement, enthusiasm and interest. In the role of the second "cat" appears, oddly enough, Twitter, with its restrictions on the message.

10. Do not limit yourself to your role.

Initially, you will be engaged in the implementation of tasks. And sometimes it will seem to you that the manager is wrong, the customers are stupid, and the team leader is a tyrant and a usurper. Often this is just an illusion that can pretty spoil relations in a team and even hurt your reputation. To understand the motives driving them, try to put yourself in the place of a person, think about how you would act in their place, having a number of restrictions and duties. Most often, a person can be understood, otherwise you simply have no luck, and then you will make efforts for productive communication. The same applies when you grow up and change the role of a developer to one that was previously incomprehensible. In this case, just remember yourself, and try not to put pressure on the already tortured programmer.

Afterword

For some, this is a matter of course, and, perhaps, a well-known captain will hang shoulder straps on me. But, as practice shows, unfortunately, not everyone understands this and, as a result, stupid bumps are stuffed both for themselves and their colleagues. But this could have been avoided.

Other helpful and constructive advice is warmly welcome in the comments. I am sure that everything will be interesting, both on the basis of his experience, and the advice received in instruction from more experienced and wise colleagues.