What is the difference between a programmer and an engineer?

[[152894]]

When I first started working, the interviewer once told me: If I work hard for two years, I can quickly grow from a programmer to an engineer. I was surprised at the time. From many job postings, isn’t “programmer” the same as “engineer”? It’s just that “engineer” sounds better. After I worked for a long time, I realized that “programmer” and “engineer” are really different - programmers only write programs, while engineers write programs that can create value in the real world.

Unfortunately, many software developers may not know the difference between the two, and even after working for a long time, they are still considered programmers rather than engineers in the strict sense. So based on my own observations and experience, I would like to talk about the difference between programmers and engineers.

***、Engineers do not write black box programs

"Program = data structure + algorithm", this famous formula is well known to everyone. Unfortunately, it is not suitable for describing programs in the engineering field or the real world. There are many programs with great data structures and algorithms, powerful enough functions, and complex enough systems, but it is difficult to debug. Once it starts running, it cannot be stopped, and no one knows what the program is doing or what is happening inside.

Don't think it's funny, I've met many developers who have worked for three or four years or even five or six years, and they still keep producing black box programs: their first reaction when something goes wrong is to kill the process and restart it (Oh my god, can't your program be shut down safely?). Of course, there are even more brutal ones, who directly use the development machine to connect to the production database (open a hole in the firewall) to debug.

Do you think they have poor technology? They can solve all kinds of technical problems. Do you think they have no system awareness? The programs they have made are not simple. However, what they have made can only be called "programs" at best, not mature "systems" in engineering.

What kind of program is not a black box? You need to consider its hierarchical division, what (outside of the function) running information must be exposed and recorded, and in what way, you even need to consider the impact of these exposures and records on performance, and what manipulation interfaces the program needs to provide to the outside world... When you have considered all of this and written a program that can keep the running details "under control", you have one foot into the door of "engineering".

In this regard, Internet and software development giants pay more attention to it, but it doesn't mean that individuals have no room for pursuit. Everyone can write web crawlers, and everyone knows that it is troublesome to debug if you want to capture data accurately. I have a friend who wrote a "visual" crawler in a large company, which can quickly locate the problem by stepping through the execution of the command. Engineers of this level are the type that are hard to come by, and everyone still praises them every time they talk about it.

Second, engineers should pay attention to the separation of implementation and interface

A classic Java interview question is: Please describe the difference between an abstract class and an interface. Generally, everyone knows that "interface" and "implementation" should be separated. Unfortunately, many people understand "interface" as the interface provided by a specific language in a narrow sense, without considering the true meaning of "interface".

What is the real meaning of interface? Computers are best at processing information, and they can make information flow at high speed without the obstacles of reality. If "implementation" is the dirty work, "interface" is the window that issues the instructions to do the dirty work. It is enough to do the dirty work once, but there can be thousands of windows to issue instructions.

To be more specific, programmers complete functions, and engineers complete functions, imagine when they will be used, and make them easy for people to use. I have seen many programs like this: the login session is stored in local memory at the beginning, but when it comes to switching to the database for session transfer, a lot of construction is required, although what needs to be done is still just access; if there is a problem with the data automatically loaded by the program, it cannot be loaded manually at all; the data that was previously loaded manually must be torn down and re-loaded to be automatically loaded...

Whether or not you have interface awareness and can truly distinguish between interfaces and implementations is a major distinction between programmers and engineers.

Third, engineers focus on the logical connection of functions

Many systems are constantly changing and improving. Programmers see functional points, while engineers see the logic above the functional points.

Of course, any system is composed of several functions. However, in addition to the functional points, a large network with logical meaning is needed to combine the functional points, reduce the complexity, and make it understandable to everyone. The simplest "login" includes functions such as data input, data verification, and login information recording. "Login" is a logical combination of these functions and is also the basis for understanding these functions.

As time goes by and the business grows, there may be more and more new features, such as loading user data, notifying friends, preparing to push ads, etc. These features are of course easy to implement (because they are very specific), but the consequence of the accumulation of features is that the complexity increases sharply because the logical connection between the features is cut off. Therefore, engineers must think about how to combine these features and put them into which logically meaningful actions - such as "login"? It is through such continuous thinking that the complexity of the system can be maintained at a low level and easy for everyone to understand.

This example looks simple, but it is not that easy to do. Sometimes I see complex system operation manuals, which are simply laughable: 1) Click here; 2) Click there; 3) Enter this... The logical meanings of these operations are so accurate that they should be completed automatically at one time. The consequence of separating them greatly increases the complexity of the system, which is neither convenient for maintenance nor for operation. The only ones who have to clean up the mess are the developers themselves.

I often reflect on the education I received. Writing programs in school and writing programs at work are somewhat similar, but they are also two completely different things. What exactly is the difference? Only by experiencing and thinking about it can you understand it. So I want to write down what I see and feel. Students with good comprehension and the opportunity to receive good training probably don't need to understand this. But for students who don't have such conditions, I hope my thoughts can help you a little.