They are at best artisans, at worst specialized monkeys.
TL;DR Concerning the engineering profession, do not call yourself a software engineer if you dislike/disapprove/do not know concepts like lambda calculus, category theory, or abstract algebra. Furthermore, Engineers are, by law, accountable for their work, we should ask so-called "software engineers" the same.
Background
I am a trained Electrical and Electronic Engineer. I came into engineering because I LOVED math, and lucky I got A LOT of it, most of my study books looked like this.
If you look at a mechanical engineer book it looks like this:
If you look at a Chemical Engineer book, you will see something like this
What do they have in common?... Engineers write Math
Engineers write math because it's THE ONLY TOOL AVAILABLE to understand complexity, fine-tune their intuition of the problem, explore possibilities and use that to stir their solutions. It's also the best communication tool out there and is very precise.
Can anyone picture a Civil engineer saying something?:
Math is overrated! I'll just start working on the bridge and let where it takes me
Even though it is ridiculous, with enough infinite tries and resources he will eventually construct a building see infinite monkey theorem
like if you put a monkey to type random keystrokes infinitely will eventually write any given text (infinite monkey theorem)
And for me, that's exactly how modern software is being built. It takes less than infinite time as the monkeys we use are a little more specialized but equally problematic to work with, especially the 10x.
So what do Software Engineering Books look like and how they should look like?
Engineers do not use all of math, math is too big for them to even need it all, but they use specialization of maths.
Electrical Engineers love imaginary numbers, Laplace/Taylor transformations, and linear algebra.
Chemical Engineers do stochastic processes, differential equations, statistics...
Software engineers, throwing the punch line of the post away here, they use no math. That is why their books mostly show hand-drawn pictures consisting (mostly) of boxes and lines connected with no other criteria than the one given by the author, arbitrarily. If that becomes popular enough, it becomes a sort of law everyone should predicate.
Book of software should be written with math like lambda calculus, abstract algebra, functional programming, or Category theory. However, at this point, most "Engineers" will frown upon it, arguing that Functional programming is an overkill.
Whenever I hear a Software "Engineer" complaining that FP, Monads, or Monoid are just overkill, and that's just fancy words for elitists, and you can do everything with plain JavaScript. It's me hearing that dumb Civil engineer again.
ACOUNTABILITY
Engineers in general are accountable by law for their work. This means that if they sign a blueprint with their calculations of a building, and that building collapses they are accountable for that, even going to jail if the incompetence is too much to bear.
WHY ARE NOT MODERN SOFTWARE ENGINEERS HELD TO THE SAME STANDARD? They are dealing with people's lives, livelihoods, savings, weapons of war, planes, and pretty much everything...
If people want the Software ENGINEER title, they should sign their work and be accountable. Once you own that type of responsibility, you start using the best tools around to do your work, like Math.
Summary
If you dislike functional programming, please do not call yourself and software engineer. You are an artisan at best, a specialized monkey at worst.
Top comments (28)
Hehe, this will infuriate some people out there, and somehow most will not say a thing because they know it's true.
You get to the engineer title once you have had to do some complex algorithms. CRUD's, carousels, animations: That's not it. Start with say, algorithms that line up parallel requests and pump them at a specified speed, or web worker synchronization. Then you'll become worthy of the title.
Sincerely,
A guy that likes to put wood in the fire.
P. S.: I studied chemical engineering.
The problem with this sort of thing is that you don't have a clear line. There's no point where complexity magically jumps from code monkey activities to laying out elaborate meshes of distributed databases. Task complexity is a continuum.
As for infuriating people, in my experience the only ones who tend to get emotional about labels are the ones trying to gate-keep them; the rest of us are just here to build things. You know, as engineers do.
You know I know a lot of Civil Engineers, really good, ones that do not build ANYTHING at all.
Building with cement is more of a blue-collar, artisan work.
And yeah the idea of being spicy its because I want, self-proclaimed, software-engineers to handle the title with RESPONSIBILITY. Otherwise do not call your self an engineer.
Thank you so much for your comments, I love throwing the idea around.
That's very true. The work of software developers has simple things, and has complex things in equal amounts.
Thanks for your comment
I would still argue that all of that does not make you an engineer.
An engineer needs to answer questions like: How many tons of cement does this bridge need? go and do some CALCULATION use math and tell you exactly the amount.
If I ask you? Can you mathematically prove that your code handles all exceptions?...
You are not able to because you did not describe the code as math, so there is no mathematical reasoning, ergo no possibility of CALCULATION.
Engineers calculate, Artisans build. You described the path of a builder, engineers rarely build. Engineers model and calculate.
Go ahead then, explain the process of calculating that. You're an engineer, so you must know how to build a bridge, no?
Thank you for your comment. Please, bear in mind that I am no civil engineer, but by using math we can navigate the problem. Which is part of the point of the post.
Certainly! As a civil engineer, if you’re calculating the amount of cement needed for a bridge, you'll first need to know the volume of concrete required and the mix design (the ratio of cement, sand, aggregates, and water). Cement is one of the key ingredients in concrete.
Steps to Calculate the Cement Quantity:
Determine the Volume of Concrete Needed:
You first need to calculate the total volume of concrete required for the bridge. The volume is generally calculated based on the design, shape, and dimensions of the structural elements (such as beams, slabs, and piers). For instance:
Volume of Concrete=Length×Width×Height
The volume is typically in cubic meters (m³).
Concrete Mix Design:
Next, you need to know the concrete mix ratio. Common mix designs might be:
1:2:4 (1 part cement, 2 parts sand, 4 parts aggregate)
1:1.5:3 (1 part cement, 1.5 parts sand, 3 parts aggregate)
Let’s assume a 1:2:4 mix ratio.
Determine the Amount of Cement in the Mix:
The total parts in a 1:2:4 mix are 1 + 2 + 4 = 7 parts.
For example, if the required concrete volume is 𝑉 (in cubic meters), the cement volume
𝑉cement is calculated as:
V cement =( 1/7) x V
Convert Volume of Cement to Weight:
Cement density is around 1440 kg/m³. Therefore, the weight of the cement
𝑊cement = Wcement in kilograms is:
Wcement = Vcement ×1440
Nice try, but the "Certainly!" gave it away :3
It's still valid knowledge.
Also the picture is incorrect. is a %100 ChatGPT
The picture isn't incorrect, the tool is simply honest about its confidence because it isn't a shitty ML scam.
As for being valid knowledge, you entirely missed my point that you, as a electrical engineer, will naturally have very little knowledge about the process of building a bridge, because that's simply a different field of engineering, but you're applying a different standard to software engineers and pretending a programmer not knowing how to build bridges is a sign that they aren't an engineer.
If you couldn't build a bridge without using google, then by your own reasoning, you wouldn't be an engineer either.
I am not
I mean, I am im paper. But i am more of a developer than a engineer
It can be proven in some cases, so long the exceptions can be enumerated or its set can be defined somehow (another algorithm, for example). This is what unit testing aims to do: Demonstrate that code works.
As for calculations, software engineers don't have to calculate material things, unless the software is used to calculate material things. We do calculate loads, maximum requests per seconds and other stuff.
@webjose You hit the core point. Software engineers do not calculate materials.
software is intangible and has other physical properties. that means that the math used is not your typical calculus. You NEED lambda calculus, category theory and that beautiful stuff.
So you can do calculations on your code, and prove mathematically that all errors handling stuff is being done in your code, so long you use, monads, monoids, maybes, etc. If you code is written in that way, you can prove it.
If we can calculate this with Math, I am pretty sure a developer can create an application for this.
Can you still call that developer an Engineer?
@jeromevillamor Thank you so much for your comments.
Well, what I am trying to stress is that for software engineering you need a different type of math. We can agree that cement is different from software. So, it would help if you had different math to make calculations. I would still call the person a developer.
I would call that person an engineer if the code it writes uses Monads, Eithers and functional programming. Otherwise, that's what a developer/artisan does.
I LOVED THE QUESTION!!! Thanks
Can you picture a software engineer working for a nuclear plant saying that? Or someone patching the flight control software of an airplane? How about someone writing firmware for a satellite? Maybe a computer-controlled radiation therapy machine?
Some of these are real examples, of course. And the response to some minor flaws in their programming show just how much accountability is expected of software engineers in fields where mistakes can have considerable consequences.
This entire "code monkeys no need careful" argument falls apart completely when you don't cherry-pick your examples on both sides. It is fundamentally a function of the potential danger, not the degree of "engineeriness" of the person doing the task.
...maybe you're thinking of graph theory there? Are you of the school of thought that something is only math when it has numbers and greek letters in minuscule? Or maybe I misunderstand, and you're thinking of mechanical schematics; although most of those do not only consist of boxes, they certainly conform to the rest of your criteria every bit as well as the diagrams used in software engineering.
Put bluntly: Because incompetent programmers don't usually kill people. Of course we are held accountable within a reasonable scope. But for all your love of math (at least in the abstract), you forget one very important inequality: Is the average cost of failure higher than the cost of carefulness?
Programming a landing page as if lives were in danger would not only be plainly silly for anyone with a bit of common sense, it also, mathematically speaking, contradicts any goal of working effectively, specially in an economic context where software is supposed to generate a maximum amount of value.
Until here, I would have been happy to take this as a conversation about semantics. At the end of the day, whether you're an "engineer" or not, is no more than a word, and at best has implications about the perception of a profession, but not on its actual value.
But you've said the quiet part out loud here. This ins't about words, it's about value. The point of this entire post is to put people down for doing the wrong kind of work; to de-value their skills and expertise with cheap and fallacious appeals to a pop-culture understanding of engineering. "Look at my books, they have numbers in them, that means I'm better".
The understanding of engineering you show in this article is something I expect in a cartoon sitcom, as the punch line to underline a character's stupidity. And maybe it is appropriate in whatever field of engineering you consider yourself a part of, but in software engineering, and the wider programming community, this type behaviour isn't welcome.
If you want to participate in conversations as a grown-up, I suggest you first develop a form of self-worth that doesn't rely on attacking others, and stop assuming there is no complexity in anything you're too uninformed to understand. It makes you look no worse if you really are looking at something trivial, and saves your face when it turns out you really were just over-estimating your own competence.
Thank you so much for this comment. I believe this should be a blog post of its own, we should share these ideas. Thanks for taking the time to comment.
The @estebanmarin makes some good points about software engineering as a profession, but their reasoning has some holes. Software engineering stands out as a field that needs a thorough grasp of computer science, math, and how people interact to create and build complex systems. It might not match up with old-school engineering fields, but it's still an engineering discipline in its own way.
@yogesh_joshi_c022cc46cdd6 thanks for your comment.
Absolutely I agree. This post cannot be an absolute for anything, and for sure it has a lot of holes. I wanted to stirr the community into taking the Engineering title with responsibility
This is stupid. Oxford dictionary define an engineer as “a person who designs, builds, or maintains engines, machines, or structures” so you could argue that software doesn’t fit into any of these categories but this just depends on how you view them. Maths is not what makes an engineer an engineer even if it is a tool that is often used. If you say that maths is what makes an engineer then aren’t other disciplines that use maths also engineers by that logic? You are clearly very bias and slightly angry(?) when it comes to this subject.
I really don’t see any value in this post apart from to put other people down which in my mind is a bit of a monkey move.
@aebonyep Thanks for your comment. You are right in everything you say. I took that definition that suited me and built a flawed syllogism with a spicy title. But are you judging me for how the internet works?
This post was sponsored by Boeing
you see what irresponsible engineers do. #cloudstrike
And don't even discuss the new "Prompt Engineers"—they're not even programmers!
So true!