المطوّر مقابل مهندس البرمجيات

Written Explanation

Writing code is one slice of the work

Think back to the lifecycle from the previous module. A piece of software passes through requirements, design, build, test, release, operate, and retire. Only the build stage is mostly about typing code. A person who only ever writes code covers one stage out of seven.

Here is a plausible week for an engineer on a backend team. The proportions are made up for illustration, and they differ a lot between teams and weeks, but the kinds of work are real:

Some weeks, writing code is the largest slice. Many weeks it is not. The point is not a particular percentage. The point is that a person who can only write code is missing most of the toolbox.

What "engineering" adds

The word engineering comes from fields such as civil or electrical engineering, where people build things that must work reliably and last. Engineers in those fields do not just build; they plan, check, document, and take responsibility for what they build. Software engineering borrows that spirit.

A well-known description from the book Software Engineering at Google says that software engineering is different from programming along three lines: time, scale, and trade-offs. Paraphrased:

• Time. Programming is about producing code. Engineering is also about keeping that code useful and maintainable for as long as it is needed, which can be many years. Over that time the tools, the people, and the needs all change.
• Scale. Programming can be done alone. Engineering means many people working on the same software together, over a long period. Habits that work for one person (keeping everything in your head) stop working.
• Trade-offs. Engineers constantly choose between options that each cost something: time, money, effort, complexity, risk. Good decisions can be explained, not just defended with "I prefer it this way".

Notice that none of these three is "more difficult programming". They are about the world around the code: how long it lives, how many people touch it, and what decisions surround it.

Real software is built by teams, over years

A typical beginner project is small: one person, one weekend, one computer, no users. Real software is the opposite. A shopping service might be worked on by dozens of engineers over many years. Some of them join after the first version was written and have never met its authors. Some of the people who write a change today will have left the company by the time someone needs to fix it.

That changes what "good work" means:

• Your code will be read and changed by people who are not you, including the future you who has forgotten the details.
• Decisions need to be written down briefly, because memory does not survive team changes.
• You cannot test everything alone by hand, so you need checks that run automatically and keep running as the code changes.
• Working software must keep working while it changes. Nobody can switch off the shop for a month to rebuild it.

Think of the house again. A house built for one owner who never changes anything can be built in a personal style. A building that will be repaired by strangers for fifty years needs clear plans and standard parts.

Readable code beats clever code

Imagine two ways to write the same rule: "a customer gets free delivery when the order is at least 50".

// Version 1: clear
boolean qualifiesForFreeDelivery(double orderTotal) {
    double freeDeliveryThreshold = 50.0;
    return orderTotal >= freeDeliveryThreshold;
}

// Version 2: shorter, but harder to read
boolean f(double t) {
    return t >= 50;
}

Both do the same thing, and you do not need to know Java syntax yet to feel the difference. In version 1 the names say what is going on, and a new teammate can read it in a few seconds. In version 2, you have to guess what f and t mean and what 50 stands for. This tiny example is easy either way. With several hundred lines, the difference becomes the difference between a change taking ten minutes and taking a day.

Clever code is code written to be short, tricky, or impressive. Readable code is code written so that the next person understands it quickly. Why prefer the second? Because software is read far more often than it is written. Every time someone wants to fix a bug, add a feature, or check that a change is safe, they first read. A commonly repeated rule of thumb is that developers spend much more time reading code than writing it. I am stating this as a widely shared experience; I did not find a measurement in the sources I checked, so do not quote a ratio. The logic holds even without a number: code is written once, and then read every time anyone needs to change it.

So the habit to build is: write for the reader. Choose clear names, keep pieces small, and explain the why in a short comment when the reason is not obvious.

Ask "what problem are we solving?" first

Beginners often start by asking "what should I type?". Engineers start earlier: "what problem are we solving, and for whom?".

Suppose a ticket says: "Add a button to export all orders." A pure code-writer might immediately build it. An engineer asks a few questions first:

• Who needs the export, and what will they do with it?
• How many orders is "all"? Ten thousand? Ten million?
• Does the export contain personal data, and who is allowed to see it?
• Is there already a simpler way to give them what they need?

Those questions may change the whole solution, or prevent the work completely. Time spent on the wrong solution is wasted even if the code is perfect. Asking early is cheap; fixing a wrong build is expensive. This echoes a point from the lifecycle lesson: problems found late generally cost more to fix than problems found early.

Responsibility continues after release

In the house picture, the builders leave, but the house still needs caretakers. In many teams the people who built a backend service also help look after it. They watch for errors, answer when it breaks, and learn from what real users do. This is the operate stage of the lifecycle.

You do not have to love 3 a.m. phone calls to be an engineer. Many companies have specialist roles for operations (lesson 2 names them). But even then, an engineer cares what happens to their code in production, and designs it so that it is easy to watch and to fix.

Is this "developer" bad and "engineer" good?

No. Developers are valuable, and everyone starts by learning to write code. The point of the contrast is to tell you where to grow. In the early part of this course you will mostly write small programs, because you cannot design, test, or review what you cannot yet read. Over the course, the other activities in the table above come in one by one. By the time you are job-ready, you should be able to write code and take part in the rest.