7 ms·
Structural engineers are unsung heroes
- montrose 9y ago"Although it might seem a sane and reasonable business, the world’s great engineers, she believes, were "very eccentric characters, all very tenacious, the sort who were cheeky at school and didn’t do what their parents wanted them to do"."
- reallymental 9y agoThat's all very nicely put, to fit a lot of people into that mould don't you think? Very 'horoscopic'. Everyone is disagreeable & eccentric to some extent when they were young, including the world's great engineers/theorists. There's more to this equation, add parameter of hard work, a bit of obsession (or 'passion', whatever that is...), a bit of environmental 'push', and THEN perhaps that might yield a 'great' individual who does that one thing very well.
- WJW 9y agoIn other news, 100% of known engineers is human. A much more interesting piece of information would be how many people have those characteristics, but do _not_ turn out to be great engineers.
- Maro 9y agoOne of the best general Engineering books I've read is 'Design Paradigms'. It's an excellent book about the importance of understanding failures in Engineering. The author is Professor of Civil Engineering and a professor of history at Duke University, so all the examples are roads/bridges/etc. As a Data/SWE guy, I still enjoyed reading it a lot. https://www.amazon.com/Design-Paradigms-Histories-Judgment-Engineering/dp/0521466490 https://www.amazon.com/Design-Paradigms-Histories-Judgment-E...
- mauvehaus 9y agoThank for the recommendation! If you're into that sort of thing, you might also enjoy Why Buildings Stand Up and Why Buildings Fall Down. Why Buildings Fall Down includes a case study on a seemingly minor change during construction that caused a walkway to collapse once it was put in use. At the risk of stating the obvious, these are focused on buildings rather than roads :-)
- wpietri 9y agoOoh, that reminds me of another excellent book on failure, Sidney Dekker's "Field Guide to Understanding Human Error": https://www.amazon.com/dp/1472439058 https://www.amazon.com/dp/1472439058 It's about investigating airplane crashes, and in particular two different paradigms for understanding failure. It deeply changed how I think and talk about software bugs, and especially how I do retrospectives. I strongly recommend it. And the article made me think of Stewart Brand's "How Buildings Learn": https://www.amazon.com/dp/0140139966 https://www.amazon.com/dp/0140139966 It changed my view of a building from a static thing to a dynamic system, changing over time. The BBC later turned it into a 6-part series, which I haven't seen, but which the author put up on YouTube, starting here: https://www.youtube.com/watch?v=AvEqfg2sIH0 https://www.youtube.com/watch?v=AvEqfg2sIH0 I especially like that in the comments he writes: "Anybody is welcome to use anything from this series in any way they like. Please don’t bug me with requests for permission. Hack away. Do credit the BBC, who put considerable time and talent into the project."
- mcguire 9y agoThat first episode should be required viewing (repeatedly!) by all architects, physical or software. Geeze.
- galaxyLogic 9y agoHere's a book that's given many software practitioners inspiration: https://en.wikipedia.org/wiki/The_Timeless_Way_of_Building https://en.wikipedia.org/wiki/The_Timeless_Way_of_Building
- jaclaz 9y ago
- sidcool 9y agoThis is true. While dealing with building architects on many occasions during my internship, they would say silly things like, 'Can you not just avoid this girder/beam/pillar?' My boss would coldly say 'Do you mind removing brake pedals from your car to make it prettier'?
- jdavis703 9y agoI hope as you progress through your career you learn to be more respectful of diverse ideas. I'm a software engineer, I have to have discussions with designers and business people who also sometimes ask for things that just aren't reasonably doable given time and budget constraints. It's our job as professionals to explain this using a tone and words that educates others on what the technical constraints are.
- pitdicker 9y agoThe trick is that architects are often also just commissioned for the project. You work together to make a nice-looking, structurally sound, and not all too expensive design. I think it is a nice remark :-). Sometimes the design has to make a little concession, sometimes the construction. The best engineers are those that think along and try to find solutions, the best architects have some understanding of what is possible. And often 'everything is possible, it is just going to cost a lot'.
- gonzo41 9y agoI know what your saying about tone. But a retort like that in the building trades is pretty gentle.
- alsetmusic 9y ago> I hope as you progress through your career you learn to be more respectful of diverse ideas. I'm a software engineer, I have to have discussions with designers and business people who also sometimes ask for things that just aren't reasonably doable given time and budget constraints. It's our job as professionals to explain this using a tone and words that educates others on what the technical constraints are. Funny. I inferred the tone as having levity. One, or both, of us is projecting.
- deleted 9y ago[deleted]
- cee_el 9y agoI see no mention of Florida anywhere
- chrisseaton 9y agoThe article is from February.
- mauvehaus 9y agoI don't understand people who aren't fascinated by engineering generally and infrastructure specifically. I love knowing how stuff works, even if I don't understand it at the technical level an engineer does. So much of what we use we take for granted, but it really is worth seeing what goes into making potable water come out of your tap. In middle school, I toured the Baldwin water plant in Cleveland, OH. There is a huge hall full of sand filters that filter out the schmutz after the water is chemically treated. It's one thing to know abstractly that drinking water is filtered through sand to make it drinkable. It's another to see the process in action on a grand scale. In Boston, I highly recommend seeing the Chestnut Hill pumping station, which pumped water from the Chestnut Hill reservoir. It long predates the availability of sufficiently powerful electric motors, and the three steam engines are a testament to how much work went into pumping water around prior to the development of electric pumps. I believe the last of the steam engines was decommissioned in the early '70s. I'm told the pumping capacity has been replaced by electric pumps in a single 3m square building, which somehow doesn't convey the same sense of awe and indebtedness to the engineers who make running water possible. Gotta share a longtime favorite joke: What's the difference between civil (structural) engineers and mechanical engineers? Mechanical engineers build weapons. Civil engineers build targets.
- cityofghosts 9y agoi dont understand why people who write code consider themselves engineers. they arent liable if their code breaks. they have no professional licensing system. they dont even need an education.
- kejaed 9y agoThere are those of us who write code who are licensed engineers. In certain jurisdictions you just be, and are liable, if the code you write has an impact on public safety.
- yardie 9y agoSince many engineers aren’t licensed will they also have to stop referring to themselves as engineers?
- ovis 9y agoIn some places, yes. Ontario, for example, imposes hefty fines on individuals who use the an engineering title without accreditation.
- dschuler 9y agoThere's a lot of debate about what kind of activity software development is. The camp that doesn't see it as engineering argues that programming is a craft, or that code is "grown". I think one of the key differentiators for engineering is that something engineered should work by design after it has been built (not including regular maintenance of a machine). A defect requires a special process to repair all built instances. In software development, defects are a regular occurrence requiring continuing changes, and requirements change as well. Of course, that's very different from a bridge or a combustion engine for example. Automated testing can help push software development _toward_ an engineering mindset. BTW - you're right that most software devs don't need licensing or formal education, but it comes off as pejorative. While those could help set standards, some of the most talented people I've worked with have neither (and some of my class mates in college don't affirm a benefit for formal training).
- dzink 9y agoStructural engineers have one of the most stressful jobs as well. Work is incredibly precise with deadly consequences under tight deadlines with a lot of egos in the way. Massive respect to those who thrive in this profession.
- keketi 9y ago> Structural engineers > stressful Pun intended?
- myegorov 9y agoComing from the profession, I often think that the problem is quite the opposite -- that there're too many engineers with an outsized ego. In almost every way, aside from schooling, the structural engineer's trade is no different than any other construction trade, and has a contribution -- framed in financial terms, or in terms of common good -- on the scale of that of a (qualified) tradesman.
- bobthechef 9y ago"the structural engineer's trade is no different than any other construction trade" Can you name these? Because that statement is false if interpreted literally.
- antod 9y ago> the structural engineer's trade is no different than any other construction trade, and has a contribution -- framed in financial terms, or in terms of common good -- on the scale of that of a (qualified) tradesman. Not sure how to read that or how you meant it, but a good or bad engineer can have a big financial effect on a project in a way that a tradesman couldn't.
- myegorov 9y agoA construction project is overdetermined to a degree that few other enterprises are. In terms of compensation, an hour of a practicing structural engineer (aside from Calatrava & co.) is worth about as much as a carpenter's (who's paid his dues, so at about the same level of investment as engineer's into his profession). In terms of know-how or sweat equity or risk minimization, it's near impossible to say who, if anyone, contributes disproportinately more than others.