1. 33
  1.  

  2. 11

    We discussed it back in January.

    I guess a downside of the mega-thread format is that it makes it harder to find out if an article has already been submitted or not :-)

    1. 3

      Mostly I agree with the logic here. But one argument felt weaker than the rest:

      Engineering is high-consequence […] Three months of the project dedicated to getting the handle working right.

      This is not to say the work wasn’t important. It does mean that the engineers spent a lot of time on something that’s low-consequence or non-safety critical.

      The fact that engineers spent three months working on the handle doesn’t disprove the claim that “engineering is high-consequence”. It could just mean that engineers sometimes work on non-engineering tasks.

      The best definition I’ve seen that engineering work happens when you have to take into account the limitations of the medium you work with. Throwing up a Mysql-backed web form application typically isn’t engineering, but as soon as you need to change your approach in order to hit performance requirements, latency requirements, or storage space requirements, that’s engineering work. I think this is more or less compatible with the conclusions in the article.

      1. 3

        Great. Fantastic. Wonderful. Imagine me jumping up and down, clapping my hands together, reading this blog post because I’ve always wanted to do exactly what Hillel is doing: finding if the metaphors are even real.

        I think the real impact of “is it real engineering or not” is the stuff that other engineers get “for free”. I know digital gives some stuff for free but consider that we don’t really have atoms. This causes many problems.

        1. Software is too abstract, you can barely describe what the thing is - name all the things curl does (be exact)
        2. You can’t describe done - is grep done?
        3. We can’t compare or contrast software - everything is opinions, man :)

        Great post.

        1. 3

          You can’t describe done - is grep done?

          How can you describe if an aircraft, a car or even a power drill is done?

          I would argue the situation is exactly the same with software: to declare it “done”, you need to have some kind of pre-established specification of what is enough to call it a day and ship it.

          1. 1

            Fair. I guess a car isn’t done either and I wouldn’t easily be able to find its spec nor grep’s spec.

            My point is that software is too abstract. The specs for software are abstract and hard to experience compared to some of physical objects’ traits. The specs for physical products have freebies like atoms which is sort of nice for experience/feedback/demostration but also testing and measuring. I feel like software doesn’t have iron / steel / plastic which has mostly dependable properties. Or maybe software does have dependable properties (math, memory, types, immutability) but we’re not using those enough?

            It would be interesting to compare demonstrations of a physical vending machine and a completely software vending machine (like something you have to drive with a mouse). See which is harder to explain based on time. If it’s harder to explain then it’s harder to experience and then it’s harder to test so it’s less dependable.

            I think theatlantic article linked in the OP says this all better than I can.

            “Computing is fundamentally invisible,” Gerard Berry said in his talk. “When your tires are flat, you look at your tires, they are flat. When your software is broken, you look at your software, you see nothing.”

            1. 3

              Industrial engineering also mostly works with abstract concepts. Much of it is optimizing schedules, workflows, processes, etc.

              1. 1

                This is a good point. The whole article series is a good point! :) I think I need to change my chunking and opinion about this topic. You posted a story three months ago, interviewed 17 people, were surprised. There’s a journey you started a while back and I’m catching up. I was in The Atlantic article zone, you were surprised (I believe) and now I’m turning my ship?

                I still like rapid feedback and visual cortex stuff when possible. Maybe the machine is abstract but we don’t have to work that way if we try. Systems can be observed. Algorithms can be animated. Schedules can be post-it notes. Console commands can be reactive TUIs. StoryboardJS kind of blew my mind today, it’s just increasing visual feedback.

        2. 2

          First of all, I am from a country where you cannot use the title of engineer unless you have an academic degree in that area. Also, I am an engineer according to these standards so I am sure that I am incurring the risk of being a little bit biased.

          I agree with the article’s take on how it ultimately boils down to a language game. But once this argument is in the table it is hard to argue against it.

          My own mental model to assess the level of maturity of an engineering enterprise sort of a “Kardashevian” scale where the main variables are component reuse, and impact on other engineering disciplines. An engineering enterprise can:

          • Eventually reuse self-made components;
          • Create new designs mostly from self-made reusable components;
          • Export self-made reusable components to other engineering fields.

          If we agree on this half-assed, completely arbitrary and non-comprehensive scale, there is no doubt that the software industry has achieved that higher level of development. Embedded OSs and CAD tools are examples of software enterprises that are vital to other engineering fields as we know them today. In other engineering disciplines that have successfully achieved that higher level of development, the lowest ones are usually relegated to technicians. They are the ones that usually get their certification from a six-month or full-year training program. And there is absolutely nothing wrong with that.

          But, of course, not every mom-and-pop software house will achieve this level of development; in most of them, their loosely defined team of engineers will have a hard time adapting their “generic” MVC implementation to support a new CRUD UI request.

          1. 2

            Negative, I am a meat popsicle.

            1. 2

              There’s one thing that isn’t mentioned often. It’s a fundamental difference that gives rise to many subsequent differences: we build software, and the building blocks we use are software. Our field is inherently recursive. We stick together smaller pieces of software to make bigger pieces of software.

              A construction engineer does not build houses out of many little houses, themselves built out tiny houses. We do that. It makes things complex in a different way than otherwise.

              1. 2

                I believe I have changed my opinion on whether or not software development is usually engineering, based on this post. Exceptionally well reasoned and articulated.

                1. 1

                  In Canada? No. Engineering is a special accredited title that bears a lot of responsibility. Very, very few software developers here are actual engineers.

                  1. 14

                    The article has a whole section on the question of licensing.

                    1. 20

                      What’s the point of reading the article if you can comment on the title? 🙃

                    2. 3

                      I call myself a developer. If I could write an SLA and stand by the agreement legally, I would call myself an engineer. Or if I operated a ship, train, or starship engine.

                      1. 7

                        The post series makes a pretty compelling point that there are traditional engineering disciplines that don’t have anything like an SLA and are still universally accepted as Real Engineering, e.g., chemical engineering.

                        1. 4

                          As a former working chemist: chemical engineering is not anything like chemistry and you can bet your ass there is stuff like, “use this flow regulator with these pipe fittings or else THE REFINERY WILL BLOW UP, because the chemical reaction will go exothermic “, signed, licenced chemeng

                    3. 1

                      I have never thought of myself as a “software engineer” or a “computer scientist” the only camp I’d actually put myself into is “programmer”.

                      This might be selling my skills short in the long run, but I’m not a scientist and I’m sure as hell not an engineer. I fit perfectly just with “computers” and so “programmer” - being it’s own thing solely related to computers (at least nowadays), makes more sense to me, personally.