5 ms·

Your field may look vast to you but from where I'm sitting I couldn't even tell you what is different about the principles needed for tv mounts versus helicopte

Your field may look vast to you but from where I'm sitting I couldn't even tell you what is different about the principles needed for tv mounts versus helicopter flexbeams. Both sound like statics class to me, presumably decades after you took it, still being used in your work. Fine the bridge guy may be able to build other structures. Though I suspect it will get increasingly difficult for them to get past the job interviews as they stray from their narrow domain. Meanwhile a software person who knows databases can create a database for practically any kind of organization in existence. I didn't say build things from scratch, I said use fundamental principles. Your solenoid operates directly on your fluids or whatever and you presumably need to be able to understand how. Is it not possible to choose incorrectly without having the right expertise?

jjk166 6y ago
So when you don't know the difference between two things you assume there is no difference and not only disregard those better informed than you who claim otherwise, but try to tell them how simple their profession is? Neither the tv mounts nor the testing machine were remotely close to statics class. For the seismic TV mounts, I had to make an economical laser cut sheet metal assembly which could be assembled in a field and still survive earthquakes. For the flexbeam tester, I had to design a machine that could survive millions of cycles while placed in an oven at high temperature to simulate the effects of 3 years of flight time in less than 1 year. To say it was just statics would be like saying software is just assigning variables. Conversely, if you are a database person, that is an incredibly narrow skillset. Creating a database isn't a profession, it's not even a job, it's just a task. Yes a database guy can create a database for practically any kind of organization, and the structures guy can analyze a truss for any kind of organization. But the engineer who can only analyze trusses is fired. Yes, an engineer must understand fundamental principles, but that is true of any profession. How can you set up a database without knowing the fundamentals of how a database works? How could an accountant manage money without knowing the fundamentals of transactions? How could a ditch digger dig a ditch if they don't understand the fundamentals of a shovel? Any job that requires no understanding whatsoever was automated away long ago. That said, most professions, engineers included, can treat many of these things as black boxes during day to day life. I don't know how any given solenoid valve is implemented, and I don't generally care beyond it being rated for my use case. Of course this can lead to problems - I once designed a big machine for scanning cars and the power cables wrapped around it made it act like a giant antennna interfering with the data cables to the cameras - that took a while to debug. The world is a fascinating place, you would do well to learn about it instead of resting on assumptions.
- unishark 6y ago
  > So when you don't know the difference between two things you assume there is no difference and not only disregard those better informed than you who claim otherwise, but try to tell them how simple their profession is? Are you really snapping at me rudely over a disagreement about the differences between engineering and programming? To answer your question, no. I'm saying that it's the same technical domain. > Yes, an engineer must understand fundamental principles, but that is true of any profession. How can you set up a database without knowing the fundamentals of how a database works? Excellent point. Because it's at the heart of my reasoning too. Identify those fundamentals and you can apply my argument. In my prior post I noted the fundamentals in engineering are specifically physical principles. In the case of databases they are not, instead they are completely at an abstract level.
  - jjk166 6y ago
    > To answer your question, no. I'm saying that it's the same technical domain. And I am saying that these things are radically different, and thus the only way you could classify them as the same technical domain is if you are ignorant of those differences, or define domain so broadly that everything affected by physics is the same domain. You specifically refer to engineers remaining in a narrow domain and specifically gave an example of bridges and transmission lines as distinct domains, and it would be oxymoronic to talk about a narrow broad domain. You not only admitted that you have no idea what you're talking about, you used the fact that you were ignorant as evidence in support of your claim. Going back to the example, both things employ statics. Statics is the most basic tool of engineering - it is the analysis of forces on something which isn't accelerating. There is no way to completely avoid statics for anything that physically exists. Statics is to engineering as wood is to carpenters. It is equally absurd to say that two engineering tasks are in the same domain because they both use statics as it is that two carpentry tasks are in the same domain because they both involve wood. The engineers designing bridges and transmission lines both employ statics, as do those designing kidney dialysis filters and rocket engine combustion chambers and acoustic panels and laser cutters, all six of which could very well be done by the same engineer (I've personally been employed to do five of the above so far in my career). Your original claim, which I argued against, was: > The engineer generally stays with a set of fundamental domain principles their entire career (e.g. sticks with bridges as opposed to transmission lines) while programmers tend to stay at the top layers while the technologies below the surface change radically. Your argument had nothing to do with the difference between principles rooted in physics vs mathematics. You were saying that programmers use high level, general abstractions while engineers make more limited use of abstractions and remain highly specialized. I am saying that engineers work on a wide variety of problems over their careers, involving radically different physical principles, and that they abstract away many of the details of these various narrow domains so that they can work on the top level.

jjk166 6y ago

So when you don't know the difference between two things you assume there is no difference and not only disregard those better informed than you who claim otherwise, but try to tell them how simple their profession is? Neither the tv mounts nor the testing machine were remotely close to statics class. For the seismic TV mounts, I had to make an economical laser cut sheet metal assembly which could be assembled in a field and still survive earthquakes. For the flexbeam tester, I had to design a machine that could survive millions of cycles while placed in an oven at high temperature to simulate the effects of 3 years of flight time in less than 1 year. To say it was just statics would be like saying software is just assigning variables. Conversely, if you are a database person, that is an incredibly narrow skillset. Creating a database isn't a profession, it's not even a job, it's just a task. Yes a database guy can create a database for practically any kind of organization, and the structures guy can analyze a truss for any kind of organization. But the engineer who can only analyze trusses is fired. Yes, an engineer must understand fundamental principles, but that is true of any profession. How can you set up a database without knowing the fundamentals of how a database works? How could an accountant manage money without knowing the fundamentals of transactions? How could a ditch digger dig a ditch if they don't understand the fundamentals of a shovel? Any job that requires no understanding whatsoever was automated away long ago. That said, most professions, engineers included, can treat many of these things as black boxes during day to day life. I don't know how any given solenoid valve is implemented, and I don't generally care beyond it being rated for my use case. Of course this can lead to problems - I once designed a big machine for scanning cars and the power cables wrapped around it made it act like a giant antennna interfering with the data cables to the cameras - that took a while to debug. The world is a fascinating place, you would do well to learn about it instead of resting on assumptions.

unishark 6y ago
> So when you don't know the difference between two things you assume there is no difference and not only disregard those better informed than you who claim otherwise, but try to tell them how simple their profession is? Are you really snapping at me rudely over a disagreement about the differences between engineering and programming? To answer your question, no. I'm saying that it's the same technical domain. > Yes, an engineer must understand fundamental principles, but that is true of any profession. How can you set up a database without knowing the fundamentals of how a database works? Excellent point. Because it's at the heart of my reasoning too. Identify those fundamentals and you can apply my argument. In my prior post I noted the fundamentals in engineering are specifically physical principles. In the case of databases they are not, instead they are completely at an abstract level.
- jjk166 6y ago
  > To answer your question, no. I'm saying that it's the same technical domain. And I am saying that these things are radically different, and thus the only way you could classify them as the same technical domain is if you are ignorant of those differences, or define domain so broadly that everything affected by physics is the same domain. You specifically refer to engineers remaining in a narrow domain and specifically gave an example of bridges and transmission lines as distinct domains, and it would be oxymoronic to talk about a narrow broad domain. You not only admitted that you have no idea what you're talking about, you used the fact that you were ignorant as evidence in support of your claim. Going back to the example, both things employ statics. Statics is the most basic tool of engineering - it is the analysis of forces on something which isn't accelerating. There is no way to completely avoid statics for anything that physically exists. Statics is to engineering as wood is to carpenters. It is equally absurd to say that two engineering tasks are in the same domain because they both use statics as it is that two carpentry tasks are in the same domain because they both involve wood. The engineers designing bridges and transmission lines both employ statics, as do those designing kidney dialysis filters and rocket engine combustion chambers and acoustic panels and laser cutters, all six of which could very well be done by the same engineer (I've personally been employed to do five of the above so far in my career). Your original claim, which I argued against, was: > The engineer generally stays with a set of fundamental domain principles their entire career (e.g. sticks with bridges as opposed to transmission lines) while programmers tend to stay at the top layers while the technologies below the surface change radically. Your argument had nothing to do with the difference between principles rooted in physics vs mathematics. You were saying that programmers use high level, general abstractions while engineers make more limited use of abstractions and remain highly specialized. I am saying that engineers work on a wide variety of problems over their careers, involving radically different physical principles, and that they abstract away many of the details of these various narrow domains so that they can work on the top level.