A programmer's toughest task has little to do with writing code. Coding is an exercise in logical thinking that is relatively simple compared to other tasks in a programmer's day-to-day work. If you consider yourself a mediocre programmer, make sure you have overcome the following obstacles before you can actually enter the ranks of the masters.
1. Explain what you are doing
Explaining the software development process can be difficult. Those in non-programmer careers may know a lot about programming, but obviously, they don't know how to program. To them, our life is consuming coffee in front of a keyboard in a dark room.
You will meet someone in your friends, family and colleagues who will think coding is not the right profession .
2. Visualize the software solution
Based on some brief requirements— often half-understood— you need to design data structures, software architectures, code algorithms, communication protocols, and all the other components of a solution to a business problem. Then you need to express them in a layman-understandable term and submit them to the client within the allotted time.
Few programmers can do this well.
3. Assess the duration
This is the source of programmer pain. It is absolutely impossible for you to determine how long it will take to complete a development task until it is completed. Maybe the program is very similar to what was written before, but the environment has changed, the problem has changed, and the constraints have changed.
Experience provides some 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 the other things on this to-do list.
4. Maintain other people's code
There may be 10,000 solutions and 10,000 ways to write a problem. Taking over code written by someone else means spending countless hours exploring thousands of lines of code to understand what the original author was thinking. 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 blurring of software boundaries and strange functional requirements that make people vomit blood
While agile development methods provide some headroom for expanding the scope of the software, it doesn't do anything -- especially when you encounter some functional requirements that arise on a whim. You know that doing so is bound to fail. Your team knows that doing so is bound to fail. But the client feels fine, and when failure inevitably occurs, it's all your fault because you didn't understand their true intentions.
6. Find a balance between under-optimization and over-optimization
Complex software is never perfect; there is always something better. You can optimize endlessly, which is why software projects are never finished ahead of schedule.
On the flip side, the "that's it - I'll optimize it later" mentality is also common. The code works fine today, but you know it might be troublesome or unusable tomorrow. Of course, you don't need to modify it, it will be left to the next hapless programmer.
7. Test your code
You also wrote unit tests and submitted the software to the test team, but bugs still exist...
-
Software is complex and may contain thousands of lines of code. There may be millions of interactions and logical paths in a system; you can't test them all.
-
Similarly, software interacts with different software on different platforms under different conditions. You can't measure everything.
-
Writing good unit tests is tedious and hard work. Ideally, the tests should be written before development begins - but how do you explain to the client why four weeks have passed and there is still no software available?
-
Unit tests don't cover every problem point. In an ideal world, there should be an independent team writing tests and actively finding problems. Unfortunately, for most projects, this is too expensive and time consuming, so the development team is used to write the tests. The development team subconsciously avoids many extreme edge cases.
-
Programmers like to deal with all problems in a logical way. But users are rarely like that. They will find problems you never expected.
8. Write software documentation
Documenting code is a laborious and time-consuming job. Few programmers are good at this, love it, and few programmers take the time to read them.
9. Deal 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 disk corruption, driver conflicts or software crashes. It's not your primary responsibility to fix these things, but unless you fix them, you won't be able to continue your development work.
Unfortunately for people outside of the IT world, programmers are supposed to be well-versed in both hardware and software. When they have a problem, they don't take the time to solve it themselves, they come to you directly. No matter what the problem is: you're on a computer, you must know how to import a budget sheet into Sage, how to configure Oracle, or why email isn't working on their BlackBerry.
Of course, these interruptions must not be a reason for you to not get the job done, and there is no pay, right?
10. Dealing with people problems
All of the above problems can be summed up as "people problems". Few laypeople would advise a pilot on how to fly a plane or advise an electrical engineer on how to wire. But a lot of people will be enthusiastic and brave to suggest how to develop software.
I believe there is no good way for these people. You need to accept the fact that half of the world's intelligence is below average!