Programmers test whether they have overcome these obstacles

The most difficult task of a programmer has little to do with writing code. Coding is the practice of logical thinking, which is relatively simple compared to other tasks in a programmer's daily work. If you think you are still an average programmer, please make sure you have overcome the following obstacles to advancement before you can truly enter the ranks of experts.

1. Explain what you are doing

Explaining the software development process is a difficult thing. People who are not programmers may know a lot about programming, but they obviously don't know how to program. To them, our lives consist of sitting in front of a keyboard in a dark room, consuming coffee.

You will meet people among your friends, family and colleagues who will think that coding is not the right career.

2. Visualize the software solution

Based on some brief requirements - usually with little knowledge, you need to design data structures, software architecture, code algorithms, communication protocols, and All other components of solutions to business problems. Then you need to express them in terms that a layperson can understand, and you need to submit them to the client within a specified time.

Few programmers can do this well.

3. Evaluate the construction period

This is the source of pain for programmers. Before the development task is completed, it is absolutely impossible for you to determine the time required to complete the task. Maybe the program is very similar to what I wrote before, but the environment has changed, the problems have changed, and the constraints have changed.

Experience will provide a certain degree of judgment, but most programmers are accustomed to underestimating the difficulty of problems. The reason for this is that they only consider the coding aspect and ignore other things on the to-do list.

4. Maintain other people’s code

There may be 10,000 solutions and 10,000 ways of writing a problem. Taking over code written by others means that you have to spend countless hours exploring thousands of lines of code to understand the original author's ideas. And if it's half a project left by a programmer who doesn't believe in comments and documentation, the trouble is even greater.

5. The fuzzy spread of software boundaries and strange functional requirements that make people vomit blood

Although agile development methods provide a certain amount of preparation space for the expansion of software scope, this does not have any effect. role - especially when you encounter some functional requirements that arise from a whim. You know this is bound to fail. Your team knows this is bound to fail. But the customer thinks it's great, and when failure inevitably occurs, it's all your fault for not understanding their true intentions.

6. Find the balance between under-optimization and over-optimization

Complex software will never be perfect; there will always be some better solution. You can keep optimizing endlessly, which is why software projects are never completed ahead of schedule.

On the other hand, the mentality of “That’s enough—I’ll optimize it in the future” is also common. The code works fine today, but you know it might have trouble or not work tomorrow. Of course, you don't need to modify it, it will be left to the next unlucky programmer.

7. Test your code

You have also written unit tests, and the software has been submitted to the test group, but the bugs still exist...

Software is complex and may Contains thousands of lines of code. There may be millions of various interactions and logical paths in the system; you can't possibly test them all.

Similarly, software will interact with different software on different platforms under different conditions. You can't measure them all.

Writing good unit tests is boring and hard work. Ideally, tests should be written before development begins - but how do you explain to the customer why four weeks have passed and there is still no usable software?

Unit tests cannot cover every problem point. In an ideal world, there would be an independent team writing tests and actively identifying problems. Unfortunately, for most projects, this is too costly and time-consuming, so the development team is left to write the tests. The development team subconsciously avoids many extreme edge cases.

Programmers like to handle all problems in a logical way. But users are rarely like this. They'll uncover problems you'd never expect.

8. Write software documentation

Writing documentation for code is a laborious and time-consuming task. Few programmers are good at this, few programmers like this, and few programmers take the time to read them.

9. Dealing with IT issues

You study technology every day. You may be an HTML or PHP programmer, but you are likely to encounter problems such as hard drive corruption, driver conflicts, or software crashes. It is not your primary responsibility to fix these things, but unless you fix them, you will not be able to continue your development work.

Unfortunately for people outside the IT circle, programmers are supposed to be people who are proficient in both software and hardware. When they encounter a problem, they solve it themselves without spending any time and come directly to you. No matter what the problem is: you're a computer person, you know how to import a budget into Sage, how to configure Oracle, or why they can't send an email on their BlackBerry.

Of course, these interruptions cannot be the reason why you can't complete your work, and there is no reward, right?

10. Dealing with people's problems

The above problems They can all be summed up as “people problems”. Few laypeople would advise a pilot on how to fly a plane or an electrical engineer on how to wire a plane. But many people will enthusiastically and bravely suggest how to develop software.

I believe there is no good solution for these people. You need to accept the fact that half of the people in the world have below average intelligence!