>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.
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.