What you don't know about when you decide to become a programmer

In this article, I will share the discoveries that await students and aspiring programmers who decide to devote themselves to development. If you still want to learn to program, you should start with the online courses on our platform.

Everything is thought through in advance

Students imagine development in the following way: there is a customer who comes to the programmer and gives him/her a technical specification, which describes everything that has to be done and how it has to be done. The programmer only has to write the code. In reality, even if there is a requirement specification, it is far from complete.

There is no one person who knows exactly how things should be done. Any pre-conceived logic is shattered by reality. This is why agile methodologies are so popular in development, where a product is not made according to the TOR from start to finish. With their help, the product is developed in small portions which are constantly given to users to make sure of the correctness of decisions made and the direction of development. A software product is a living organism that is constantly evolving based on experimentation and feedback. All the products you know are developed continuously.

Programming is sometimes compared to construction, but it is not a good comparison. In the case of construction, everything is planned in advance, and the developer is always in a state of uncertainty - he does not know exactly where the project will develop.

Programmers write code all the time

Tasks given to programmers are usually described in terms of ordinary users' behavior: "Add confirmation of login by SMS". In general, this is clear, but there are many questions about the working conditions and technical implementation. In what situations is confirmation needed? Can it be disabled? And if it is the subscriber of other countries? And if a person has lost the phone? And what service to send SMS?

Some of these questions will be covered in the terms of reference, but not all. And this is not done on purpose. Only the programmer understands the complexity behind such tasks. It is his/her direct duty to point out the points which have been forgotten or will be difficult to implement. As a result, the task can be greatly simplified, because the original version will take a lot of time to develop, which is expensive.

All this requires negotiation, digging through documentation, and interacting with people from external products and other parts of the system. The more experienced the developer, the more they do this. And the code? The code is written at the end when all the necessary details are figured out. Writing 20 lines of code can take days of discussion.

The customer is the one who pays

The real customer of development is the user of the product; it is his or her convenience that the programmer should think about first when starting the task. The developer gets a task because the customer has some problem that needs to be solved. Therefore, in an ideal situation, the developer either communicates with the user or, with those who communicate with users.

In either case, the developer should have a clear understanding of how the customer interacts with the product. That's why, in many companies, the use of branded products by employees is a prerequisite for hiring. In other companies, developers move into the support department from time to time to know the needs and pains of customers. If a programmer does not know this, he or she can easily get into the business of building air castles where simple and straightforward solutions are needed.

Programmers don't make mistakes

Beginner developers are afraid of making mistakes and try to do everything right at once. However, if you decide to become a programmer, you have to forget about perfectionism. Do you want to write a working code the first time? Alas, you won't. You will find a lot of details you forgot to think about or only a part of the users will get them in the working code. In development, mistakes are an inevitable part of an application's life. What is more, developers spend much of their time on fixing both others' and their own errors.

Experienced developers make a few fewer mistakes than beginners, but they fix them quicker. This is aided by their observation and automated tests, which constantly check the code.

Good code considers everything

A common problem in development is 'over-engineering', where solutions are created that take into account all possible scenarios, even those not yet in use. Or many people like to make the code fast, in the hope of a heavy load, which only some projects come up with.

In reality, you should start with the simplest answer to a user problem - a solution that can be implemented in a short amount of time. It does not matter how good or bad the solution is. Next, the advantages and disadvantages of the chosen approach are analyzed and something is added to the solution to complicate it and make it better at the same time. And so it is step by step.

We do not end up with one solution, but several solutions, each with its own advantages and disadvantages. And only after that, we must decide which of them to implement. If the programmer sees only one way to implement his task, he does not understand it.

A programmer must code

Seems to be the most paradoxical fact of all described: A good developer is not the one who codes the most. An experienced developer can solve problems without writing a single line of code.

Any code has to be maintained, it has to be monitored. In development every decision binds you: the code restricts the choice of subsequent decisions because in programming all subsequent decisions depend on previous decisions. Over the years a product accumulates a huge number of architectural decisions from which you can neither go left nor right. And the more code you write, the wider this trap gets.

If you can write no code, you don't have to write it. When a problem arises, an experienced programmer will always find out what the existing system can do and will not complicate it if it is not necessary. For example, sometimes you can solve a problem by removing code rather than creating it.