Tips for novice programmers

In this short article, we want to share tips that we would have given 10+ years ago to dedicated software developers. For some, all this may seem obvious.

1. Thoughts are critical.

In my practice, there was a case when I was given the task to write a service and offered to take the architecture of a similar service that was written by a technical lead. Everything went well, everyone, including the author, watched this, but at the final review it turned out that the approach that I took as a basis has a number of significant drawbacks, it should not be used and everything needs to be done radically differently. In the end, everything was redone, but the deadlines were missed, and the responsibility was on me. Because I am a little slow-witted, I stepped on this rake a few more times, until I began to be critical and deliberate about all approaches, decisions, advice, and in general everything that gets into my brain. You should not use someone else’s approaches or solutions, even if the authors are very authoritative. Trust is good, but not in this case.

2. Make the machine repeat your actions.

When you think through and program an algorithm, you describe the actions that a person would take to achieve a result, and the machine only repeats them. And when you get stuck on something, think about what a person would do, you in particular. Even though this is a direct basis for programming, I often forgot about it.

3. Colleagues are a real treasure.

Over the years of working in different teams, I learned one simple truth for myself: the people you work with are a treasure. Why? Because they help you grow. When my opinion did not coincide with the opinion of a colleague and I was confident that I was right, I quickly became annoyed. This is a very wrong approach. It is much better to remain calm and look for arguments. If you can skillfully argue your position, this will help you improve your skills and gain respect from colleagues, and this is important. Especially good if the search for arguments seems difficult. If it turns out that you were wrong, it’s even better because you will learn a valuable lesson for yourself, and you can also strengthen your skills. You can’t be always right in the end)) Colleagues can have a different vision and this is excellent. Learn from them. They are the best teachers.

4. Practice more.

The result of the programmer’s work in Peiko Company is, foremost, the code. Knowledge and understanding of the theory are necessary, but just thinking in the head will not make the machine perform the desired actions. Program as much as possible. You study an algorithm – program it, you decide to learn how to write multithreaded programs – write multithreaded programs, if you just want to understand the primitives of thread synchronization – write some simple program, even a training one, where you need, say, a semaphore. But here you should not go to extremes. If you need a red-black tree, for example, and there is a ready-made implementation of it, then it is not necessary to sit and program their rotations, a conceptual understanding is enough; otherwise, you will get bogged down in details and spend too much time, or maybe you will fall into a slight depression. This tip is about not being a theoretical programmer in the first place.

5. Remember business goals.

When you solve a problem, remember that you are solving a very specific business problem, and not just programming a spherical horse in a vacuum. Imagine yourself in the place of the end-user and the owner or manager of the product, and you will understand what you are doing and why.

6. Be mindful of the big picture of the system.

If the previous advice concerned the product picture, then this one is technical. When you write a component, be it a module, a class, or a service, don’t forget that it’s still a system component, try to keep the big picture in mind. Remember this, it’s important.

Leave a Comment

Share via
Copy link
Powered by Social Snap