Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Cyborg)
  • No Skin
Collapse
Brand Logo

CIRCLE WITH A DOT

  1. Home
  2. Uncategorized
  3. The job of engineers is not to deploy some technology but to build robust, reliable and sustainable (in all meanings of that word) solutions for real world problems based on requirements directly derived from people's needs.

The job of engineers is not to deploy some technology but to build robust, reliable and sustainable (in all meanings of that word) solutions for real world problems based on requirements directly derived from people's needs.

Scheduled Pinned Locked Moved Uncategorized
47 Posts 21 Posters 0 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • tante@tldr.nettime.orgT tante@tldr.nettime.org

    The job of engineers is not to deploy some technology but to build robust, reliable and sustainable (in all meanings of that word) solutions for real world problems based on requirements directly derived from people's needs. Even for an engineer technology comes second at best.

    wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
    wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
    wyatt_h_knott@vermont.masto.host
    wrote last edited by
    #7

    @tante The job of the engineer is to meet the specification. Period.

    colman@mastodon.ieC G phf@tabletop.socialP 3 Replies Last reply
    0
    • wyatt_h_knott@vermont.masto.hostW wyatt_h_knott@vermont.masto.host

      @tante The job of the engineer is to meet the specification. Period.

      colman@mastodon.ieC This user is from outside of this forum
      colman@mastodon.ieC This user is from outside of this forum
      colman@mastodon.ie
      wrote last edited by
      #8

      @Wyatt_H_Knott @tante and to make sure the specification being developed is as close to the requirements as possible.

      wyatt_h_knott@vermont.masto.hostW 1 Reply Last reply
      0
      • tante@tldr.nettime.orgT tante@tldr.nettime.org

        @olyerickson That's a tinkerer. Tinkering is fun but a different thing IMO

        amorpheus@kind.socialA This user is from outside of this forum
        amorpheus@kind.socialA This user is from outside of this forum
        amorpheus@kind.social
        wrote last edited by
        #9

        @tante @olyerickson Tinkerers specifications are intrinsic, which is the essence of joy.

        Professional engineers may also enjoy their work mostly while still being bound to extrinsic specifications, which sometimes are frustrating as they are much harder to comply with.

        1 Reply Last reply
        0
        • tante@tldr.nettime.orgT tante@tldr.nettime.org

          The job of engineers is not to deploy some technology but to build robust, reliable and sustainable (in all meanings of that word) solutions for real world problems based on requirements directly derived from people's needs. Even for an engineer technology comes second at best.

          G This user is from outside of this forum
          G This user is from outside of this forum
          gerardthornley@hachyderm.io
          wrote last edited by
          #10

          @tante In my experience, it's non-engineers who tend to focus on the tech and may need to be gently guided back to the problem they're trying to solve, from which a lot of engineers will look first for a simpler, less technical, or more general solution.

          darkuncle@infosec.exchangeD 1 Reply Last reply
          0
          • alatiera@mastodon.socialA alatiera@mastodon.social

            @tante Calling any of the turn it off and on again engineering is an insult to engineers.

            When I am crossing a bridge, someone had run the math to prove that it won't collapse on its own or from an earthquake.

            But with software we don't have a single clue what will happen let alone to how reproduce issues.

            G This user is from outside of this forum
            G This user is from outside of this forum
            gerardthornley@hachyderm.io
            wrote last edited by
            #11

            @alatiera @tante which software?

            alatiera@mastodon.socialA 1 Reply Last reply
            0
            • colman@mastodon.ieC colman@mastodon.ie

              @Wyatt_H_Knott @tante and to make sure the specification being developed is as close to the requirements as possible.

              wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
              wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
              wyatt_h_knott@vermont.masto.host
              wrote last edited by
              #12

              @Colman @tante Yes and no. As a working engineer, I got handed a spec. I was allowed to INTERPRET that spec to my advantage, but I was never allowed to modify it, because it was a customer document. So if the spec said "no pipe fittings here, with some exceptions" it was my job to make sure the exception was found and that it was justifiable. Which is how we got around stupid requirements. But mostly, we did what the spec said to do.

              colman@mastodon.ieC 1 Reply Last reply
              0
              • wyatt_h_knott@vermont.masto.hostW wyatt_h_knott@vermont.masto.host

                @Colman @tante Yes and no. As a working engineer, I got handed a spec. I was allowed to INTERPRET that spec to my advantage, but I was never allowed to modify it, because it was a customer document. So if the spec said "no pipe fittings here, with some exceptions" it was my job to make sure the exception was found and that it was justifiable. Which is how we got around stupid requirements. But mostly, we did what the spec said to do.

                colman@mastodon.ieC This user is from outside of this forum
                colman@mastodon.ieC This user is from outside of this forum
                colman@mastodon.ie
                wrote last edited by
                #13

                @Wyatt_H_Knott but there was another engineer up the pipeline somewhere involved in developing that spec. I meant the gestalt "engineer". πŸ™‚

                wyatt_h_knott@vermont.masto.hostW 2 Replies Last reply
                0
                • colman@mastodon.ieC colman@mastodon.ie

                  @Wyatt_H_Knott but there was another engineer up the pipeline somewhere involved in developing that spec. I meant the gestalt "engineer". πŸ™‚

                  wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
                  wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
                  wyatt_h_knott@vermont.masto.host
                  wrote last edited by
                  #14

                  @Colman Probably not. The specs came from the contract. The contract came from the Navy. The Navy thinks they know what they want, so they are very detailed about their specs. It's why we don't deviate very much. Specifications are commercial contracts. They say "do they job according to such and such standard to produce X result." Maybe there was a smart engineer involved in producing the standard, or maybe a bunch of managers sat around with their heads up their asses justifying their jobs.

                  ingram@mastodon.socialI 1 Reply Last reply
                  0
                  • colman@mastodon.ieC colman@mastodon.ie

                    @Wyatt_H_Knott but there was another engineer up the pipeline somewhere involved in developing that spec. I meant the gestalt "engineer". πŸ™‚

                    wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
                    wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
                    wyatt_h_knott@vermont.masto.host
                    wrote last edited by
                    #15

                    @Colman Also, what KIND of engineer? Because if the sonar guy wrote the spec, but the pipe guy has to interpret it, you're getting a different result, guaranteed.

                    1 Reply Last reply
                    0
                    • tante@tldr.nettime.orgT tante@tldr.nettime.org

                      The job of engineers is not to deploy some technology but to build robust, reliable and sustainable (in all meanings of that word) solutions for real world problems based on requirements directly derived from people's needs. Even for an engineer technology comes second at best.

                      gabrielmarkley@techhub.socialG This user is from outside of this forum
                      gabrielmarkley@techhub.socialG This user is from outside of this forum
                      gabrielmarkley@techhub.social
                      wrote last edited by
                      #16

                      @tante i love this thread. πŸ€“ only a bunch Of engineers would debate this great post. πŸ˜‚

                      1 Reply Last reply
                      0
                      • wyatt_h_knott@vermont.masto.hostW wyatt_h_knott@vermont.masto.host

                        @tante The job of the engineer is to meet the specification. Period.

                        G This user is from outside of this forum
                        G This user is from outside of this forum
                        gerardthornley@hachyderm.io
                        wrote last edited by
                        #17

                        @Wyatt_H_Knott @tante Perhaps for a junior engineering role, but I'd expect anyone in a more senior role to understand the context of the specification and the constraints that led to it, and where appropriate to discuss alternatives with the relevant stakeholders. With increasing seniority there should be a widening scope of awareness.

                        wyatt_h_knott@vermont.masto.hostW 1 Reply Last reply
                        0
                        • G gerardthornley@hachyderm.io

                          @Wyatt_H_Knott @tante Perhaps for a junior engineering role, but I'd expect anyone in a more senior role to understand the context of the specification and the constraints that led to it, and where appropriate to discuss alternatives with the relevant stakeholders. With increasing seniority there should be a widening scope of awareness.

                          wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
                          wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
                          wyatt_h_knott@vermont.masto.host
                          wrote last edited by
                          #18

                          @GerardThornley @tante Sure, yes. And for sure I was able to have discussions with contract supervisors where we could suggest modifications to the specification requirements in certain limited scope cases. But it was always a fight, and often the outcome rested on a political consideration rather than a purely technical one. The truth is there are MANY ways to do most things and what we were doing was picking one that jibed with the rest of our manufacturing ethic.

                          G 1 Reply Last reply
                          0
                          • tante@tldr.nettime.orgT tante@tldr.nettime.org

                            The job of engineers is not to deploy some technology but to build robust, reliable and sustainable (in all meanings of that word) solutions for real world problems based on requirements directly derived from people's needs. Even for an engineer technology comes second at best.

                            deshipu@fosstodon.orgD This user is from outside of this forum
                            deshipu@fosstodon.orgD This user is from outside of this forum
                            deshipu@fosstodon.org
                            wrote last edited by
                            #19

                            @tante [a gif of the Team Fortress engineer playing on a banjo]

                            1 Reply Last reply
                            0
                            • tante@tldr.nettime.orgT tante@tldr.nettime.org

                              The job of engineers is not to deploy some technology but to build robust, reliable and sustainable (in all meanings of that word) solutions for real world problems based on requirements directly derived from people's needs. Even for an engineer technology comes second at best.

                              cuberootoftrue@mathstodon.xyzC This user is from outside of this forum
                              cuberootoftrue@mathstodon.xyzC This user is from outside of this forum
                              cuberootoftrue@mathstodon.xyz
                              wrote last edited by
                              #20

                              @tante Sun Tsu's "The Art of War", specifically the section on Tactics, is surprisingly relevant in Software Engineering. You have a powerful army. Don't ask it to do something it can't do

                              gvlx@masto.ptG 1 Reply Last reply
                              0
                              • wyatt_h_knott@vermont.masto.hostW wyatt_h_knott@vermont.masto.host

                                @GerardThornley @tante Sure, yes. And for sure I was able to have discussions with contract supervisors where we could suggest modifications to the specification requirements in certain limited scope cases. But it was always a fight, and often the outcome rested on a political consideration rather than a purely technical one. The truth is there are MANY ways to do most things and what we were doing was picking one that jibed with the rest of our manufacturing ethic.

                                G This user is from outside of this forum
                                G This user is from outside of this forum
                                gerardthornley@hachyderm.io
                                wrote last edited by
                                #21

                                @Wyatt_H_Knott @tante Oh, for sure. I think we engineers often start out hoping that engineering decisions will flow from what makes the most sense, technically, only to discover that in large organisations (where most engineering happens) it's politics (a skill not typically taught to engineers) that rules.
                                I've certainly seen some dumb things done to satisfy political constraints, and with long-lasting consequences. And in a nod to the original post, I should note that some of those were made by engineers focusing on their own technical area of a product to the detriment of the product as a whole.

                                1 Reply Last reply
                                0
                                • wyatt_h_knott@vermont.masto.hostW wyatt_h_knott@vermont.masto.host

                                  @Colman Probably not. The specs came from the contract. The contract came from the Navy. The Navy thinks they know what they want, so they are very detailed about their specs. It's why we don't deviate very much. Specifications are commercial contracts. They say "do they job according to such and such standard to produce X result." Maybe there was a smart engineer involved in producing the standard, or maybe a bunch of managers sat around with their heads up their asses justifying their jobs.

                                  ingram@mastodon.socialI This user is from outside of this forum
                                  ingram@mastodon.socialI This user is from outside of this forum
                                  ingram@mastodon.social
                                  wrote last edited by
                                  #22

                                  @Wyatt_H_Knott @Colman And then there are Navy contracts with all the the mechanical interface specs as "figure it out with the ship SPO". Not exactly helpful when you're designing something that goes on every major ship class, and when the SPOs won't give you drawings or access. Flickr to the rescue sometimes, especially for the high res pics.

                                  wyatt_h_knott@vermont.masto.hostW 1 Reply Last reply
                                  0
                                  • ingram@mastodon.socialI ingram@mastodon.social

                                    @Wyatt_H_Knott @Colman And then there are Navy contracts with all the the mechanical interface specs as "figure it out with the ship SPO". Not exactly helpful when you're designing something that goes on every major ship class, and when the SPOs won't give you drawings or access. Flickr to the rescue sometimes, especially for the high res pics.

                                    wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
                                    wyatt_h_knott@vermont.masto.hostW This user is from outside of this forum
                                    wyatt_h_knott@vermont.masto.host
                                    wrote last edited by
                                    #23

                                    @ingram @Colman That was usually the point where I would walk down the hall, or to another department, and start digging through someone's private filing cabinet of legacy classified drawings.

                                    Which is why we worked so hard to get production rates up - to be able to keep legacy engineers and historical build data in house and actually usable. Because all those files were worthless without the engineer who collected them and could give you the right set of notes without looking anything up.

                                    ingram@mastodon.socialI 1 Reply Last reply
                                    0
                                    • G gerardthornley@hachyderm.io

                                      @alatiera @tante which software?

                                      alatiera@mastodon.socialA This user is from outside of this forum
                                      alatiera@mastodon.socialA This user is from outside of this forum
                                      alatiera@mastodon.social
                                      wrote last edited by
                                      #24

                                      @GerardThornley @tante All software ever written, unless its one of those special "formally verified" academic projects.

                                      G lain_7@tldr.nettime.orgL 2 Replies Last reply
                                      0
                                      • alatiera@mastodon.socialA alatiera@mastodon.social

                                        @GerardThornley @tante All software ever written, unless its one of those special "formally verified" academic projects.

                                        G This user is from outside of this forum
                                        G This user is from outside of this forum
                                        gerardthornley@hachyderm.io
                                        wrote last edited by
                                        #25

                                        @alatiera @tante Then I think the phrase "don't have a single clue" might be putting it a little bit strongly!

                                        For the software managing, for example, the timing of fuel injectors and spark plugs in all modern internal combustion engines, the engineers will have a very high (and justifiably high) level of confidence in how it will behave.

                                        That's built on a great deal of work to measure things like the behaviour of raw materials (electronic components) including failure rates and conditions, model the behaviour of the system in a range of scenarios, and test the product at multiple stages during both design and manufacture.
                                        All the same processes that give confidence in the construction of a bridge.

                                        In neither case will these efforts always manage to catch every single unintended outcome. A _fairly_ recent example would be the London millennium bridge, a footbridge over the Thames, which happened to have a resonant frequency at around people's walking pace, and had to have dampers added after construction to prevent an unpleasant rocking motion.

                                        alatiera@mastodon.socialA johntimaeus@infosec.exchangeJ 2 Replies Last reply
                                        0
                                        • wyatt_h_knott@vermont.masto.hostW wyatt_h_knott@vermont.masto.host

                                          @tante The job of the engineer is to meet the specification. Period.

                                          phf@tabletop.socialP This user is from outside of this forum
                                          phf@tabletop.socialP This user is from outside of this forum
                                          phf@tabletop.social
                                          wrote last edited by
                                          #26

                                          @Wyatt_H_Knott Yikes, when did you take Engineering Ethics? Never?

                                          wyatt_h_knott@vermont.masto.hostW 1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups