How to be a good programmer

It happens that it’s hard for beginners to understand where to go next, what to do. It happens that such problems arise not only for beginners.



Many people understand where to move, what to do, comes on a hunch. And it takes a lot of time. Time is the most important human resource that must be protected and not scattered by it. And so as not to lose this time, I want to share some thoughts, tips.

These tips seem to many to be "captain's" and obvious, especially to experienced programmers, but this should not negate their correctness.



Constructive criticism is welcome.





Be honest, don't be afraid to ask questions and look stupid.

• The device operating systems, compilers, interpreters, the architecture of recognized software systems and systems .
  
  Any executable code is created and executed in some kind of environment. Not knowing this environment, it’s hard to create a good product.
• Algorithms, data structures, discrete mathematics .
  
  In our real life, there are programmers who feel great not having the listed knowledge in detail. For example, to solve many applied problems of enterprise applications this is quite enough. The implementation of many algorithms is already built into the platform. For example, sorting, searching, etc.
  
  But when it becomes necessary to solve more complex problems, the invention of the bicycle may begin. Knowledge of algorithms can greatly simplify the task.
• Other languages, development and interaction tools .
  
  Different languages ​​solve different problems. For example, R, MathLab will do an excellent job with math problems. Without HTML markup languages, XML cannot develop a web application.
  
  And knowledge, for example, of C or assembler will allow you to develop a product that will work most effectively with hardware.
  
  Learning new languages, understanding their philosophy, and not just syntax, will expand the scope of thinking and understanding of programming principles. Knowledge of only a few "basic" languages ​​will allow in the future to easily learn new ones.
  
  
• Foreign code, documentation and description .
  
  Studying someone else's code, you can discover a lot of interesting things. Other approaches and programming methods that can be adopted. Any newbie should do this in order to quickly join the development team.
  
  And if, before you start looking for the cause of the error in someone else's code, read the documentation or description, you can significantly reduce the time it takes to search.
  
  
• Feedback on the review of your code .
  
  You can consider this as getting advice on improving the code and, moreover, for free.
  
  It is also a good way to “communicate” between programmers. Especially if the development team is distributed or there are strongly expressed introverts in the team.
  
  It also looks like learning someone else’s code, but on the other hand, the coin. When both: the reviewer and the peer, they gain experience and learn something new.
• Development methodology .
  
  Methodologies are key to managing software development.
  
  The choice of a specific methodology depends on many factors: the size of the team, the specifics and complexity of the project, the stability and maturity of the processes in the company, the personal qualities of employees and many others. The success of the project largely depends on this choice.
  
  
• The subject area with which you work .
  
  Not knowing the principles of the process, what and how people, future users of the product do in this process, it is almost impossible to automate it and even better.
  
  You need to try to understand what the end user "cooks".
  
  

You can read a bunch of books, do a thousand tasks, but without practice you can’t achieve good results.

• Present your ideas .
  
  In order for the future product not to be developed for itself, but to bring benefits, you need to be able to present your ideas. At the same time, thinking about the goals and expected results that the business customer, the end user is pursuing. Otherwise, the idea is not to sell.
  
  With a good presentation of the idea, you can get good advice even before its implementation. Even if the idea fails to sell the first time.
• Write readable, understandable, structured, and extensible code .
  
  If necessary, develop functionality, provide product support, some time later you may need to quickly figure out the code yourself or someone else.
• Design code with the expected behavior .
  
  The released product must be reliable and maintainable.
• Test your code yourself .
  
  This item does not mean that you need to test instead of the tester. This paragraph indicates that the developer should submit the code for testing having the confidence that he has done everything necessary for the tester to catch as few bugs as possible.
  
  When developing the code, it can be assumed that the final product will be the aircraft control system, during the test flights of which the system designer must be on board.
  
  
• Practice more .
  
  As in any other business, experience comes only with practice. Mastering programming is not the end of a university or some course. This is a long way to life. And it’s important not to stop there.

Without communication, you are like a good book in a "dead" language. It is, but no use.

• Help, share knowledge .
  
  There is an important “But!”: Do not do it for another.
  
  It is necessary to suppress the desire "to do it yourself easier than to explain."
  
  The more often you explain, rather than do for another, the more people around you will be able to learn something new.
• Find yourself a Padawan / mentor and become his mentor / Padawan .
  
  Underline whatever applicable.
  
  Despite the apparent contradiction of the phrases, the essence lies in one thing - the mentor and Padawan grow and develop together. This is the main and essential difference from the interaction of roles “teacher - student” learned from school. When in most cases this interaction comes down to the formula "I'm the boss, you're a fool."
• Participate in programming championships .
  
  This will allow you to carry out a slice of knowledge, identify gaps, strengths and weaknesses, look at yourself from the outside.
• Communicate, work in a team of gurus like you .
  
  In this case, two components can be distinguished:
  
  - the first is the refinement of technical skills;
  
  - the second - honing communications, communication skills.
  
  Both components are necessary for becoming a professional. And both need to be honed.

Literature and references

The links provided are not necessarily read. What book, article, material to read, where you need to catch up - this is purely individual. Everyone must decide for himself.

The links below are rather some starting points from which you can start.

• R. Gandapas. Ready for the performance! Presentation Designer.
• E. Hunt, D. Thomas. The pragmatic programmer. The path from apprentice to master.
• S. McConnell. Perfect code. Master Class.
• M. Fowler. Enterprise software architecture.
• T. Cormen, C. Leiserson, R. Rivest, C. Stein. Algorithms Construction and analysis.
• E. Tanenbaum, H. Bos. Modern operating systems
• R. Martin. The perfect programmer. How to become a professional in software development.
• I. Bubnov. 12 software development methodologies.