8 ms·
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
by deltaonefour 5y ago
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?
- svantana 5y agoIf 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.
- deltaonefour 5y agoThe 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.
- laserlight 5y ago> 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.
- deltaonefour 5y ago>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.
- foxfluff 5y ago"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.
- deltaonefour 5y agoExactly. 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.
- ericbarrett 5y agoThis is an especially good analogy when you look at mass home builders and buyers' frequent complaints about shoddy materials and workmanship, e.g. https://old.reddit.com/r/RoundRock/comments/ae8p5c/what_is_your_experience_with_kb_homes_and_other/ https://old.reddit.com/r/RoundRock/comments/ae8p5c/what_is_y...
- deltaonefour 5y agoAnaolgies 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.
- ericbarrett 5y agoI 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.
- deltaonefour 5y agoI'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.
- gilbetron 5y agoBeen 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.
- deltaonefour 5y ago>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.
- dpweb 5y agoI'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.
- deltaonefour 5y ago>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.
- ZephyrBlu 5y agoHow 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.
- deltaonefour 5y agoA 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?