Daily work of a programmer

Hello friends,

Referring to programming is referring to lines of code, referring to lines of code is referring to programmers, but do  programmers  only know how to write code? In this article, I will share with you the most typical and daily tasks of programmers.

Daily work of a programmer
Do programmers only know how to write code?
I. DAILY MEETING
In essence, daily meeting is an activity of  Scrum  - a software development model applied by many teams.

Daily meeting is described as a short meeting that takes place every day (usually in the morning), with the purpose of reporting an overview of the team's work. Depending on the culture of the team, this meeting may have different format and content.

Like my team, this meeting is called "Good morning", team members will take turns to report (generally) about their work situation, like what did you do yesterday, how far did you go? Do you have any difficulties, what is today's work… or simply this is a great opportunity to… joke around.

II. PROFESSIONAL ANALYSIS
For large companies with a clear working model, business analysis will have a separate department. But with medium-sized companies, or small teams, programmers will sometimes have to "kick" to the role of BA (Business Analyst).

The BA is the person standing between the customer and the product development team (a team with handsome devs), responsible for analyzing customer requirements. BAs usually have to answer the following questions:

Is the customer's requirement feasible? The point is to do it or not, because customers sometimes ask for unreasonable features, outside the limits of technology.
Should that feature be made or not? Customers sometimes come up with features that are expensive to implement, but offer little value. BA needs to analyze and show it to the customer.
Some other typical BA jobs:

Converting customer requirements into specific work heads: Customer requirements are often vague and general, BA needs to analyze and clarify them, turning them into specific tasks.
Risk analysis when changing (adding) features: When a new feature is added to the system, the BA needs to analyze how it affects the system.
Giving advice to customers: Customers are sometimes very "unreasonable" asking to do things in the sky and under the tank without bringing any benefits, BA needs to analyze and give reasonable advice to customers such as: “ You shouldn't do it, because… instead you should do this because…  ”.
Daily work of a programmerImage of the whole team sitting down to analyze business for new features

III. WRITE CODE
Programmers know code for sure, and “programmer's code” is an age-old topic – a lot of saliva has been wasted, but not all. So I will just point out a few notable things behind this work:

Writing code = Programming language + Programming thinking: Programming languages ​​are easy to learn, but programming thinking requires hard work. That is to say, to write code, you should focus on programming thinking more than learning a programming language.
Code is just a tool: Good software includes the element of “good code”, but “good code” does not mean good software. That is to create a good software you need to focus more skills and "code well".
Coding is the process of converting human ideas into computer work: That is, you have to have an idea before you actually write code.
IV. REVIEW CODE
Code review is the job of seeing and evaluating a piece of code that is good or not? Good or bad at what point? How should I edit? … To make sure the review is effective, this work is usually done by the leader or experienced coders, or it can also be the developers who cross-review each other's code, but rarely "I review my own code by myself." me".

Compared to writing code, review is more difficult and stressful, because:

Those lines of code are not written by you, you need to understand why “it is coded like that”. To be honest, the code I wrote down will not understand it until tomorrow, let alone read other people's code.
Code after being reviewed by you, but still has errors, then the error is your fault, because you did not find the error during the review.
You have to think at a "higher level" than the person who wrote the code to find the cases that the code doesn't handle (or does poorly).
V. TEST
Just like business analysis, small teams may not have a tester position (the person who tests and makes sure the software runs properly), so many times the programmer has to take on the role of a tester.

Basically, the role of a tester is to think of as many cases and make sure the software runs well on all of them.

Although developers are advised to cross-test each other's features to make test results more objective, test results from one developer are still not really "reliable". Since they often trust their colleagues, they think the case is so basic that their coworker must have handled it, but the outcome may not be the same. Although inefficient, but distorted is better than nothing, many teams still do not have a clear tester position.

BECAUSE. MEETING
You may think "meeting" is the job of "officers", but in reality, programmers also have to attend a lot of different meetings:

When there is a new project => meeting.
When completing a project => meeting.
When there is unclear business, need to discuss again => meeting.
When discussing with partners => meeting.
When need training new technology => meeting.
When the team has a new female member => meeting.
The frequency of meetings with each team, each company, each time may be different, but in general, meetings are one of the jobs that happen quite often when you are a programmer. Not only that, the role of the devs in each meeting is also very diverse, they can be the meeting owner, or the commentator, sometimes the secretary...

VII. SUMMARY
Tell me, the job of a programmer is not just code, right? Not to mention, when they have experience, they will tend to "code less", and switch to jobs such as system design, project management, customer relations, etc. In general, the code is only basic level. programmers' best, and  no programmers code all their life .