Everything you need to know before you become a decent developer
Hey, friends in front of the screen, everyone, I am a programmer, and I have been developing for a long time, I also met a lot of companies and people. I feel it is necessary to write an article about the soft power of programmers in the workplace. I hope it will be helpful to students who want to do well at work, and it can be regarded as making my little experience shine.
The company is a melting pot, with all kinds of seniors and newcomers. No one can summarize any company in one sentence. However, no matter which company you are in, the problems encountered in development are actually similar, such as:
Postpone
Hard coding process
Colleagues do not cooperate
Many bugs after testing
I work hard, but I always do bad things
What’s more difficult is that the problems often appear together. Originally, the work at hand had to be postponed, and urgent online issues had to be dealt with. Colleagues who were connecting with each other did not cooperate and couldn’t handle it. It’s crazy, isn’t it?
First determine your identity
who are we?
“software engineer”
What are you doing?
“The code runs up and tests and changes the bug and finishes it”
Yes, but this is a software engineer in an ideal environment. The environment of a company composed of people is very complex, and it faces far more problems than coding. For example, an advertisement in an online APP cannot be displayed, which may be caused by various reasons such as the client, server, database, script, and on-site environment. If the developers who were called to come to see the problem jumped into the code as soon as they came up, they might not be able to extricate themselves.
“But I am a developer, what do I not look at the code?”
Look at the clues~ If you first try to collect “confessions” from witnesses, confirm the phenomenon and frequency. Before this, who has moved where and what functions have been launched.
If you learn that this is a function of advertising filtering by someone from another development group, you don’t even need to read a line of code, and you can solve it by adjusting the filtering configuration. Isn’t it beautiful?
If you want to do a good development, you must first determine your goal, that is, what identity should I exist in this company. We can’t just be a tool person who knows how to code, we should become:
The problem terminator that promotes the smooth profitability of the company’s products (just familiar with programming)
Any problem will be resolved as long as it passes through you. The solution may be coding, designing, investigating, and finding other people for help. In this way, your position in the company is not limited to a programmer, and the possibility of the future is much greater. Don’t shirk because of the non-technical abilities involved, because then you become a tool man.
Don’t rush, plan what to do first
Whether it is an iterative development task, or solving online bugs, setting up an environment, or even helping the team apply for development equipment. It’s not recommended to do it right away regardless of the size of the matter. It’s best to calm down and think about whether there is a better plan for this matter, how to arrange the order to complete it better, and it will not affect your current task, and even help you. Other jobs.
All roads lead to Rome, but only one road is the most suitable. If you simply hope that all problems will be completed at once, it will inevitably interrupt your current progress, and you will not be able to achieve the hope of “all things will be completed at once”.
Reasonable time management.
First of all, you need to have a list of things you have to do, including their deadlines, for example:
Now I have received a task of “Reporting the log function to be delivered in 7 days”
And you have 3 existing tasks:
Refactor the log tool to beautify the output and deliver in 3 days
Participate in the requirements review of the next iteration to be delivered in 2 days
New features added to the shopping cart delivered in 10 days
Obviously, it is inappropriate for you to “report the log” immediately, and it is best to put it after the “refactoring log tool”. If you do “report log” first, then “refactoring log tool” will inevitably affect “report log”.
Don’t worry if you want to start doing it after 3 days. First, ask if there are any changes in the product’s “Report Log” function to avoid information asymmetry and take precautions.
Mission planning
Different types of tasks require different planning:
The development plan is mainly pre-research, design (UML), joint debugging preparation (for example, appointment time with the docking person)
The planning for solving difficult bugs involves on-site investigation and communication, building a reproducible environment, and being familiar with code logic. (After knowing how to change, usually the changes will be small)
After these pre-work is done, the remaining code is simple, usually just a matter of time.
Reliable task dismantling and time estimation
No one wants to postpone the delivery of their work. In the company, you will find that some people often postpone, but some people can always complete it on time. This is inseparable from the ability to disassemble and estimate tasks.
After completing the design of the task, it is clear what needs to be done. At this time, the knowledge should be recorded as soon as possible as your next work outline. Then each subtask is refined and divided into executable Tasks. In hours, about 3 hours is recommended for each task.
For example, if the client needs to log in logic, it can be split into:
UI-Login Interface Framework 2
UI-input box 2
UI-Login button 0.5
Interface-login network interface format definition 2
Interface-login network interface joint debugging 3
Logic-Use the input to call the logic of the login interface 2
Logic-Jump to the page after login and exception handling 2
The numbers behind these tasks represent hours, which can be adjusted according to your personal speed.
These tasks can be entered into Excel to facilitate the total working hours to be fed back to the superior. Note that Excel should be provided as an attachment when reporting working hours to support your time estimation. It is also convenient for superiors to flexibly delete/add tasks.
The color of the grid is marked green every time a task is completed to facilitate tracking of progress. And you can also know how many hours you have left to finish, whether you need to speed up, or you can focus on more details or supplement unit tests.
Tasks are not only coding, but also the time for communication and familiarity with the business. In this way, the working hours you give will be relatively accurate, reducing the risk of delay. Consider “non-coding” tasks, because they are often overlooked. Try to reserve some time to deal with other interruptions encountered in the middle.
Be careful not to deliberately estimate a long time to Task, which will destroy the team’s trust in you. The establishment of trust is very difficult. It requires multiple output of work to establish trust, but a lie will break it.
With more and more estimates, you can refer to the previous results each time you estimate. You will be more accurate and the team will trust you more.
High-quality coding
The coding quality affects the bug rate after the test, and also determines how likely it is to fill the hole online in the future. So this is something that needs to be taken seriously.
However, since no one cares about the quality when coding, it rarely attracts attention.
Writing a single test is a good way, but unfortunately many companies don’t have time to write. Code review is also difficult to cover comprehensively, because the person who reviews may not be doing your thing, so he can’t find problems in business logic.
Sonarqube or lint actually does a lot of work to review code, such as whether the stream is closed, whether it is not empty, and so on. So the loopholes in the business can only rely on oneself at present.
This requires a full understanding of the module you are working on before coding. If not, add a Task that looks at the code when splitting the task. You have to know where the heart is before doing the surgery, right?
The skeleton of the code
Now that you have a coding plan, you can write comments or pseudo-code in the code.
It is recommended to write from the outside (abstract) to the inside (details). For example, for the APP upgrade function, you need to poll or receive MQ push to trigger the upgrade, then download the installation package, and install it automatically after downloading.
At this time, you can build up the necessary tools like UploadChecker, RabbitMqManager, Downloader, ApkInstaller according to the UML design that has been done.
You can define some functions or interfaces first but don’t implement them. Use code to connect them in series. In this way, your UML structure is shaped. As for the specific realization of these blanks, fill in step by step after the structure is stable. Every time you fill in a detail, the UML structure remains the same, and things are always going on steadily. The thinking is clearer and the bugs are naturally less.
But if you only create the UploadChecker class at the beginning and start writing from the implementation, it may appear that although the writing is very delicate, the interface exposed by it may not fit your design, and even lead to rework. And it’s easy for blind people to touch the elephant without realizing how UploadChecker interacts with other components.
Avoid changing the original logic
When adding code, it is bound to cause changes to the existing logic. If you find that the change is about to happen, don’t do it yet, first debug and track to figure out the original logic. Then, after adding the code, be sure to debug the logic again to make sure that the existing logic is not changed. Of course, if there are unit tests, things will be much simpler.
Note that if you are a back-end programmer, “this original logic” also considers other microservice projects.
As for the clichéd quality of coding syntax is not soft power, I won’t repeat it in this article.
More effective communication
Communication is a weakness that programmers shouldn’t. After all, we are not pure scientific research and technical personnel, but engineers. A PhD who studies mathematics every day, if you say that it is not good at words, it makes sense, but an engineer is tugging like what is going on.
Communication here involves communication with products, customers, subordinates, and leaders. If you communicate well, you will die. If you don’t communicate well, it’s really going to capsize in the gutter. You don’t know how to die.
Communication with product managers
For example, classic product managers and programmers are always ridiculed on the Internet that they are rivals. After all, one said “requirements” and the other said “cannot do it.”
But this is just an unscrupulous misrepresentation from the media.
In fact, as a development, many valuable suggestions can be made before the product project is established or the demand starts. For example, some requirements are inconvenient to achieve, it is best to communicate in advance. In fact, many places can be flexibly adapted, but you don’t need to draw all the prototypes, and even the UI is out of the picture. You can say that you can’t do it. It will inevitably hurt the harmony.
The needs review meeting can also solve this problem, but you must speak actively at the meeting.
In addition, when the product is actually in demand, it is not clear what can be done and what can not be developed. At this time, the development can actually take the initiative to say “I can do better here”, or “Here can make an animation to achieve better results”.
If you encounter a product demand that has already been formed at the project review meeting, if it is indeed difficult to achieve it, you must immediately bring it to the table to make it clear, at least there is still time to change it.
Client (leader)
Customers do not necessarily refer to the company’s commercial customers. Leaders, project managers, and products are generally the people who issue tasks, but for you, they are actually customers. For customers, they hope you can successfully complete the task. This will test your own judgment and planning ability.
Because of the promise of gold, it is really possible to say yes.
The one who fears the most is the people who “work hard” + “dare to promise”. At the beginning, they said very well, “No problem, no problem”, but they may not be able to deal with it when they have to deal with each other. This is a taboo in the workplace. .
Because when you say “no problem”, the customer is likely to arrange to use your product the day after you deliver it, and even the progress of other departments will depend on your delivery date. In the end, if you say no, the damage caused is incalculable.
Therefore, dare to refuse the things that you are really not sure about. This also eliminates the embarrassment that you will not be able to do it in the future.
As for what you can handle, use the “task dismantling” described above to estimate a reasonable delivery date and report it to the customer. Develop according to your own plan.
Take the initiative to report progress when giving staged results that can be demonstrated. When customers see the steady progress of their arrangements, they will naturally look at you with admiration, and there will be more valuable tasks for you in the future.
Of course, if there is a risk halfway, it should be reported in time. The earlier it is proposed, the more room for maneuver. If it is true that force majeure causes the task to fail, at least the customer will think that you are reliable and know to reduce losses in advance.
Be careful not to disregard other people’s tasks because the other party’s rank is lower or equal to you. Word-of-mouth is done, and everyone is not stupid whether you are a member of a power or not. When you treat everyone respectfully, your reputation is steadily increasing.
There is a small tip about communication. Put a can of sugar on the table and send it to everyone. Nobody will refuse sweet things~
Create value
Our goal is to create value for the company as much as possible. Although the butt is sitting in the office building, but the vision must be put into the use of first-line products. To ensure the normal operation of the product, maintain its quality, respond to customer needs, and be a problem terminator that promotes the smooth profitability of the company’s products.
Finally
I hope this article can help you a little bit and make you a better developer.
