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.
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.
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.
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.
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.
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:
https://www.youtube.com/watch?v=4n3R1xQzs3E
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.
Take a look at this: https://en.wikipedia.org/wiki/Software_engineering#Tasks_in_...
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?
https://analyticsindiamag.com/why-google-believes-you-dont-n...
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"
> 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”
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.
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.
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.
> 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).
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.
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.
Outside of this kind of stuff, software engineering is easier than most other forms of engineering due to an accepted lower bar of quality.