What is the difference between a programmer and an engineer? (3)

This is not to discuss the difference between the two from the level of human resources job definition, but to look at the gap between the two from the broad concept and ability, and to make up for the shortcomings, so that "programmers" can broaden their horizons, expand their knowledge, and improve Go up one floor. Let me share with you an episode of my training process. At an analysis and design training meeting focused on programmers, I asked the trainees the following questions:
□Q: I think engineers are more capable than programmers Please raise your hands for the first level. Everyone raises their hands.
□Question: People who think they are programmers raise their left hands and think they are engineers who raise their right hands. As a result, most people raise their left hands and only 3 people raise their right hands.
□Q: The three of you think you are engineers. Please explain what is engineering and what is engineer? What is the difference between a programmer and an engineer? As a result, the three people immediately raised their left hands (the audience laughed).

What does this episode show? First, the definition of "programmer" and "engineer" is unclear, and second, everyone lacks confidence in themselves. Regarding naming, in different software companies, people who write code are called "development engineers" and some are called "programmers." Here we tentatively set the requirements for "engineers (short for development engineers)" higher than "programmers", and put forward some suggestions on the cognition of these two and what abilities an ideal engineer should have.

1.
The similarities between the two can write code proficiently. This is their similarity.

Two, the difference between the two

1. Engineer (ideal, expectation)
□Understand what is meant by software "engineering", know the process, deliverables, standards, etc. to complete the software;
□Able to see R&D objects from the perspective of "systems and associations," and understand from the overall and architectural perspectives;
□When encountering problems, they will find "common methods" to solve the problems, such as extracting, sorting out, and modeling;
□Good at analysis, and able to "speak with design drawings", and use graphics to express intent and logic;

2. Programmer (status, shortcomings)
□I don’t understand what software “engineering” means, and is not clear about the development process, but only knows the content of the part relevant to him;
□It is easier to see the research and development objects from the perspective of “code and program”, more Start with details and think;
□When you encounter problems, immediately look for "specific methods", such as online checking and copying;
□Not good at analyzing and expressing your intentions with design drawings, lacking logical awareness, and only "speaking with code" ;

3. Analysis of the differences between the two

It can be roughly seen from the following three perspectives that engineers are better than programmers (not limited to this): engineering perspective, system perspective, logic perspective

1. Engineering perspective
Engineers understand the different stages of the software implementation process, the theories, methods, tools, deliverables, and standards required at each stage.

2. The system perspective
engineer can study the object from the whole to the detail, from top to bottom, and from coarse to fine. The observation object is in the order of "system→module→function→control→program", and has comprehensive knowledge in many aspects. Abilities (including customer business level, software technology level).

3. Logical perspective
When researching topics, engineers can express their intentions through analysis and design, and have strong logical thinking and logical expression capabilities.

4. How to quickly grow as an engineer

After clarifying these gaps, what should programmers do to quickly reach the level of an ideal engineer? In addition to relying on personal hard work and time-consuming accumulation, I also want to make a suggestion to software companies: the first job of college graduates after entering a software company is not to write code, but to be an "apprentice" for demand research, experience The whole process from demand investigation to design can help new students understand what is "engineering, system", how to obtain the basis of software development, what needs to be done at each stage of the project, and at the same time, they can master certain analysis and Design method. Depending on the scale of the project involved, this process may take 2 to 3 months or more time, but this will greatly shorten the distance and time of new recruits from "programmer → engineer" in the future, and become the company's early Business backbone.

■If you didn’t spend this time to enlighten them and didn’t cultivate their awareness at the beginning of the job, it is very likely that after 5 years or even 10 years, they will find that they are still standing in the place of "programmers" instead of becoming "engineers". "s position.

■If students write code immediately after entering the job, they may be in a state of "knowing what they are and not knowing why" the development content they participate in for a long time, so they will be doing "small jobs" for a long time. If the students who have participated in the research, analysis and design of requirements in advance, after entering the development work, they can do "knowing what is happening, and knowing why." New recruits treated differently will be qualitatively different after working for a period of time, and the latter will grow faster.

The first step for college graduates engaged in architectural design and manufacturing design after entering the company is to go to the construction site/workshop for internship, and then enter the design position after a period of internship. Through the internship, they can see the whole production process, which makes them understand more What is the concept of engineering and systems? The experience of this process has accelerated their growth.

The above three blog posts about programmers are mainly to give some expectations and suggestions to friends who are engaged in programming work. Programmers are the basic force of the IT industry. The so-called threshold of 35-year-old programmers is a great waste of talents, and this waste is caused. One of the reasons is that programmers can only code, "too specific"!

If "coding" and "innovation" can be linked, the value of programmers will be greatly increased, but a bridge between "coding" and "innovation" is needed. This bridge is the ability of "analysis and design". With this ability, programmers can never change careers. To improve the ability of analysis and design, you can refer to "Dahua Software Engineering—Requirements Analysis and Software Design".

Insert picture description here

Guess you like

Origin blog.csdn.net/lihognjun/article/details/109726012