Ten Tips for Beginner Programmers

Foreword

It’s good when you work with a person who knows a lot about his business. But what if it happens to work with a colleague whose experience is not so great. This is especially true of professional and personal qualities. Involuntarily I have to prompt, help him in places, and somewhere even openly teach. We all once started. All these actions require considerable efforts that could be applied for their intended purpose - in the development of the project, but without the training of new specialists it will be harder.

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

The ten tips offered here do not claim to be original and are mainly based on my short five-year development experience. So, let's begin.

1. Be independent

If you have a question and don’t know what to do with it, then first try to research 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 Most of the typical "rakes" can be circumvented by various effective options, and there are dozens of ready-made solutions to solve basic problems. Just go and get it.

2. Know how to ask

If an independent search for an answer to a question has not yielded results and you have been treading your feet for a long time, then do not be afraid to ask more experienced colleagues for help.
Before you ask your question, do not rush, try to formulate it as clearly as possible. It is possible that the answer to the question is already 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 the image (for example, UML ), this will allow you to effectively demonstrate the subject of the question, and also give you an increase in design skill.

3. Constantly evolve

We are all witnesses to the stunning pace of technology development. This is especially true for our field of activity. Remember that much that was taught to you at the university, unfortunately, can very quickly become outdated, become irrelevant. Fortunately, this does not apply to fundamental technical sciences. Be prepared for the fact that you constantly have to comprehend something new, to understand the latest innovative technologies and explore new trends all the time that you will act as a software developer. In addition, the younger generation is on the alert and creates competition. It is important to understand that in order to effectively and quickly master technology, you need to constantly train the learning skill itself and not let it atrophy.

4. Do not be afraid to learn to evaluate

Remembering myself, at first I had a peculiar fear of evaluating the task. And with varying success, I sometimes missed or hit. I can immediately reassure you, this task is not so simple that for its solution there are many complex methods developed by more than one generation of specialists, and this is not only in IT. It seems to me that I pretty scared you. Well, never mind, catch a couple of rake shots, treat beer to more experienced colleagues in order to find out their know-how, and you will have the basic skill of task optimization. Over time, gaining experience in solving various problems, the picture will be very clear, for example, you can easily understand that it will take 6 hours plus 2 hours for risks to implement the jQuery whistle-puff feature. So this is a profitable business.

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

When developing the next class, implementing a pattern or fixing a tricky bug, do not forget about the whole picture of the created software. Sometimes it happens that as a result of overly enthusiastic work on a certain section of the code, the visibility of the project is narrowed, which leads to potential conflicts in the code, ridiculous errors and provokes bottlenecks in the system.
Try to train your overall vision through class diagrams (or key parts) printed on paper, algorithms, complex data structures, and other important components. This will help, in case of confusion, to quickly refresh the general idea and return to a healthy rhythm.

6. To the best use ready-made solutions

Probably, nowhere more than in IT has such a huge number of bicycles been invented. This has its advantages as well as frank cons. It is important to understand that if there is enough time, the task is not difficult and you have a good idea of ​​what to do, then you can write your own implementation, which will harmoniously fit into the overall style of the project. This will at least give you an understanding of the processes from within, and of course practical experience. However, if time is running out, or the task is successfully solved by complex tools, for example, the popular framework involved in the project or some component from the library, then it is more efficient to use the ready-made solution. Keep in mind that there may be situations when in the future you may need to optimize or expand 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 create and create. Do not take a couple of minutes to complete the code, according to generally accepted standards in the company or team. Scrub your result, be pedantic, cultivate this habit in yourself, if it is not already there. For example, if you have "moved out" the interface element a few pixels to the right, then take the time to fix it, returning it to its place. Be sure to check and run the result of your activity, do not shift everything onto the shoulders of the already busy 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 the hub, watching videos on YouTube, and other Skype during downtime at work is not bad, but it is much better to do something useful for both yourself and your colleagues. Have you read about an interesting technology that could potentially be applied to a project? Try it in practice - load the tests in the sandbox, compare the results with already used similar technologies, or write “hello world” in the form of an engine for a blog or another trivial (but not too) task. It’s also good to create something of your own in your free time: whether it is a simple greasemonkey script for your favorite web resource, or an original thought for a startup for a long time that has not given rest. In any case, a huge plus after all this will be maintaining a working tone and, as a result, good results in solving new problems.

9. Be able to express your thoughts correctly

Try to state your thoughts concisely and clearly. No wonder they say that brevity is the sister of talent. If you have more than just a verbal “water” pouring nonstop, then train “on cats”: write down a thought on paper, try to carefully identify the basic thesis and, through the gradual deletion of “superfluous” and “embellish” words and phrases, clear it. Treat it like a game - with excitement, enthusiasm and interest. Strange as it may seem, the second “cat” is Twitter, with its restrictions on messages.

10. Do not limit yourself to your role.

First, 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 usurper. Often this is just an illusion that can prettyly spoil relationships in the team and even tarnish your reputation. To understand their motives, try to put yourself in the place of a person, think about how you would act in their place, having a number of limitations and responsibilities. Most often, a person can be understood, otherwise you are just out of luck, and then make an effort 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 the shoulder straps of the well-known captain will be hung on me. But, as practice shows, unfortunately not everyone understands this and, as a result, stuffs stupid bumps to both themselves and their colleagues. But this could have been avoided.

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