The main Difference between software engineering and software developer

The main difference between software engineering and software developer

To someone who may be trying to get into this career but has no idea where to start, here are the core differences as described by many online communities.

A software engineer has a more global vision of a project in general while a developer has a more technical vision. It depends of course on the person in question but a developer training is generally only to teach the person to develop and not to think about the issues, actors related to development.

Now, another way of looking at it is by looking at which group of people they belong to:

An engineer belongs to a professional association. A developer does exactly the same work, but is not a member of a professional association.

According to the data collection forms team, a developer is someone who only writes code while a software engineer thinks about the software architecture (classes, functions, data structures etc...) in addition to coding.

What is the difference between a developer, a programmer and a coder?

Currently studying, let's try to structure these three terms according to what we remember from computer science courses:

  • I learn to code: What is a variable? a condition? a loop? The specificities of the language I use? I can make, for example, a deminer in graphical interface.
  • I learn to program: What are the good coding rules? What is modeling? Learning to program is to detach oneself from a language as such, to have a more general vision of the thing. I can write algorithms: in that case, I program without coding. Ideally, one would learn to program before coding ;)
  • I learn to develop: I meet clients, I give back files, I learn AGILE, I coordinate a team work. I can make a web application relatively complex/complete.

All three articulate, complement each other. The limits can be porous.

At least, that's how some see it!

The answers already given are quite symptomatic of why good developers are rare: they almost only talk about technique!

It's like saying that being a good carpenter is mainly about mastering the chisel and the plane.

Thinking that a developer's job is to type code is already a misjudgment. Code is a tool (in the past, you had to know about electronics or manipulate punch cards...) and mastering your tool is a prerequisite. But this is clearly not enough.

The job of a developer is above all to solve problems and to find the most relevant solution according to the context and the constraints.

Solving problems implies having a spirit of synthesis and analysis. Finding solutions requires creativity and the ability to use the tools at one's disposal, sometimes to divert their primary use.

But developing is not limited to that, because the solution provided must be reliable, stable, sustainable and support future developments. It is therefore necessary to be rigorous, to be able to provide a correctly architected solution and not just a wart stuck on top of what already exists.

Then, you have to understand that the code is not intended for the computer because the computer would be better off if we communicated the instructions directly to it in machine code. The code is intended for humans. A code written by one must be understandable by the other. And for that, you have to conform to the standards and norms of the development team. Write code that everyone will understand, even the intern. Writing deliberately complex code to show off your skills does not do the team or the code any favors. A good developer knows how to keep his ego in check.

If code is a way to communicate with the machine and other developers, let's not forget other forms of communication. A developer who does a good job in his cave, ignoring all team interaction, will only be a good developer inside his cave.

A good developer is also a developer who takes responsibility. A developer who says NO when you should say no! Accepting everything without consideration puts the team/project at risk. So sometimes you have to stand up to the client/project manager/investor. It takes courage, it's true.

Being a good developer is one thing, staying good is another! Because if the aspects directly linked to the person will last in time, those which are external to him (like his tools) will evolve in time. And technology evolves quickly, very quickly. To remain a good developer, you have to be constantly on the lookout, to train yourself, to question yourself.

To put it simply, a good developer is one who masters his tool, who is an expert in his field, who is intelligent, creative, rigorous, courageous, communicative, capable of questioning himself, of training throughout his life, of never taking anything for granted, who has a good capacity to adapt. And who remains humble, on top of it all.

Look around you.

How many people do you see who meet all these criteria?

That's why good developers are rare.

(and also because 90% of their training is limited to the technical aspect).

Why are developers so haughty?

They are often asked to know a lot of things and to have an answer to everything "immediately". Among developers we know that infinite knowledge does not exist and that admitting not to know is a sign of intelligence, so no petty.

The problem is often with people who are not developers or who don't practice the profession on a regular basis, when a developer will want to communicate with someone who expects to have an answer to everything, that person can potentially look down on them if they don't get an immediate answer to a given problem.

