I hate it when someone calls it a craft. First off programming is one of the easiest engineering disciplines out there. That's why it's so easy to learn without a degree. It's like calling plumbing, "the art of plumbing." Sure it's a "craft" but don't be so full of yourself.
Also lifelong student? Have you ever felt that everything you learn is just the industry moving in circles?
Been doing this for 30+ years. "Craft" is an ok way to put it. It definitely isn't the "easiest" engineering disciplines - all engineering is difficult otherwise we wouldn't call it engineering. If you think it is easy, you haven't done anything worthwhile, sorry.
To bad engineers, I can see how it looks easy and that it is "moving in circles". It is still a relatively new discipline, and as such, still finding a lot of the process, tools, and techniques that other disciplines have developed. Plus Moore's Law and its ilk change things constantly.
>If you think it is easy, you haven't done anything worthwhile, sorry.
LOL this is an insult. Let me put it this way, you're right but I can bet you haven't done anything worthwhile either. Anything you've built as a software engineer, I can 100% build as well. There is nothing you can do that I can't as a pure software engineer. In fact likely everyone on this thread can build anything you've built and likely do better as well.
But let me be clear. If you programmed CAD software that can simulate an entire boeing 747 flying through the air... that is a feat that not many software engineers can do. But this doesn't count because it's combining two engineering disciplines (even a PRB renderer doesn't count.
Something like an OS would be an example of a pure software engineering approach.
Also I never said software is easy. I said it's the "easiest." Big difference.
IN ALL of engineering it's highly unlikely for all engineering disciplines to be equally hard. highly highly unlikely. All engineering disciplines must overall stand at some general point in the challenge spectrum. You could say the answer is too complicated to answer as there are jobs in say chemical engineering that are much harder than certain jobs in mechanical engineering and vice versa but regardless a GENERALITY of hardness exists.
What engineering discipline in your mind is than the easiest if not software engineering? Tell me. What other engineering discipline to practitioners don't require any schooling are hired without a degrees and you can easily form a start up around with less effort? Why don't we see a bunch of spaceX startups but see a ton of startups building some stupid dashboard for a niche?
I'll give you a hint. Because when you compare rocket science versus computer science, one of these fields is GENERALLY easier.
> I can see how it looks easy and that it is "moving in circles". It is still a relatively new discipline, and as such, still finding a lot of the process, tools, and techniques that other disciplines have developed. Plus Moore's Law and its ilk change things constantly.
How it looks? I've been in this industry for years. I can assure you it's not a "look" thing. It's a TRUE thing. The industry does move in circles.
There's no mathematical theory on how to organize code so we make shit up and call them "patterns" but there's ultimately no actual proof that one pattern is better than another and we're not 100% clear about the tradeoffs diving in. That's why the industry moves in circles. It oscillates between two solutions and it can't figure out which is better.
For what use case is a monolith better or a microservice? What software design pattern is actually better for what use case? Can you plug it into an formal equation and optimize the best design pattern to use for a certain case? You can't... because no theory exists.
But no theory needs to exist. You can hack a half assed solution and that's really all that's needed. Even if you don't "hack" a solution together nobody can really prove whether your "designed" solution is better. A stupid engineer can design something and think he's a genius but without theory nobody can prove whether his design is the best one possible.
And that is why software is easy. Anything goes. It's like building 1/32 scale model of the eiffel tower out of toothpicks. Is there a theory behind it? No. Is it easy to do? No. Can anybody do it? Given enough time, Yes.
> But no theory needs to exist. You can hack a half assed solution and that's really all that's needed
I don't understand your reasoning. You say that it's possible to "hack a half assed solution" that somehow works and from that you conclude that software is easy (or the easiest, doesn't matter)?
Aren't you contracting yourself? If software is easy why do you produce a half-assed solution? If it's so easy why isn't your solution of high quality like the 747? Maybe it's not so easy to write cheap, bug free, portable, maintainable, compatible, little-resource-consuming, high-performing software?
I can also build a half-assed airplane. It will crash often, not do what I wanted, and I will use a lot of off-the-shelf components (engine,...), just like modern software... That must mean building airplanes is easy, right?
Edit:
It would be more correct to say it like this: Creating software is hard and poorly understood at the moment. Even worse, people writing software are not trained well. But since the expectations of our customers are low (compared to the expectations we have to, for example, an airplane), the market tolerates this.
Edit 2: By the way, I agree with most of what you have written about the industry moving in circles, half-assed solutions, using patterns and frameworks without any deeper understanding. But that's actually proving that software engineering IS hard. (or maybe it's easy but nobody cares)
>Aren't you contracting yourself? If software is easy why do you produce a half-assed solution?
That's why it's easy. Finding a formal theory for software organization is hard so it hasn't been done yet. We make do with design patterns and many of those patterns are outright mistakes.
As it stands without "Computer scientists" establishing a formal theory on this... Software engineering is a shot in the dark and therefore easy.
>I can also build a half-assed airplane. It will crash often, not do what I wanted,
An airplane can only crash once. And when it crashes, people die. That's why no airplane is ever half-assed. Building an airplane is hard because of these requirements. Building software is easy because the requirements ALLOW for it to be half assed. Does my OS crash once a day? Still somewhat useable... Does my plane crash once a day? Holy shit.
>Edit: It would be more correct to say it like this: Creating software is hard and poorly understood at the moment. Even worse, people writing software are not trained well. But since the expectations of our customers are low (compared to the expectations we have to, for example, an airplane), the market tolerates this.
Hence why Software engineering is one of the easiest engineering disciplines out there.
>Edit 2: By the way, I agree with most of what you have written about the industry moving in circles, half-assed solutions, using patterns and frameworks without any deeper understanding. But that's actually proving that software engineering IS hard. (or maybe it's easy but nobody cares)
I would argue that this is more, computer science is hard rather than software engineering. The development of new techniques and greater understanding is the domain of science and academia. Engineering is about solving existing problems with existing techniques. Software engineering as it stands is easy.
What about safety critical software? For example software running inside airplanes, rockets, etc. Is that also easy, or it doesn’t count because it’s cross discipline? Although I would guess that many of those developers are indeed software engineers and not aerospace engineers by training.
>What about safety critical software? For example software running inside airplanes, rockets, etc.
There's two ways of handling software that's safety critical. For software that needs an extreme level of safety... formal methods are employed to prove correctness and that software is bug free. For this part of computer science the foundational theory is well established. This part is really really hard which is why 99% of software engineers don't even know what I mean when I say the word "formal methods." It's so different from traditional software that it's never ever referred to when people use the term "software engineering." We have a rudimentary form of it in the form of type checking in our programming languages.
But there's another part of it as well involving empirical testing. This is popular in the industry and engineers use the term unit testing or regression testing to refer to it. It's a shot in the dark. Basically taking a couple test samples out of an huge sample space of possible tests and saying if those samples work then likely the whole thing works. IF you want to prove your program correct using this method you would have to run every single possible test that exists on your program. It's untenable so we informally rely on a statistical phenomenon of taking a sample of tests out of a huge sample space.
This is the most common way of creating safety critical software that everyone uses because it's easy. Don't mix tediousness with easy. Using this methodology is very tedious, but I would argue quite easy.
Also redundancy and fail-safes in logic are used throughout the system for safety critical software. This again is easy to implement but tedious.
>Although I would guess that many of those developers are indeed software engineers and not aerospace engineers by training.
Yeah most of the mathematics in this case is modeled by system engineers or other engineers that are more specialized than the math is handed down to the software guys who only need to understand the equations but they don't need to understand how to derive those equations.
During testing the software engineers and hardware engineers would have to work together to make sure the software operates the hardware correctly. If the hardware is simple or well established and accessible often the software engineer can do the testing alone.
Sometimes the engineer of the physical system itself just programs it himself. Alot of non-software engineers are like this because software engineering tends to be easy so they can just learn how to program.
I agree that formal methods probably isn’t as well known as it could/should be.
> Also redundancy and fail-safes in logic are used throughout the system for safety critical software. This again is easy to implement but tedious.
I wouldn’t call implementing redundancy and fail safety for a fairly complex system easy though. Tedious, yes. And tedious but easy probably could describe lots of other engineering work as well, not only software.
> Sometimes the engineer of the physical system itself just programs it himself. Alot of non-software engineers are like this because software engineering tends to be easy so they can just learn how to program.
They might believe that it’s easy to write some software that in some way solves the problem but in my experience they don’t always engineer good software, and don’t always realise that their small part of the program has to work together with a huge amount of other software. Not that all software engineers do this either..
>I wouldn’t call implementing redundancy and fail safety for a fairly complex system easy though.
What's the cutoff for IQ then to implement a redundancy. Is there really a mediocre software engineer who can't do it. My argument is with a lot of effort any software engineer can do it. And if anyone can do it.. it's easy.
>They might believe that it’s easy to write some software that in some way solves the problem but in my experience they don’t always engineer good software, and don’t always realise that their small part of the program has to work together with a huge amount of other software. Not that all software engineers do this either..
As I've stated before. There's no logical theory behind program organization. How you integrate software together is mostly gut level arbitrary decisions and many times those decisions come out wrong and people make workarounds to fix things.
It all usually ends up working in the end. It may be ugly but it works and then everyone rewrites and the cycle begins anew.
Nobody in this area of software truly knows what they are doing. Hence why it's easy.
Let me be clear about what I mean by easy. Easy means anyone can do it. If a lot of hardwork and problem solving effort is involved... it doesn't matter and it's still easy because anyone can do it.
What you wrote confirms what I thought, sorry. You seem incredibly bitter, and I'm also sorry that you feel that way. If software isn't for you, it isn't for you. I come from an era when I was considered a weird nerd because I understood and liked "programming". The idea that everyone should like it is bizarre and foreign to me.
There is worthwhile software, and I have written some. But worth it is in the eye of the creator, and so I maybe I find worth where you don't.
What is the "easiest" discipline is a nonsensical question to me.
See this is a straight up insult. How do you know software isn't for me? You only say this to be manipulative and insulting. I love software, I'm just not delusional. Software is easy.
Let me tell you the extent in which I love software, I study haskell in my freetime. I study formal methods. I study graphics programming all of which are unrelated to anything practical to my current career trajectory.
>There is worthwhile software, and I have written some. But worth it is in the eye of the creator, and so I maybe I find worth where you don't.
I defined it in a way where it isn't defined by the eye of the beholder. What "worthwhile" software have you written that very few people in the industry can write? I bet you all the stuff you wrote, any mediocre software engineer can write. Which illustrates my point.
>What is the "easiest" discipline is a nonsensical question to me.
Of course it's nonsensical to you. How convenient. Because answering this question would defeat your argument or display how much knowledge you lack for other forms of engineering. The answer is: "software engineering"
It's like refusing to answer the question which is harder: Calculus or algebra? Well they are two different subjects and I am a logical automaton I can't determine which is harder so I am labeling the question as nonsensical even though the entire face of the earth OBVIOUSLY knows calculus is harder.
Well guess what you're not a robot. Don't hide behind that as an excuse. Calculus is harder than algebra just like how software engineering is the easiest engineering discipline out there.
Even "worthwhile" software that you write is easy.
Calculus and algebra were easy. I know you haven't written worthwhile software (yet), since you say writing software is easy. Write something worthwhile and then come back and let me know how easy it was.
Although, to be fair, some worthwhile software is easy to write, it's just figuring out what to write is really hard ... but that's one of the reasons why the discipline is hard!
>I know you haven't written worthwhile software (yet), since you say writing software is easy.
lol. You're a genius. I've stated this multiple times. Software engineering is EASIER than other forms of engineering. This is a bit different than just being "easy" and while I've used the word "easy" you know my intent.
I am also absolutely positive all the worthwhile software you have or yet to have written, any mediocre software engineer can do. Just name all the stuff you done. Anyone can do it.
Well when I think of impressive "worthwhile" software I think in terms of kernels, 3D rendering engines, a compiler that kind of thing. Those are things I would argue that actually promote your argument as less software engineers know how to program this stuff.
But looking at that site looks like you mostly do typical generic webdev stuff. Web dev is one of the easiest areas of software engineering. Also you're a vue guy and php. Vuejs is the typical choice for old school web dev guys who do php. I assure you all the stuff you built, anyone can do it. Doesn't even come close to "worthwhile."
Because anyone can do it, that is why it's easy. You can call it hard. But that's fine it just becomes a word game. Let me put it this way, ALL the software you have done may be "hard" but it's easy enough that any mediocre software engineer out of bootcamp can implement everything you wrote from scratch.
>Calculus and algebra were easy.
Nowhere near as easy as programming. The math involved with engineering goes much deeper than highschool algebra and calculus. I know you haven't done anything worthwhile in engineering besides webdev because you called it easy.
> Software engineering is a shot in the dark and therefore easy.
> Software engineering as it stands is easy.
> Nobody in this area of software truly knows what they are doing. Hence why it's easy.
> Let me be clear about what I mean by easy. Easy means anyone can do it. If a lot of hardwork and problem solving effort is involved... it doesn't matter and it's still easy because anyone can do it.
Seems like you think it is easy.
And no, that's not me that you linked. Although I have done webdev work in my career, and only easy webdev work is easy. There is plenty that is difficult in webdev.
Also I've created a 3D renderer from scratch (a complete 3D engine, in fact, including networking), a flight simulator, an ISAR simulator, software for force feedback, and a genetic samples assembler - and that's just the stuff from before stack overflow existed.
Let me repeat it a bunch of times so you get it:
Software Engineering is Easier than other forms of engineering
Software Engineering is Easier than other forms of engineering
Software Engineering is Easier than other forms of engineering
Software Engineering is Easier than other forms of engineering
Software Engineering is Easier than other forms of engineering
Software Engineering is Easier than other forms of engineering
Look you can either understand my point or play stupid games.
>Also I've created a 3D renderer from scratch (a complete 3D engine, in fact, including networking), a flight simulator, an ISAR simulator, software for force feedback, and a genetic samples assembler - and that's just the stuff from before stack overflow existed.
LOL, A 3D engine from scratch with networking impressive but arguably is doable by anyone. It also depends on whether when you created and what version API you used to interface with the graphics card. Prestack overflow likely means the engine was quite trivial.
But your other stuff only proves my point. Most of your projects are impressive ONLY because they combine other aspects of engineering together. Your stuff intersects with kinematics, aeronautics, biology, embedded hardware sensors, electromagnetic theory. This stuff is hard, the software by itself is easier.
>Although I have done webdev work in my career, and only easy webdev work is easy. There is plenty that is difficult in webdev.
I've been a webdev for a good chunk of my career. I've also done work similar to what you've done in your examples. You skim over general truths shooting for only the technicalities at your convenience.
Webdev work is generally the easiest form of software development and one major reason for it is due to lack of intersection with other aspects of engineering. WebDev also currently happens to be the sector of software with the most jobs and it contributes to the fact that software engineering is one of the easiest disciplines out there.
If this was the case, then why are most applications full of bugs, including those written by trillion dollar corporations? To me, coding is a lot like physical construction - anyone who can swing a hammer can build a treehouse, but try to scale that to a skyscraper and it will go badly. At that point you need careful planning and lots of specialized knowledge to do it proper.
"If this was the case, then why are most applications full of bugs, including those written by trillion dollar corporations?"
No-one ever seriously asked me how to make a program bug free. They also didn't ask me to use formal methods or prove any properties of the system I'm asked to implement. Hell, I can tell that I want to spend time developing tests and they say no, nah, we don't want that. Everywhere I've been it's been more important to deliver stuff quick and cheap than it is to make it perfect. Maybe places where extreme focus on quality do exist, and you only hear about them when the extremely unlikely catastrophic failure happens. But that's not the norm.
Analogies to real world rarely fit but I think most software is like most construction: houses and flats and small commercial buildings where you can and regularly do get away with shoddy stuff and blemishes. The usual thing complaints are about are schedule and budget overruns, and then when everything is done, all the faults and rushed parts they find... Guess what, they like cheap and fast in construction too. In every place I've lived, I could point out many many little snafus from walls that aren't quite straight, misdimensioned boards and panels and other things that just don't quite fit, design issues such as doors obstructing important paths or not having room to fully open, etcetra.
And you get away with it because your house is not going to fall apart because of a missing nail. Likewise for most software. Just another bug? Fix it and move on. Or maybe even leave it in if it's not catastrophic and there's more important things to do. The bar for quality is generally pretty low.
Exactly. Try open source development on a boeing 747 or even agile style development. @svantana Would you step onto a plane that was developed this way? The bar is low as hell.
The things you describe, managing complexity, is hard because there's no science around it. There's no optimization method for calculating the best way to organize code. It's not even formally defined what "organization" is.
As a result everyone just makes up anecdotal "patterns" without proof that those patterns satisfy any quantitative "efficiency" criteria. Again this "efficiency" criteria doesn't really exist, we have some numerical metrics for measuring certain things but we can't really say definitively which is more organized the windows code base or the linux code base.
So in terms of these kinds of things. Nobody really knows who does what better. Does hiring people who can solve LC type problems result in more "organized" code? How can we know when we don't even have the word "organized" defined? The existence of this problem in CS doesn't make CS harder because everybody is basically ignoring this problem and just picking arbitrary solutions aka "patterns" to solve things.
Coding is like physical construction, unbounded by the rules of physics and therefore MUCH MUCH easier then engineering a boeing 747. Try learning building a 747 from a bootcamp. You can't. Coding bootcamps exist because it's freakishly easy to learn programming while engineering a 747 is freakishly hard, hence the lack of bootcamps for building airplanes.
It's like making legos to fulfill your goal. In the end the thing we build with these legos likely isn't the most theoretically efficient thing but it works and we didn't need super high intelligence to build it and we don't need someone smart either.
The thing with programming is this. It makes you feel smart. The reality is, your not.
> Coding is like physical construction, unbounded by the rules of physics and therefore MUCH MUCH easier then engineering a boeing 747.
No, this is exactly backwards: engineering software is much much harder than engineering a large airplane. The latter is bounded by laws of physics, which acts as a global coordinator between parts and teams. There are no global constraints in software engineering and therefore coordinating modules and teams are very difficult. We have to come up with a set of constraints to achieve these goals, but the search space for the correct constraints is almost infinite. Enforcing these constraints is another issue.
> Try learning building a 747 from a bootcamp. You can't. Coding bootcamps exist because it's freakishly easy to learn programming while engineering a 747 is freakishly hard, hence the lack of bootcamps for building airplanes.
This is a false equivalence. Coding bootcamps are akin to learning to assemble parts --- nothing like engineering software.
>No, this is exactly backwards: engineering software is much much harder than engineering a large airplane. The latter is bounded by laws of physics, which acts as a global coordinator between parts and teams. There are no global constraints in software engineering and therefore coordinating modules and teams are very difficult. We have to come up with a set of constraints to achieve these goals, but the search space for the correct constraints is almost infinite. Enforcing these constraints is another issue.
Your joking or highly highly misguided. Very few corporations have the ability to manufacture/designs planes. Tons of software engineering firms exist that hire coders out of bootcamp. Global constraints makes problems harder. Why? because these constraints are extremely hard to figure out. They can be modeled with differential equations but much of the constraints can only be determined through building an actual model and experimenting with them.
>This is a false equivalence. Coding bootcamps are akin to learning to assemble parts --- nothing like engineering software.
This is a true equivalence. Let me explain to you. THERE are many people who can't "engineer" software after they come out of a bootcamp. BUT there are tons of people who come out of a bootcamp and CAN engineer software. That's why people say you don't even need to go to school to learn how to program. You don't even need to go to school to learn how to "ENGINEER" it's easy.
Now for engineering a plane? I can assure you. An aerospace engineer can't EVEN engineer a 747 OUT OF UNIVERSITY; it's that hard. It's also fundamentally impossible for a plane engineering bootcamp to even exist due to the sheer challenge of it.
You have a misguided notion of how hard software engineering is. Software Engineering is Ironically the easiest "engineering" discipline out there yet one of the highest paid.
> Very few corporations have the ability to manufacture/designs planes.
So what? The reason could as well be market dynamics. By the same reasoning we could also argue that software engineering is the hardest, because it is the highest paid one.
> You have a misguided notion of how hard software engineering is.
Software engineering is not programming, just like aerospace engineering is not assembling a plane.
> An aerospace engineer can't EVEN engineer a 747 OUT OF UNIVERSITY; it's that hard.
Let me rewrite that: A software engineer can't even engineer a Google out of university; it's that hard.
I don't think this discussion is being fruitful to me. I hear personal attacks instead of counterarguments to the ideas I presented. So, I won't be replying further.
>I don't think this discussion is being fruitful to me. I hear personal attacks instead of counterarguments to the ideas I presented. So, I won't be replying further.
Apologies for you thinking this it's not my intention to personally attack you, in fact I didn't. I think you're just perceiving it this way because my language is very to the point.
Saying you're misguided when you actually are is not an insult btw. It's not your fault or some kind of attribution to your intelligence when I say so. It's simply you are misinformed. Likely you are also very young.
Either way... I myself am a more logical person so "personal attacks" don't effect me if the possibility of new knowledge being imparted to me is greater than zero. This is the logical way of perceiving things. You obviously are less logical so your reasoning can be forgiven.
>So what? The reason could as well be market dynamics. By the same reasoning we could also argue that software engineering is the hardest, because it is the highest paid one.
lol market dynamics. No the reason is because it's harder. There's only two companies in the world that can build passenger airliners. There is tons of room for more competition. The duopoly is held because very few companies can build these things to the scale and speed as boeing or airbus. China is making a huge endeavor to gain these skills and after several decades their planes are still not ready for mass production. See below for evidence:
This isn't the only example. Let's go with semiconductor manufacturing. Currently there's a shortage of computer chips. The "MARKET DYNAMICS" demands for tons and tons of companies to fill the space... but guess what? China and the US don't have the knowledge or the know how to fill the gap. TSMC and ASML two companies from Asia and Europe respectfully are just a few companies out of a handful that can do build chips at the 5nm process. Intel is still behind.
Meanwhile no company on the face of the earth has a monopoly on "software engineering." Why? because it's easy. Anybody can do it.
There's zero science, axiomatic proofs or empirical evidence that is part of the definition. It's all just "planning" guidelines masquerading as some kind of mathematical formalism. It's not. It's just a made up series of steps for creating software. I can easily make the same set of formal rules for company bylaws or planning some event.
>Software engineering is not programming, just like aerospace engineering is not assembling a plane.
Software engineering? You mean agile? lol. or simple stuff like unit testing? Even agile isn't part of any theory. and best practices like testing are easy. These are just made up formal rules that we "think" work. Let me be honest with you, if engineering practices from software were applied to other forms of engineering you would be laughed at. Also people would begin dying if agile was used to hack on features onto an airplane. See the boeing 737.
>Let me rewrite that: A software engineer can't even engineer a Google out of university; it's that hard.
You realize google doesn't care what university you went to or even if you went?
Google is built and maintained by many people who never went to university. Additionally do you know about the founder of duckduckgo another company centered around a search engine? You know what "engineering" knowledge he used to create duckduckgo? None. He got a physics degree from MIT. Learned programming by himself. Likely didn't read a single book on "software engineering"
With you for the most part, but can’t get behind your analogy.
> Try learning building a 747 from a bootcamp. You can't.
Yeah, try doing that with an engineering degree. You can’t.
Try grabbing a random Boeing engineer and get them to build a 747. They can’t. No one can.
Okay, I should be more charitable. You mean can’t contribute to a portion of the 747 project? Yeah, college isn’t necessarily going to help you much either, and you might be surprised what a smart person off the street can do… there’s a really good chance your boss just has a bunch of spreadsheets for all her maths. Yeah in the grand scheme of things you’ll have to learn how to do that too, but it may not be the barrier it seems.
I’m a SW Eng, but did and entry level EE gig, and basing my experience on that. College did not prepare me at all. Engineers routinely enter industry without knowing what a relay is (and we used ladder logc!). Btw, we had self taught non-college educated “engineers”… they'd usually be talented operators that knew the machine like the back of their hands. So that’s basically an ME without a degree.
I did a stint on an F-16 project after switching to computer engineering, and it was the same shit. Almost everything was learned on the spot from the veterans or google for general stuff.
So yes, I could have worked on F-16 off the street, as well as done EE work and it really seemed like my ME friends were grinding out the same BS.
Where are all these super special engineering people you so admire? Some of them do get very specialized education, but we were talking BS Engs.
P.S. I do agree about the accessibility of programming. There actually are many topics that are hard to self learn, for example comp arch would be very challenging without a good professor. There’s many others, that’s just what sticks out as “thank God I went to uni so I could learn X”
> With you for the most part, but can’t get behind your analogy.
I think the analogy works. No single engineer whether out of university or not can build a 747.
However a single person built a search engine. Duckduckgo. The person didn't even have a degree in software engineering. He had a physics degree.
I see your point. Let me put it this way. Somewhere in building the F-16 or the boeing 747 there is a form of theoretical modelling that must be done as a fundamental thing in order to build it. You need to calculate the flight dynamics and mathematically model the control system using math skills that cannot be obtained by attending a bootcamp.
Most of these skills can only be obtained through several years of practice, and a bootcamp doesn't offer that. Granted there are many parts of engineering a 747 that don't need these deep design skills so you can get away with not knowing what an ODE is while being an engineer.
But again, these complicated problems tend to be handled by well educated and experienced specialists. The reasons behind why it's not possible to do for the 747, but is with a search engine deal with complexity. There's far too many pieces for one person to handle, no matter how skilled.
For a single person to be able to do everything (not familiar with your examples, so I can't speak to the truth of it, but accepting your premise), the implementation must be sufficiently simple. You CANNOT provide an adequate solution to a slew of technical problems by yourself. There are many topics in SW Eng that CANNOT be done by a single person. Impossible. You can build a plane by hand by yourself. People do all the time. I had a boss that did. Sure he's buying parts and not eg designing the body himself, but no one ever really did.
At one point there were no planes, but over time we learned to do it better and better. At every step engineers were learning the ropes from industry veterans, then adding their own innovations. Not that different from a guy putting together a plane from parts. You could point to more complicated areas where harder technical concepts are applied, but that really just works the same. You learn x software, and y methods (again from the veterans NOT from Uni), then you add your innovations.
You think Boeing is designing all their parts, on one team? No it's mostly people cobbling together parts from suppliers and other teams, digging under the hood for some things, tweaking similar designs, managing, "business stuff", ect. That's the vast majority of engineering, even outside of software. A high percentage of people won't touch the stuff they learned in school, or just a tiny piece of it. They're getting most of their information from the professional greybeards from within their industry.
I do agree that things are a bit different in software engineering, but not by as much as you seem to think. We could probably get a lot of traditional engineering prospects off the ground with an intensive camp. This makes a lot more sense in software for a variety of reasons (IMO mainly because there's SO MUCH of this kind of work to do), but I don't agree that it's impossible in other engineering domains.
It seems like you'd have to make a comparison that is not apples to apples, eg. comparing a master/phd educated, highly-specialized ME to an entry level software engineer. A better comparison is comparing a run-of-the-mill developer to a basic ME working in a plant. Things aren't so different there. You can also compare a specialized SW Eng, eg. working on algorithms themselves to the kind of aerospace engineers your picturing. Things don't look so different then, I think.
>But again, these complicated problems tend to be handled by well educated and experienced specialists.
That's my point. In software engineering these specialists aren't required. Like actual deep mathematical knowledge isn't needed for software engineering.
>They're getting most of their information from the professional greybeards from within their industry.
Of course, I never disputed this. However there is a foundational knowledge in say something like ME which is more reliant on schooling. This foundational knowledge is required to understand the greybeard. For example kinematics and calculus. Just getting up to that point requires at a minimum.. two years of training in school.
Plenty of software engineers don't know calculus or trig. That much I can assure you because it's rarely required.
I don't dispute that deep mathematical knowledge isn't needed for software. It isn't really needed in much of engineering. Plenty of high school level students can do trig and algebra. You can get by just fine in much of the engineering world, just like software, with bare minimums. Linear algebra, trig, even basic diff eq and calculus is relatively easy to pick up independently IMO. Plenty of books, exercises, videos, ect. Having taken math at multiple universities, including community colleges, I can't tell much difference between the programs. It didn't seem like anyone else felt otherwise. Going to college to learn basic math would be a waste of money, I think.
> That's my point. In software engineering these specialists aren't required.
That's not really true. I mentioned this in my comment. There are many areas of software and computing that DO require specialists. Elite teams or team members that tackle really really hard problems that much of the field then uses. So there's really no difference there at all.
Do you work in ME? It sounds like you have a glamorized idea of what a lot of other engineers do. I can assure you that the vast majority of them are not using specialized knowledge. It doesn't really seem that different to me. I can assure 100% that it's the same in EE, because I've done that, and it was almost exactly the same. (of course, it's fair to point out the similarities between EE and CS, but again all my ME friends reported the same kind of stuff).
>It isn't really needed in much of engineering. Plenty of high school level students can do trig and algebra. You can get by just fine in much of the engineering world,
A certain amount of People can get by, but the project itself cannot get by without a minimum people on that project knowing this stuff.
For your typical software project, the entire project can get by without anyone knowing anything from algebra and beyond.
>Linear algebra, trig, even basic diff eq and calculus is relatively easy to pick up independently IMO.
Less likely for people learn this stuff outside of a school. It can be done without school but the likelihood of learning these things without school is low because learning these things is about 10x harder than programming. Developing the intuition and familiarity with this is very rarely done independently.
Additionally, these are the bare minimum required for engineering. Complex analysis, control system theory, kinimatics, physics, circuit analysis and much much more are required for systems engineering. And almost nobody starts learning this stuff as a "hobby." Basically people pick up learning django or rails as a hobby or something along those lines.
>Do you work in ME? It sounds like you have a glamorized idea of what a lot of other engineers do.
I'm EE, switched to CS after graduation and I work in embedded systems with mechanical engineers and other EEs.
Yes the day to day doesn't require solving an ODE. But the basic knowledge is required in some aspect of the project. The same is NOT true for software.
>There are many areas of software and computing that DO require specialists.
Very few. ML or Data is mostly what I see but you're average web development shop has sw guys who are roughly homogeneous in terms of skills. Any specialization is domain knowledge as in he's the guy that coded that maze so he's the guy that knows it best.
There are "specialists" but the crossover is so close that all these specialties can combine and you encounter tons and tons of people who are "full stack" engineers.
One of the best analog engineers I worked with was not an actual electrical engineer in title. He was a technician without a degree of any sort that worked on electronics projects at home for fun. He’d often be frustrated at the solution the actual electrical engineers gave him to implement and test and would fix the design. Sure, he couldn’t program an FPGA or write DSP code, but he had a solid grasp of analog design that a lot of electrical engineers lack.
Oh yeah, we had this guy in enterprise. Total hardware wiz. Did horribly in college. All that homework-doing and test-taking got in the way of all his fun projects. So he just limped across the finish line and got a gig from a professor he'd worked with closely. Pretty cool technical work, guessing the pay was so-so, but doubt he gave a fuck.
Thumbs up to that engineer. How many of those people exist in the industry though? I would argue far far far fewer than the equivalent in software engineering.
For people interested in the comparison between “real” engineers and software engineers (as in this thread), Hillel Wayne wrote an outstanding series of blog posts summarizing a bunch of interviews he did with former “real” engineers who turned software engineers. I found it extremely interesting.
Anaolgies are deceptive. They don't prove anything but they lead you to perceive something to be more real even though no argument was made for proof.
So houses are made from shoddy workmanship. Software is also made with shoddy workmanship. How does this analogy prove that software engineering is not the easiest engineering field out there?
I would argue that it proves software engineering IS the easiest engineering field out there because you can get away with this shoddy workmanship. In fact the engineering process of software engineering are centered around shoddy workmanship and throwing in and developing features without any sort of plan. See agile for more info on this process.
I used agile before it was cool, back when it was a website and some rebel engineers frustrated at 6-month point patch cycles. In those days everything was a skyscraper, even getting MS Word installed on your company desktop. I hate what it's become and you're preaching to the choir. But some big projects do take real engineering, and coordination, and careful weighing of options before moving forward.
I've worked on these projects, they still exist but are rare. You'll find most of these projects are in high end defense or other embedded systems projects that are highly, highly connected with building hardware.
Outside of this kind of stuff, software engineering is easier than most other forms of engineering due to an accepted lower bar of quality.
How much do you know about traditional engineering? I have family and friends who work as engineers, and from what they have told me software has a far larger problem space and the software engineering process is far more rigorous.
Traditional engineers are generally doing the same-ish thing over and over, and the number of possible things they can do is severely limited in comparison to software. Safety is also not as big of a deal as cost. Any idiot engineer can create something with an insane factor of safety, it takes a good one to design something that is safe and cheap.
If you want to compare very complex/rigorous engineering projects like airplanes you should compare them to things like Google. Software and traditional engineering are both rigorous at the highest levels, though not in the same way since software is so much more flexible and has a larger problem space.
A lot. I work at the intersection of all engineering disciplines.
>I have family and friends who work as engineers, and from what they have told me software has a far larger problem space and the software engineering process is far more rigorous.
Software engineering is and everyone agrees with me, 100 times less rigorous. Only software has this culture of releasing something than issuing patches later.
As for "problem space" this is more defined by a product. The product is the problem space and programming is one solution to solve a problem. Granted programming is more versatile than other forms of engineering in terms of solving certain problems but this only lends to the fact about how much easier software is hence the desire to convert analog stuff to digital.
Flexibility is an indicator of easiness.
>Traditional engineers are generally doing the same-ish thing over and over, and the number of possible things they can do is severely limited in comparison to software. Safety is also not as big of a deal as cost. Any idiot engineer can create something with an insane factor of safety, it takes a good one to design something that is safe and cheap.
>If you want to compare very complex/rigorous engineering projects like airplanes you should compare them to things like Google.
>Traditional engineers are generally doing the same-ish thing over and over, and the number of possible things they can do is severely limited in comparison to software. Safety is also not as big of a deal as cost. Any idiot engineer can create something with an insane factor of safety, it takes a good one to design something that is safe and cheap.
I mean sure, this doesn't change the fact that software is the easiest of all engineering disciplines.
>If you want to compare very complex/rigorous engineering projects like airplanes you should compare them to things like Google. Software and traditional engineering are both rigorous at the highest levels, though not in the same way since software is so much more flexible and has a larger problem space.
Fine let's compare the rocket industry and automobile industry with software. Are either of these industries over loaded with a barrage of random ass startups or is software the only industry with this stuff?
You are trying to directly compare software with traditional engineering which doesn't really make sense. Traditional engineering has a lot of constraints which software doesn't.
> Only software has this culture of releasing something than issuing patches later
This has nothing to do with the rigour of software engineering. The process for releasing the initial software can be very rigorous, with a conscious decision to follow up with a patch or second release.
The nature of software allows this behaviour, whereas traditional engineering doesn't. The fact you can't release a day 1 patch for a building doesn't mean that the process for designing and creating a building is more rigorous.
> Flexibility is an indicator of easiness
How so? Flexibility means more ways to shoot yourself in the foot. It means you can easily implement something that works for now, and fucks you over later on. It's harder to do that with a physical construction because there are a lot of constraints. Physical construction has physics as guardrails, whereas software has unbounded complexity.
> Are either of these industries over loaded with a barrage of random ass startups or is software the only industry with this stuff?
How is this indicative of rigour? Yes, software has a lower barrier to entry. That doesn't mean that software engineering in general has less rigour.
A lot of software is written haphazardly without process, but I wouldn't classify that as software engineering because there is no engineering process there.
I'm just comparing the hardness. Software engineering is easier is my argument. The patchy nature of software makes it easier.
>How so? Flexibility means more ways to shoot yourself in the foot
True but people do so anyway. People in software repeatedly shoot themselves in the foot all the time than shrug it off. Oh it's just a bug. Hence the easiness.
>How is this indicative of rigour? Yes, software has a lower barrier to entry.
Rigour is another argument, though software definitely has less rigour. But my point is software engineering is easier. Doesn't low barrier to entry mean it's easier? It's like literally a synonym.
>A lot of software is written haphazardly without process, but I wouldn't classify that as software engineering because there is no engineering process there.
That's why it's easier. The "software process" is not really required. It's like an optional thing. Plenty of software shops prioritize speed over planning.
It sounds like your argument is that writing ANY software is easier than traditional engineering, which I would agree with but I think it's a poor comparison.
Most software shops aren't practising engineering, so to compare them to traditional engineering seems odd.
Software engineering is poorly defined. You say most shops aren't practicing engineering yet every software guy who works at these shops has the title "Software Engineer."
Let's dispense with the linguistic technicalities. Software, whether you want to attach the word engineering at the end of it or not is easier than other forms of engineering.
I agree software engineering is poorly defined, but I don't think it's just "linguistic technicalities".
There is an enormous difference in the work between shops that hack code together and those that have well defined processes.
The former is nothing close to engineering whereas the latter is very much engineering.
Also on the title thing, I think they're basically meaningless everywhere. Engineering grads will also call themselves engineers regardless of the kind of work they do.
The titles are as meaningless as the process itself. I understand what you're getting at. Everyone understands.
I'm saying these processes are pointless. They're are made up. An arbitrary set of methodologies or plans to execute certain things made up by mostly project managers.
It's like company bylaws or procedures for scheduling an event. Engineering processes are usually designed around some form of mathematical model or statistical phenomenon. This is not the case for software. Software processes aka Software engineering is just a made up set of arbitrary planning procedures.
Things like Kanban were not at all what I was thinking of.
Software processes are designed with mathematical/statistical backing when needed. For example, A/B testing, anomaly detection and merge queues.
> arbitrary planning procedures
I don't think this is an accurate description. In traditional engineering the main focus is: does it work and is it cheap? In software, both of these are usually non-issues so things can vary a lot more.
For example, recently there was a blogpost by a company about not doing code reviews by default to allow them to move faster [0]. They are making a conscious effort to optimize their process for speed. Other companies (Or even teams within companies) will make different optimizations. A service that must be highly available may have 100% test coverage as a requirement, etc.
I suspect you will call this arbitrary, but I see these process decisions as conscious choices. The fact these aren't grounded in mathematics or statistics is not a big deal to me because the goals/focus are more complex than does it work and how much does it cost.
In software everything is a tradeoff rather than having an absolute answer.
>For example, A/B testing, anomaly detection and merge queues.
A/B testing is arguable a product based thing. It can be called "engineering" but it's not strictly a software thing. It's associated more with UI.
I've never seen anomaly detection used with software development. Looks more like a data ML thing.
Merge Queues are just a collaborative tool. I mean you can use this on any document outside of software engineering. Say, for example, CAD drawings where a bunch of people work collaboratively.
I don't think your examples are focused enough to be strictly things that are part of "Software Engineering" in the same way agile isn't strictly "Software Engineering."
>Software processes are designed with mathematical/statistical backing when needed.
This is rarely done. Very little statistical methods make it into the dev process or are even influenced by the dev process. When it does make it in there's no common methodology either as it's usually just some data driven behavioral changes based off of some analytics. The reasoning behind why it's like this is clear. At it's core software is deterministic. Code is simply a series axioms and theorems that can be logically proven correct. Statistics is for unknown processes and is usually employed at the intersection of software and real world stuff like the failure rate of ssd drives.
A passing unit test does give more confidence that a program is correct. This is a statistical phenomenon, but hardly anyone tries to actualize it from a statistical quantitative standpoint.
>does it work and is it cheap? In software, both of these are usually non-issues so things can vary a lot more.
I disagree. These are issues and we do use methods to mitigate these things. We want our software to work and we want to build it at a certain cost. Agile and measuring velocity is a way to monitor costs and working software is verified through mostly testing.
But most of this stuff isn't engineering. It's done out of necessity. There's no mathematical modelling going on as it's hard to even quantify the costs of software or even correctness. Hence why it's all arbitrary processes made up by managers.
>I suspect you will call this arbitrary, but I see these process decisions as conscious choices. The fact these aren't grounded in mathematics or statistics is not a big deal to me because the goals/focus are more complex than does it work and how much does it cost.
All decisions made in any field even say plumbing is a conscious choice. The difference is in engineering we use science and mathematics as much as possible to optimize these choices. We don't in software. Mainly because it's hard to model it.
>In software everything is a tradeoff rather than having an absolute answer.
Everything in life is a tradeoff. It's like this in fields OUTSIDE of engineering as well. The thing with engineering is you try to optimize your choice using math and science as much as possible. In software no such optimization procedure exists.
> The thing with engineering is you try to optimize your choice using math and science as much as possible. In software no such optimization procedure exists.
It's comparatively easy to optimize something with an absolute answer. Ex: will this building fall down with x design?
It's practically impossible to optimize something like: will our software development process allow us to deliver new functionality faster and win market share?
There is far more ambiguity in software development than in other fields.
I meant exactly what you're referring to. Source code isn't the only thing that can go under source control. As long as the file isn't fully binary and is in a somewhat readable human format it can be subject to version control and therefore a Merge Queue.
>It's practically impossible to optimize something like: will our software development process allow us to deliver new functionality faster and win market share?
This is my point. It's impossible in the same way optimizing a painting of still life is impossible. Therefore it's not really engineering.
>There is far more ambiguity in software development than in other fields.
I'd call plumbing a craft, same with auto mechanic. I admire someone who put in the years to not only fix the thing, but knows ridiculous details of certain kinds of bolts or whatever. That's having a hobbyists perspective, and the enjoyment of something just because you're fascinated by it.
Obviously, some would consider it a waste of time. 90% of their colleagues would say, "I don't get paid to know unnecessary stuff about the bolts. I get paid to screw this to that according to this diagram." Which is what commercial software work is. Different thing from being a hobbyist.
>I'd call plumbing a craft, same with auto mechanic.
The point is that the plumber himself wouldn't call himself a craftsman. He doesn't label himself as some sort of artist and prance around like an arrogant prick thinking he's better than those janitorial engineers who are complete hacks.
>Different thing from being a hobbyist.
Yeha nobody does plumbing as a hobby. I'll give you that. I think you're more referring to "Computer science" here which is a bit different.
Also lifelong student? Have you ever felt that everything you learn is just the industry moving in circles?