The hardest task of a programmer has little to do with writing code. Coding is an exercise in logical thinking, which is relatively easy compared to other tasks in a programmer’s day job. If you consider yourself an average programmer, make sure you’ve overcome the following barriers to advancement before you can truly enter the ranks of the best.
1. Explain what you’re doing
Explaining the software development process is a difficult task. People who are not programmers may know a lot about programming, but obviously, they can’t program. For them, our lives are spent sitting in a dark room at a keyboard sipping coffee.
You’ll meet people among your friends, family, and colleagues who don’t think coding is the right profession.
2. Visualize the software solution
Based on a few brief requirements — often sketchy — you 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 layman’s terms, and you need to deliver them to the client in a given time frame.
Very few programmers can do this well.
3. Assess the duration
This is a source of pain for programmers. There is absolutely no way you can determine how long it will take to complete a development task until it is completed. Maybe the program is similar to what it was written before, but the environment has changed, the problems have changed, the constraints have changed.
Experience provides some discretion, but most programmers tend to underestimate the difficulty of a problem. The reason for this is that they only consider the coding aspect and ignore the other things on the to-do list.
4. Maintain other people’s code
There may be 10,000 solutions to a problem, 10,000 ways of writing it. Taking over code from someone else means spending countless hours digging through thousands of lines of code to understand the original author’s thinking. And if it’s half a project left behind by a programmer who doesn’t trust comments and documentation, it’s even worse.
5. The blurring of software boundaries and strange functional requirements that make people vomit blood
While agile development methods provide some preparatory space for software scope expansion, it doesn’t help – especially when you encounter functional requirements that are created on a whim. You know you’re bound to fail. Your team knows this is a surefire way 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. Strike a balance between under-optimization and over-optimization
Complex software will never be perfect; There is always something better. You can optimize endlessly, which is why software projects are never finished ahead of schedule.
On the other hand, the “This will do — I’ll optimize it later” mentality is also common. The code works today, but you know it might get in trouble or not work tomorrow. Of course, you don’t need to fix it, it will be left to the next hapless programmer.
7. Test your code
Unit tests are written, software is submitted to test groups, but bugs still exist…
Software is complex and can contain thousands of lines of code. There may be millions of interactions and logical paths in the system; You can’t test them completely.
Similarly, software interacts with different software on different platforms under different conditions. You can’t measure all of them.
Writing good unit tests is tedious and hard work. Ideally, tests should be written before development begins — but how do you explain to a customer why four weeks have passed and still no software is available?
Unit tests don’t cover every problem point. In an ideal world, there would be an independent team writing tests and actively finding problems. Unfortunately, for most projects, this is too costly and time consuming, so a development team writes the test program. Development teams subconsciously avoid many extreme boundary 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 task. Very few programmers are good at this, like this, and very few programmers take the time to read it.
9. Address 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. Fixing these things is not your primary responsibility, but unless you do, you won’t be able to continue your development work.
Unfortunately for those outside the IT world, programmers are supposed to be proficient in both software and hardware. When they have a problem, they don’t take the time to solve it themselves, they come straight to you. Whatever the problem: you use a computer, you know how to get a budget into Sage, how to configure Oracle, or why they can’t send email on their Blackberry.
Of course, these interruptions are no excuse for not getting your work done, and there’s no pay, right?
10. Deal with people
All of these problems can be summed up as “people problems”. Few laymen would advise a pilot how to fly a plane or an electrical engineer how to wire it. But many people will cheerfully and courageously suggest how to develop software.
I’m sure there’s nothing good that can be done for these people. You need to accept the fact that half the world’s intelligence is below average!
Recommend an exchange learning group: 650385180, which will share some veteran architects recorded video: Spring, MyBatis, Netty source code analysis, high concurrency, high performance, distributed, microservice architecture principles, JVM performance optimization these become the architect’s necessary knowledge system. You can also receive free learning resources, which have benefited a lot at present:
Note: like friends can like and follow, learning progress together