Sometimes, because the answer given is not understood or misunderstood, the other person will come to the same conclusion "this developer is not competent". But this is not true. We are therefore often obliged to reassure the people with whom we communicate about our skills by exaggerating our knowledge or by giving them the impression that we have the immediate answer to all their problems, even if we really don't! 

Because we know very well that any problem requires an analysis of the problem before finding a solution, the analysis or reproduction of a problem takes time and often this time generates frustration in the "non-developers".... So to calm down all this little theater, we adopt from the beginning of the first act a particularly haughty behavior which gives a superior and untouchable air and which allows to avoid thereafter all the disrespectful remarks coming from people who would like an immediate answer to a problem.

Okay, let's try to see another difference by just describing what it is and we think the difference will come out. Here we go.

Programmer meaning: 

Already this term tends to disappear over time. Most often a programmer is the one who is given algorithms that he translates into a programming language simply (In Java, Php, C#, ...). He doesn't "think, he just translates the received algorithm" into a language understandable by our computers;

Developer meaning:

Fashionable term, which already steals the place of the previous one. In addition to what the programmer does, the developer is able to improve a received algorithm and/or produce one. Yes, he is able to find a solution to a problem and solve it. It is often a bac+3 is enough;

Software engineer meaning:

He or she, with a baccalaureate of 5 years or more, designs computer solutions, can develop them and evaluate the final product;

Computer scientist researcher meaning:

There is no magic, it seeks to improve the existing. Most often they are developers, engineers who have worked with tools and have seen the limits and produce new tools, new processes that become standards if they are adopted by the community. With Javascript it's so widespread. There is often ego that helps them to come up with new technologies and such. You don't have to have a high academic level in my opinion and that's what's great.

Is it difficult for engineers (other than software engineers) to change jobs to become programmers?

Of course not, let's see, we go through 4 to 5 years of intensive training, on a dozen separate subjects, just for fun - in fact, the grade corresponds to the number of beers we downed during the midterm... 🙄

Irony aside: on the one hand, "programmer" is like "lecturer", it doesn't exist anymore. It's a term that's often used pejoratively among us: "a programmer is a guy who pees code". I don't need to tell you what we think of the code produced, I guess?

The lowest level is technician (like a DUT in computer science), and most developers (that's the right term) are engineers. Software engineers, therefore, who don't need to change jobs to be "programmers" since they are already several notches above that.

Secondly, it's a job: it's ALWAYS difficult to change jobs during your career. You don't learn as fast or as well as you used to, and it would be an illusion to believe that anyone, even an engineer, has the skills to become a developer... Especially if he's facing an experienced developer like me, who doesn't take kindly to the presence of "tourists" on his projects.

You should take a look at the curriculum of a complete computer science program, maybe it will show you that apart from math and English - and even then, you have to be in computer science to study Boolean lattices - you don't have much in common with other engineering programs...

How to recognize a bad developer?

He doesn't write code, he hangs out with his group to socialize which guarantees him jobs. He will never write code, it's always about good code, but in fact he has no code.

When he is asked to solve a problem, he is afraid to translate it into code as if it was an effort. It's natural to use a programming language. I can understand that people are intimidated by implementation, but when you work with languages, you'll quickly solve with code. They're looking for certifications and stunts, but they never have code.

When you ask yourself how should I do something, you are not a normal developer. You need to know your design patterns and use them effectively, have a culture of algorithms and do regular analysis. The design documents are also always there without you thinking. The only thing you need to have in your head is an understanding of the real world. Don't force your client to think like a machine because it requires less effort and be able to anticipate details. You ask for the minimum to understand the maximum.

Your time is precious and you never say a word that doesn't matter, you respect your schedule. Bad developers talk about their vacation during meetings. They don't have a sense of urgency and they don't usually feel like they're under review when they have presentations. Everything should be as seamless as possible, your client should be able to travel through time without seeing a difference when they meet you, you shouldn't show them your personality, you are a piece in a machine. You should not do a job you are not qualified to do, so don't let them manipulate you, they should invest in the project.

engineer vs developer - the core difference described by the Data Collection Forms Team