1: Understand Structural Engineering Itself

In order to grow, we need to understand who we are. A popular but limited definition of structural engineering is "the art of molding materials we do not wholly understand into shapes we cannot precisely analyze, so as to withstand forces we cannot really assess, in such a way that the community at large has no reason to suspect the extent of our ignorance." This is clever and fun but only addresses uncertainty of forces and materials. What a limited understanding of what we do! Yes, we are experts in the ability to make decisions under great amounts of uncertainty, but that is only one aspect of our work. Stress and strain are necessary calculations but represent only a small fraction of all that we do; otherwise, we could be completely replaced by computers. Those of us who do genuine engineering are never concerned about this.

Another flawed definition comes from the British Institution of Structural Engineers: "Structural engineering is the science and art of designing and making, with economy and elegance, buildings, bridges, frameworks and other similar structures so that they can safely resist the forces to which they may be subjected." This sounds pretty good, right? Unfortunately, it fails completely in describing how one goes about designing. Like most other definitions, it puts too great an emphasis on force resistance. Yes, we proportion members based largely on forces, but that is only one of many design considerations - we also have to take construction practices, architectural constraints, client needs, and many other factors into account. As Hardy Cross famously put it, "Strength is essential, but otherwise unimportant."

The American Society of Civil Engineers unfortunately defines civil engineering thus: "The profession in which a knowledge of the mathematical and physical sciences gained by study, experience, and practice is applied with judgment to develop ways to utilize economically, the materials and forces of nature for the progressive well-being of humanity in creating, improving and protecting the environment, in providing facilities for community living, industry and transportation, and in providing structures for the use of humankind." How could a definition of engineering omit the most important word - design! This one is lengthy and dull, and fails to describe what we do, instead focusing on the end product, what we make. Saying that a cook makes cake does not describe cooking very well.

Here is more of the same from the National Society of Professional Engineers (NSPE): "Engineering is the creative application of scientific principles used to plan, build, direct, guide, manage, or work on systems to maintain and improve our daily lives." This suggests that our creativity is not employed for artistry, self-expression, costs, or constructability, but solely for science. That is just plain weird - and wrong. The applied science portion of what we do is actually the easiest and most straightforward. It is objective and has its own linear, step-wise methodology. That is why young engineers are doing the calculations and the modeling, while more experienced engineers are doing less. Yes, it needs to be right, so there is a lot of responsibility in this phase; but that does not necessarily make it difficult. The experienced ones are doing the other 90% of what we do, the more difficult tasks that require much more than calculations. Design is the other 90% of engineering that is only achieved after one graduates from being a mere applied scientist (or technician) to being a genuine engineer!

It is a widespread misconception that engineers are applied scientists. Scientists are applied scientists. Most of our engineering educators are applied scientists. Scientists make sense of what exists in nature. They test and examine nature. Scientists discover. Engineers take nature and make what exists outside of it. Engineers invent and create. Engineers are makers. Engineers are designers. Alan Harris put it succinctly: "Engineering is no more applied science, than painting is applied chemistry."

Here is my own definition: 

Structural Engineering is the design of BIG things.

The know-how required to do this is immense and is only obtained via lifelong learning. Engineers are 1% to 10% of each of the following:

  • Scientists

  • Mathematicians

  • Computer Scientists

  • Information Seekers (State of the Art)

  • Specialists in Systems

  • Experts in Construction

  • Citizens of a Locality of Construction Practices and Material Availability

  • Cost Estimators or Experts on Best Practices to Reduce Cost

  • Experts on Local Fabrication and Construction Technologies

  • Experts on Building Codes, Specifications, Standards, Guides, and Regulations

  • Risk Evaluators and Code Interpreters

  • Experts in Calculations

  • Experts in Three-Dimensional Representation in the Mind

  • Experts in Synthesizing Complex/Unsolvable Things into Simple/Solvable things.

  • Experts in Analysis Modeling Using Software

  • Skeptics of Engineering Software

  • Debaters of Efficiency, Economy, and Elegance

  • Artists, Philosophers, Poets, and Dreamers with Unconstrained Self-Expression

  • Drafters and/or BIM Specialists

  • Collaborators Working Within Design Teams

  • Listeners of the Vision and Needs of the Project/Client/Architect

  • Users of Rules of Thumb (Heuristics)

  • Experts in the Ability to Make Decisions Under Great Amounts of Uncertainty

Civil (Structural) Engineering is the design of big things.  You might ask, well Architects design big things too don’t they?  This is correct, but they are not hired precisely because the thing is big.  We are.  "Big" does not mean good - I use it here to clarify what we do (we do not design spoons).

This definition may contribute to a positive re branding of the profession and I believe it will  improve “career appeal” if we simply and succinctly told the truth.   Why is the retention rate in engineering schools around 50%?  That is a real problem but I think it is a marketing problem.   Our educators are not good engineering mentors and they likely mislead our students into believing we engineers merely complete calculation procedures.   Engineering is so much greater than that!

11

11

See 03/2012 ASCE-SEI Structures Congress Procedings “What makes an Engineer, an Engineer”

2: Embrace the Process

22

22

Let the design process push and pull you constantly.  It is healthy.    Design is nonlinear.  It goes backwards as much as forward and it curves around back on itself.  That is okay.   If you have issues with that, this may not be the best profession (although there are engineers that successfully do only computer modeling or code research, so there is still hope). Yes the Architect will keep changing things until the very last minute, get over it.

Above is a bridge truss, the top one may be familiar with, but the bottom one is new and novel.   How does one do this improvement?   You start with what you know and proceed.   You ask questions “how can I improve this boring Pratt truss (the top truss A)?”   Well maybe I can study the shear and moment diagrams and adjust the spacing of the verticals such that the axial force in the diagonals is always the same.    The cost saving will be significant if the rods, gusset plates, welds, bolts etc are all the same.  Then you can proceed from B to C and remove the middle diagonal – (zero shear).   This is a new truss, a novel and beautiful truss  - an economic, efficient, and elegant truss.   One that is created.

3: Listen

Be a better listener and collaborator.  Architects (and other clients) will make you a better engineer, but you have to listen.

Seth Horowitz, an auditory neuroscientist at Brown University and the author of “The Universal Sense: How Hearing Shapes the Mind”, wrote a terrific article in the New York Times called The Science and Art of Listening which starts...

"Here's a trick question. What do you hear right now?  If your home is like mine, you hear the humming sound of a printer, the low throbbing of traffic from the nearby highway and the clatter of plastic followed by the muffled impact of paws landing on linoleum — the slight trick in the question is that, by asking you what you were hearing, I prompted your brain to take control of the sensory experience — and made you listen rather than just hear. That, in effect, is what happens when an event jumps out of the background enough to be perceived consciously rather than just being part of your auditory surroundings. The difference between the sense of hearing and the skill of listening is attention.   [Horowitz, NY Times 11/9/2012]

This trick of asking yourself what are you hearing right now, reminds us of the difference between listening and hearing.   Many of us have no trouble hearing sounds, but listening to meanings with our full attention is another matter.  Can we shut of our internal thoughts and really listen to our design team around us?   Can we listen to the Architect or Contractor or co-worker without assuming what they will say or without interruptions by our own thoughts?   This is hugely important.  I for one am an extremely poor listener, so this #3 of my manifesto is the most difficult for me.

4: Ask and Pursue

Ask stupid questions often and pursue answers.  These stupid questions are really smart...Who am I?   What is engineering?   What is a weld, really?   How can something turn from a liquid to a solid within a liquid (concrete underwater)? How come I don't add that tension force I calculated to the pretension already within the bolt shank from tightening?   If you are constantly thinking about these types of questions, you are in great shape.  In order to maximize your well being now, you need to pursue answers to all your questions, and think up new questions to pursue.   Engineering, like the good life, requires this and your efforts will result in lifelong learning (ie happiness according to Aristotle).

5: Take Risks

Take Risks.   Design of big things requires risk taking.    Design of new and unique solutions to problems takes even more risk.  Because engineering requires ingenuity, it requires risk.  Be daring.  We need to continue to be leaders in design and construction and we need to take more active roles in pushing our projects forward, not getting pushed. In Uncertainty in Structural Engineering by William M. Bulleit, there is a great little quote taken from Lord Kelvin:

Lord Kelvin, the physicist William Thomson, said, “It’s no trick to get the answers when you have all the data. The trick is to get the answers when you only have half the data and half that is wrong and you don’t know which half.” Although he was talking about science, Lord Kelvin’s statement fairly well summarizes the problems associated with uncertainty in structural engineering.  [Bulleit, 2008]

In popular terminology, scientific applications or procedural calculations are about the "known knowns."   Design is much more about the "known unknowns."  Embracing this means embracing risk.

Also, maybe taking risks isn't really that risky.

People who don't take risks generally make about two big mistakes a year. People who do take risks generally make about two big mistakes a year. [Peter Drucker, Austrian-American writer]

So... don't not do it.   Do not let things prevent you from doing the thing you want to do.   (i.e. take risks)

6: Accept Imperfection

If there is not a perfect solution,  it follows that, all solutions are imperfect.   In other words, there is always a better solution than the one that you just submitted for construction.   Every design has many compromises such as code requirements, construction skill, material limitations, conservativeness on new construction techniques, possibly errors of design, bad decisions early, etc, etc.  Get accustomed to that, own it, it is a good thing.   All designs are fallible.  All designs can be improved. Guess what, your design you submitted last week has numerous problems or design compromises, that is okay.   Learn and do better next time.   Hopefully, you didn't just lose a client.   That will happen too.   Take your imperfect project to a lower state of imperfection on the next project.  That is the design process, taking something to a lower state of imperfection.

Above you can see a joint that affected the clear glass.   The joint was required when the bridge extended to the cantilevers and it compromised the aesthetics.  Compromises in design are the imperfections, but they are necessary.   The cantilever is fixed on the building, whereas the bridges floats freely on large friction pendulum isolators.  Isolating the bridges from the towers not only reduces the forces on the towers, but it also protects the light bridges from the movement of the towers.   Thus, we took our design to a lower state of imperfection, but still kept a healthy dose of imperfection.

7: Forget about Goals

Structural Engineering is a process without a goal.  Design constraints are not goals, they are ways to make decisions and move the project forward in the present.  Engineering is an evolution from a concept to a built project.   Let the final product be unknown during the design process. Understanding that design is inherently goalless is good for you.  Design is means driven, not ends driven (not the outcome).  It is the present, not the future.

Ask "What am I doing right now?"  Ask yourself that question often. How are you improving the project now?   Today, not tomorrow.   How are you increasing your well being, your team around you, and your project?   If you have an end product first, that is less effective than if you live and work honestly in the present.   When you take meaningful steps in the present, the next day the project will evolve to a higher level.  This repeats itself day after day.  The end product (building / structure) simply becomes.   Let it become.  Nurture the process.   Be patient.

We don't know the end product, the final construction is unknown.  So it is pretty reasonable to suggest that the goal of achieving this or that building is useless.   How could something unknown obligate us?   But the tricky types of goals, are the known goals.   I would submit that even known goals are useless whether it is to be successful or to win a super bowl.   These are not only obvious, they are superfluous.   Goals themselves are always good things for the person, so I am not debating whether this or that goal is a worthy pursuit.   Worthing pursuits like yearning for the vast and endless sea, as a goal is fine - but the more immediate task is building the boat.  Focus on the boat not the sea.   The sea is a useless goal, it is obvious.  Freedom to float on the water is inherently good.   Freedom in the sea or the goal of greatness is obvious.   The goal of the sea is superfluous - how can something superfluous, obligate us?   Just like the goal of being great.  That is just as useless.  Be great instead.  Let the design process produce the next evolution of the concept.  Try to design the boat by asking what materials are available first, and keep proceeding.   The built project, the boat itself in its final state should not be known.   Let the boat become, and then hop on board.   The sea will be reached.   Greatness will be achieved.

This is the problem with goal-laden appeals to our industry like ASCE's Vision 2025.   There is nothing wrong with the goal that we should be better planners, designers, stewards of the natural environment, innovators, and leaders.  Yes we should be all this, but we don't need a goal, we don't even need some dense roadmap toward that goal.    The real problem is that with Vision 2025, ASCE is submitting to the fallacy that "goals" themselves are useful in some way.  Goals are completely useless.   As a father of three, I never, ever, push my kids to get straight A's.  I could care less about their grades.  I encourage clarity of thought.  I encourage love of learning by reading, playing, climbing, etc.  I encourage being a good person, a good citizen.  I encourage them to be selfless.   Giving makes you feel good.  I teach them the golden rule (or better yet Kant's Categorical Imperative,  John Rawl's Theory of Justice).   I encourage them to be active learners through play or challenging questioning.   With this encouragement, they will get As, and hopefully they too won't even care.   That is good.  This is why goals for money and success are problematic.   Another problem with goals is the confusion one has after achieving them, I guess my new goal is going to have to win another super bowl?  I guess my new goal is that second million dollars?   So my point here is that known goals are useless too.   So if that is the case, that the unknown ones (a finished building) are definitely useless.   Again, you don't need goals.   Purge them if you have them, it is liberating!

8: Kick Ass

Design is an incredible process (again, from step 7 we learned it is not an end).   It is good for you to make the process of design your own. Drive the process and in so doing you will grow and become a better engineer.   Cooperate, listen, be humble, but don't let that prevent you from kicking ass.

You need love of learning, pursuit of excellence (not the goal of excellence - pursue excellence by being excellent in the present), you need process, you need means.   Ends are useless to process.  If you focus on the present and work to maximize your well being, others' well being, the building's well being -  now - what results is the achievement of any goal.  Take action now.  Act as though everything you do will become universal law.  Your pursuit of well being will help others, which will in turn come back to yourself and everyone benefits.  Do not picture yourself as a great engineer, a rich engineer, or a famous engineer.   Do great engineering now and you will be great (not in the famous type of great, the un-famous type of great which is more worthy of the word).

9: Improve the Codes

Codes are good and extremely important, but they are getting completely out of control and unsustainable.   There is an old Faraday adage:

Make every effort to ensure that the results of your experiment are proportional to the evidence and assumptions that produced them.

I remember listening to a great lecture by Ronald Hamburger regarding this same topic at an AISC conference.   He used the example of a provision in the ASCE 7-10 code regarding how QCQ methods should be employed when combining model results where translational and torsional modes are intermixed.   While admitting not knowing what this meant himself (and for Mr. Hamburger, that is saying something) and how to go about determining if in fact QCQ-4 should be used, he discussed whether the provision was actually important.   He questioned the code provision, something we all need to do.  This also helps us understand them better.  The questions we may ask in this case are:

  • “Why do I care about exact modal superposition methods when I am doing Response Spectrum Analysis, which is exceedingly approximate?”
  • “Do I really need to be exact when I just took my elastic response spectrum and divided by 500% (R=5 for example)?”

Of course not (should be the answer to question 2).  

The code committees should keep in mind the approximate nature of this enterprise called structural engineering.  Not only are there large uncertainties in our loads and material strengths used in design, there are huge uncertainties in construction.  Before meeting in a conference room, the code committee members should visit a construction site to remember how reinforcing is placed within a slab on grade.  While they are there, they can see what a true pinned base support looks like (a thick base plate with four heavy anchors).  They can see the soil and the assumptions used for designing the footings.  They can see what shear connections look like that are not supposed to transfer moment.  They will notice the large non-structural interior and exterior walls that were completely neglected when modeling the stiffness of the structure.

In summary, the code committee should ask themselves the following two questions:

  • Is this provision important to the design of safe structures?
  • Is the provision too exact?

In other words (from Faraday)  "is the proposed provision proportional to the assumptions and uncertainty inherent in structural design (loads, strengths, construction, etc)?”   If they asked these questions, the codes would not balloon to the size they are now.

Codes are getting so large they are becoming impossible to meet.  This is also going to hurt the profession.  We need to reduce code provisions and in their place, increase design guides to continue producing the state of the art.  Should we stop updating codes?  No.  Should we slow down?  Yes, absolutely.  The updates to the codes are out of control and unsustainable.  My ASCE 7 is a half inch thicker and depressing.  I am now a voting member of ASCE-7 and will fight every provision that does not meet these simple requirements.

Codes already contribute to the need for fully automated applied science because no one would be able to apply the amount of code information to a particular problem.   What does automation foster?  Non-thinkers.  I understand the codes are becoming more and more sophisticated and provisions are being improved to better mimic reality - but there was a time when people understood that code requirements needed to exist to ensure public safety, and that was the standard that they needed to meet.  That should be the only standard.  I like to compare my ACI 318-63 (no, I am not that old, I am an asshole who bought an old code to compare) with my ACI 318-11 just to remember which provisions are actually very important and how to prioritize my reading.  We need to join code committees and take our profession back - join me on the ASCE-7 committee or other important committees!

We will never be able to mimic the complexities of nature (the real world) in our computer models.  Our professor's are trying and great work is being done.  This great work may lead to larger codes and more accurate requirements at modeling and designing structures.  Some of this is good and some of this is harmful.  Larger codes means less understanding and more reliance on software to be code compliant, which leads to less understanding, less interest, more errors, and, possibly, more lawsuits and more collapses.  I don't believe the common wisdom that computers reduce error.   Computers just hide more error.

10: Become an Educator

I never thought being a teacher would make me a better engineer.   It is undoubtedly the best decision I have ever made as an engineer.  If not interested in teaching in a formal university setting, teach your fellow colleagues at work, set up lunch seminars ,etc. It allows you to reflect on important concepts and theories that you thought you understood but never really did.   In order to teach, you need to be able to translate complex ideas into clear language which requires that you master the material.  It also allows you to explore how best to communicate to people with different learning styles.  As we know, teaching is not about sharing facts, it is about assisting the student in discovery - but how?  I learned a couple tricks in my young career as an educator (now only 8 years).

One is to simply understand how knowledge itself is transferred and then retained. Socrates can even help us understand how structural engineering can be taught.  We know from his actions and through Plato's writings that he is clearly able to help us understand the importance of a liberal education (helping students in the process of discovery, so their knowledge is their own).  How does this translate to engineering education?  For Socrates, education within any classroom needs to foster freedom and inquiry.   He lost his life in defense of the spirit of inquiry (read the Apology or Crito). The most telling dialog of Socrates on the importance of inquiry is Plato's Meno. It is where we find Socrates asking fundamental questions about learning/teaching itself and the method of attaining knowledge.  I wrote about Meno, see “Socrates, How is Engineering Knowledge Attained?”  in STRUCTURE magazine April 2013, and edited the entire dialog (replaced words) because I think this is exactly the type of conversation that should take place in all of our classrooms.  I also borrowed heavily most of these ideas from my Dad's writing on liberal education... that every class needs to foster enquiry (especially about how ignorance is important to recognize, to be able to learn).  It took me a while to understand that a liberal education should be the same as an engineering education.  We need to resist cramming students' heads with more and more knowledge, whether it is more mathematics, new theory based on a particular research agenda, or trends in the marketplace.  This may numb the minds of our future engineers, let them seek information when they are ready.  Again, teaching should be about assisting the student in discovery (a liberal education), not supplying knowledge or listing the latest facts.  So we need to ask questions, open the classroom up and share our thoughts on solutions, criticize and praise worthy ideas, etc.  We do not want engineers who merely regurgitate what they have been taught and what they have memorized. We want them to struggle and to engage the world and people in meaningful ways. We want engineers with a spirit of inquiry and love of learning that will last a lifetime. So we had better make sure that Socrates joins us in every class.

A second idea is to teach forwards, not backwards.   This means, like our engineering history, our knowledge sharing should start from actively playing in the world and with materials - and then later asking how science and math contribute - not the other way around!   For example, I can lecture about the moment of inertia and provide the mathematical derivation or formula for stiffness.  Or, I can hand the students strips of wood to play with and ask them "why is one stiffer and by how much?" The math should never be the start, it is the end (see "science is applied engineering" blog to understand how art and engineering are the beginnings, and science and math, the ends of design).  Never teach backwards - unfortunately, that is how most do it (I am certainly guilty of this too, since it is actually much easier to teach backwards).

You can make four strips of wood (or Masonite), say 1″ wide by 1/8″ thick.   Take a pair and tape the middle together, take another pair and only tape the ends.   Feel the difference in stiffness…

100_1226

100_1226

The one you one tape in the middle will act as two separate beams.  The one you taped at the ends will act as one beam with double the thickness.  How much stiffer will the beam that is taped at the ends be?   Since deflection is proportional to moment of inertia, and I is proportional to thickness cubed, it will be 4 times more stiff!  Two cubed is eight, and 1 cubed times 2 members is 2, and 8/2 = 4.  It will be double the strength and 4 times the stiffness – just by taping the ends so it resists horizontal shear and acts as a composite beam.  Go ahead and try this simple experiment in your classroom and design other ones. Let the numbers follow the art/design/engineering and try to teach that way, teach forwards, just like our history (and the same way as how we design).

11: Become a Material

Talk to materials.  You can ask if bricks like to take compression.   Go ahead and ask a brick (Louis Kahn did this, we should too).   This may sound bizarre but participating in a conversation with an inanimate object is healthy.  Feel a brick (or bolt, concrete sample, etc) in your hand and discuss with it what it wants to be and where it wants to go in the building.  (For more, see my article  "Participation Mystique" May 2007 Structure Magazine).   It is important to the process of quality design to become the thing itself, by manifesting yourself on the building, beam, connection, or bolt.

I remember visiting a project where I designed all the connections for a large box truss that supporting four stories of concrete and spanned 100 feet.   The erector was proud to show me his work and described the installation, weld and details as a master craftsman would.   He wasn't self serving when describing this – he was describing the work itself.   He and I both knew the architect was going to cover it all up for no one else to see.  He was still deeply satisfied, as was I.   I realized much later that the satisfaction was not really about the truss or even the workmanship (craft).   What he was really showing me was himself, a manifestation of himself on the steel connection.  Yes, the weld was beautiful and well crafted of course and that is satisfying too, but that isn't really what he was indicating.   He was really showing me was that he was a good human being, he is quality just like the connection.   The inanimate object was him and it was beautiful.   We can learn a great deal about ourselves the same way.

I think this idea is similar to Robert Pirsig's metaphysics of quality.   In Zen and the Art of Motorcycle Maintenance, Pirsig suggests:

You want to know how to paint a perfect painting?  It's easy.  Make yourself perfect and then just paint naturally.  That's the way all the experts do it.  The making of a painting or the fixing of a motorcycle isn't separate from the rest of your existence... the real cycle you're working on is a cycle called yourself.  The machine that appears to be "out there" and the person that appears to be "in here" are not two seperate things.   They grow toward Quality or fall away from Quality together. [Pirsig 1974: 332]

Therefore, according to Pirsig, if you want to become an expert structural engineer, make yourself an expert structural engineer and then do engineering.  This sounds very similar to my idea of living a goalless life.

How does one enter the right frame of mind to do quality work (or enter a material)?  It might be the time when the mind is at ease in the task at hand, such that it no longer feels like a task but an extension of ourselves; it becomes part of us, a feeling of closeness, connectedness.  This state has been described as flow by Csikszentmihalyi (1988).  There are moments while doing engineering that could be described as being in the flow state, such as modeling, sketching, or hand calculations.  He describes how flow is exhibited by mountain climbers: "The mountaineer does not climb in order to reach the top of the mountain, but tries to reach the summit in order to climb," which means that climbing is intrinsically rewarding regardless of whether the goal is accomplished.  Climbing is about the exhilaration of the task at hand, not the reflection on an accomplishment.  Design is the same way, and it is through flow that quality can also come about.

12: Draw with a Pen

If you don't like to write words, sketch ideas of structural systems or buildings.  Buy a sketchbook and use a pen, so you can't erase your mistakes.  Mistakes are important reminders that you are an idiot (like everyone else).  The best preparation for life as an engineer is the understanding of our ignorance.

In 1850 J. Monier, a French gardener, developed a flowerpot with reinforced concrete in the hand sketches above on his patent shown on the right.  In 1867 he patented reinforced garden tubs and, later, reinforced beams.  We engineers owe a debt of gratitude to this gardener.

In the terrific book "Structural Engineering:  The Nature and Theory of Design" William Addis states:

Up until the turn of the century, it was standard practice for engineers to keep their own notebooks containing annotated sketches of hundreds of interesting designs and details they have seen in their travels; this formed a body of knowledge upon which a designer could draw and provided an important link to the past.  Also, until the present century, engineering textbooks and encyclopedias often used to contain many examples of successful designs, both ancient and modern.   Nowadays, young engineers are generally brought up without a good knowledge of precedent and to believe that mathematics of engineering science encapsulates all they need to know. [Addis, 1990:xii]

Does this sound familiar?

13: Simplify Your Analysis Models

15

15

The best structural engineers do not need complicated models.   Be skeptical of computer results and don't over complicate analysis models.   It is commonly said, that computer software can be a valuable and reliable tool only to those who otherwise do not need it.   This is true.   In your work, make this true.

In the October 2011 article in Structural Engineer, the world renowned structural engineer Bill Baker of SOM is quoted discussing the importance of simple hand calculations when designing the world's tallest building (Burj Khalifa):

Simplicity is not easy.  Always returning to the intrinsic idea of the building gives the design process lucidity and direction.   It also helps one make essential decisions when confronted with the unique situation that arise when creating a building of such great size [Baker: 2011, 12]

He required his team perform the preliminary designs using conjugate beam theorey, which are simple hand calculations. Our software writers that work on integrating BIM with FEM/Analysis Models completely do not understand this (for example Revit/Robot or XSTEEL/RAM).   They think it is actually useful to model the entire building, every floor slope or offset, every little filler beam around slab openings, etc.  They believe this is how we do our work!  I tried to help reduce this misunderstanding when writing BIM and the Structural Engineering Community.     We can model everything, it would be stupid, but we can.

15a

15a

Computers should be used as a tool to make a design decision, it shouldn't make the decision.   If it does, you are an idiot.  Stop what you are doing and talk to someone in the office that knows better and can be your mentor - you need one.  We can model base plates and foundations as shell elements, or we can do a 3-second hand calculation or quick spreadsheet.   You choose.  This is not about trying to take short cuts.   This is about knowing what the software can provide and what it can't.   If you already know the software cannot come close to mimicking reality, where do you draw the line?  We are further along than when Nervi wrote his book Structures in 1956 but his comments still resonate today:

Theoretical results are a vague and approximate image of physical reality... masonry and concrete are far from being isotropic and elastic.  Theory of structures considers our building as being out of time, in a kind of eternal stability and invariability.  But the simple and commonplace fact is that all structures decay...thus this second assumption is also unrealistic.  No soil is perfectly stable nor settles uniformly as time goes by.  All building materials flow viciously...cements and limes keep hardening for decades... theory of structures may be compared to the physiology of perfect organisms, which are permanently youthful and untouched by disease or functional deficiencies.  This kind of physiology is certainly indispensable in a school of medicine but such a school would graduate very poor doctors... the preeminence given to mathematics in our schools of engineering, persuade the young student that there is limitless potency in the theoretical calculations, and give blind faith in their results.  [Nervi: 1956, 15-16]

Is the concrete you are modeling Hookean (linear-elastic)?   Do plane sections really remain plane?  Is that foundation a true pin, a fixed point, or somewhere in between?   My point with these question is to convince those who rely to heavily on computers that these models, no matter how complex, still fail at mimicking reality.  I am not suggesting that we don't need to know about the state of the art in analytical modeling, I am just pressing the point that they will never achieve reality.   Sometime complex FEM modeling is unnecessary and does not contribute to a good design decision (for example, the modeling of a simple spread footing - don't do that).

In the book "Structural Engineering:  The Nature and Theory of Design" William Addis is concerned about how our educators may also be misleading our students when stating:

Students are now told mainly about the mathematics and engineering science relevant to engineering works, but not how to use this knowledge in design.  Nor are they taught the importance of other types of engineering knowledge in design, such as a qualitative understanding of structural behavior, precedent, empirical data and rules ('rules of thumb').  And lastly, they are poorly educated as to the limitations of theory, how and when its efficacy in design might be suspect, and when it might need to be supported, for instance, by tests or physical models.  [Addis, 1990]

David Krakauer of the Santa Fe Institute describes the m^cubed phenomenon or m^cubed mayham as confusions that arise in people minds between mathematics, mathematical models, and metaphors.  I would simplify this and call it m^squared and lump mathematics and mathematical models together as models.  In the past, I have described the FEM models we use in engineering practice differ from the real world and highlight how our models should never be assumed to mimic reality, but are simply tools for us to exercise our engineering (or moral) judgement (in my case, to design safe structures).  We should never mix up the model for what is actually happening in the real world.   This is analogous to Krakaur’s models and metaphors. 

Krakauer says in Harris’s book Making Sense

“you can talk about spring and levers and these are physical artifacts…and then there are mathematical models of spring and levers” and “there is this tendency to be epistemologically narcissistic.  We tend to take whatever current model we’re using and project that onto the natural world as the best-fitting template for how the natural world operates…for many reasons the model is imperfect, computers are not robust”.  

It is not that computers are not robust, they can be robust, it is that they don’t need to be – we humans need to be robust. We need to better understand computer models (and output) and not be subjects to its authority.   This is a actually a question of dominion – we need never forget that we rule over it. Also, to Krakaur’s point, we need recognize when we are being epistemologically narcissistic - it happens all the time and it is really lazy thinking.  This will make us better engineers.  We need to constantly question our models. Again models serve us, not the other way around.

14: Get into the Details

Become super technical (root pass tolerances of CJP bevel welds or stirrup spacings for example) because actively understanding our codes and science is essential.   It is also unlimited.  Yes it is knowledge, but knowledge is an inevitable result of doing engineering (knowledge is mainly the experience portion of our know-how).  

I have found that E-Readers are great for getting into the details of codes.    We cannot possibly know all that is in the endless codes we need to use.   So, you can add them all in PDF on your E-Reader (Kindle, Nook, etc) and read in bed.    If you have trouble sleeping, there is nothing better!   Also, you wake up with new knowledge (experience).

Memorization is less important since engineering is not knowledge based, it is know-how based (See "What is Engieering exactly?").   Knowledge like "A490N bolts cannot be galvanized" is important but this knowledge simple comes through experience, through process, through work.   The know-how of where to look for knowledge is more important than knowledge or facts themselves.   The other way to gain knowledge is through ignorance and knowing when you need help.   With understanding of your own ignorance, comes desire to learn.  That is really all you need.

15: Constantly Prod Yourself

We need to constantly prod those around us to wakefulness by asking questions like "why did you chose this over that" or "what factors led to the decision to do that?" etc.   These should be internal questions too.  If no one is around to prod you, prod yourself.   If you need a poker to prod yourself, buy one.   Don't get lost in the codes, details, loads prior to looking at the full picture.  If you have trouble looking at the structure as a whole (or connection as a whole, weld as a whole), then you are not effectively managing your time.  You will have trouble seeing what you need to focus on.   You need to determine which areas of the project need special attention and which do not.   After all...

What we see depends mainly on what we look for.  [John Lubbock]

16: Know Engineering and Architecture History

Knowing our history, our leaders, our heroes, our world's architecture is not something that needs an explanation.   How is this not part of the curriculum? History helps us use our long tradition of building structures to push new boundaries in our workplaces.  We can stand on the structures of the past and learn to improve future design.   We need to try to work daily towards rejecting the status quo but only after we fully understand why.  History will help us.

In Henry Petroski's book Remaking the World he states:

Engineering ideas and designs are seldom of themselves. Historically, they came out of the oral traditions of the crafts, in which nonliterary thinking abounded, and out of the pictorial catalogs of devises and structures that comprised the notebooks of early engineers...the creative engineer owes a debt to earlier engineers, for it is the wealth of clever artifacts , machines, and schemes they have left for us to climb upon and use that serve as the bases of ideas for the present and future.  [Petroski, 1997:47]

Eladio Dieste is shown above, born in Uruguay, created stunning structures with his revolutionary approach to building with reinforced masonry.  We need to know him.

17: Do Not Seek Beauty, Let it just Become

How do structural engineers design beautiful works of "structural art"?  Nervi and Salvadori give us some clues.  In the forward to Nervi's inspiring and wonderful book Structures, Mario Salvadori reminds the readers:

Nervi's results are not achieved by consciously trying to meet aesthetic demands, but by tackling the fundamental structural problems from the outset, and giving them an obvious and clearly articulated solution.  Beauty, says Nervi, is an unavoidable by-product of this search for satisfactory structural solutions.  [Salvadori 1956:  vi]

Nervi states the importance of structural honesty or correctness:

Every improvement in the functionality and the technical efficiency of a product brings out an improvement in its aesthetic quality...there is no doubt that any product of high efficiency is always aesthetically satisfying.   In the field of architecture, in which functional, statical, and economic needs are intimately mixed, truthfulness is an indispensable condition of good aesthetic results... architecture that satisfies these conditions - that is, a correct work - may be aesthetically insignificant or expressively beautiful, depending on the actual and unconscious capacity of its designer, but will never be aggressively annoying.  [Nervi 1956:  26-27]

If you have been reading this blog, one recurring theme is that idea that engineering is more of an art than a science.   Not art as beauty or aesthetic vision, not at all.   We should not consciously drive toward beauty, since beauty is a by-product of working well.  Instead of trying to create structural art, work honestly in the present ...similar to my idea of living a goalless life.  About 4 years ago prior to reading Nervi's Structures, I was so inspired by Nervi that I wrote this poem with the following last line:

Truth in form as the means, and beauty as the end.

It is not the unattainable "truth" that is useful here, it is simply avoiding that which is not structural correct or appropriate.  and living in it and with it, beauty just becomes.  There is something called “design science” (bio-mimicry, form finding, geodesic geometry, etc) which has mathematical, scientific, and objective procedures to create form.  So “truth in form” is okay in the poem -  but again, it rare that good design is driven by scientific methods.   It can be, but often not.   So, if I could re-write this, I would replace “truth in form as a means”, with “quality as the means”.   Quality, is by definition, process.   As Pirsig (the father of the metaphysics of Quality) would say, quality is “the knife edge of experience”, and living in it and with it, beauty just becomes.

I also tried to write an article about the importance of using Plato's trinity (truth, beauty, and goodness) to drive better design, not sure I succeeded but if interested, see Architects are from Plato.

18: Throw Away Your Alarm Clock

I admit, this is sort of a luxury I have.  I haven't needed an alarm clock for 15 years.   The most important part of my day as an engineer is lying in bed awake for about 20 minutes or so after slowly and naturally waking up from sleep.  The reason it is so important is that I am honestly the most creative and inventive at this time.   Not only do I lay out my work day, I literally solve engineering problems in my head.  I can view the entire project, rotate it in my mind, find problems with the design, prioritize where I need to focus on the project, and improve the design.

The picture above is a project we designed two years ago and is the largest commercial building in the US made out of shipping containers (35 total).  This was partially conceived in the morning waking up from sleep (the 1/3 cantilever and 2/3 backspan).  I can think better then because part of my subconscious is still present consciously.  It hasn't scurried to the back of my brain yet.  Also, it is super quite at 5am or 6am (my 3 boys are still sleeping).  I think the combination of the fact that I was dreaming about many structural engineering issues and then waking up naturally in a peaceful and quiet state creates this clarity of thought.  Throwing away my alarm clock helped me be a better engineer.  It might be the secret to creativity or inventiveness.   If you need an alarm clock, try to go to bed earlier.   Waking up abruptly to a loud noise must be awful, I can't believe I did that through college.   I know this is a luxury that mostly older people have, but it could be incredible useful for everyone.

I am grateful for projects that last more than one day because I will be able to sort them out in the morning.   Try not to finish deadlines at 6pm, finish them at 6am the next day (or 8am).

In Gorden Glegg's The Design of Design we find the following:

History tells us that in fifteen creative artists in various fields from music to mathematics, their key inspiration came suddenly and unexpectedly and never when they were working at it.   This is what they were doing at the time:

  • Half asleep in bed - 4
  • Out walking or riding - 3
  • Traveling - 3
  • In church - 2
  • At a state dinner - 1
  • Sitting in front of fire - 2

Concentration and then relaxation is the common pattern behind most creative thinking."  [Glegg 1969: 18-19]

So, make sure you have time for reflection (not "working") and it will be the best work you did that day.

The Simone de Beauvoir footbridge by PR firm in Paris is shown above.   My guess is this was conceived around 6am.

19: Succeed in Reducing Idiocy

Robert Pirsig complained about a bad motorcycle mechanic when writing Zen and the Art of Motorcycle Maintenance after dropping off his bike at a shop after the engine had ceased up and caused the rear wheel to lock up. When walking into the shop, a radio was going full blast and the mechanics were clowning around and talking and did not seem to notice him. When one of them finally did, they immediately misdiagnosed the problem. This caused three overhauls and the original problem became a much larger problem. Then Robert Pirsig describes the mechanics next move:

He brought a hammer and cold chisel and started to pound something loose. The chisel punched through the aluminum cover and I could see he was pounding the chisel right into the engine head. On the next blow he missed the chisel completely and struck the engine with the hammer, breaking of a portion of two of the cooling fins. [Pirsig]

Then Pirsig later thinks to himself:

Why did they butcher it so? That sat down to do a job and they performed like chimpanzees. Nothing personal in it…they were good natured, friendly, easygoing – and uninvolved. They were like spectators. You had the feeling they had just wondered in there themselves and somebody had handed them a wrench. There was no identification with the job. No saying “I am a mechanic” [Pirsig]

What Pirsig is suggesting is that this guy was not a mechanic and should not call himself one. He was an idiot. Just like engineers, we have amongst us plenty of idiots, plenty of spectators that follow procedures or slaves to the status quo, non-thinkers. But Engineers are not spectators. Engineers actively engage projects to reveal solutions to problems or yield new ideas. Matthew Crawford, in the terrific book Shop Class is Soulcraft, describes the difference between an expert mechanic and an idiot:

The forensic perceptual expertise of the engine builder is active in the sense that he knows what he is looking for. But with the idiot we see the result of a premature conceit of knowledge. [Crawford: 2009, 98]

So knowledge itself is not what separates an engineer, or mechanic, from an idiot. The idiot actually did know how to work on a bike and had some knowledge. The most important difference is not knowledge acquisition but the recognition of ignorance. An engineer, like a master mechanic, is self reflective and constantly aware of the possibility of making a mistake.   Mistakes are going to be made, whether you are an idiot or an expert.   So that is not the issue.   After all, it was Niels Bohr who famously said:

 An expert is a man who has made all the mistakes which can be made in a very narrow field.  [Niels Bohr, Danish physicist]

Before taking a hammer to the problem, the engineer (or master mechanic) reflects and asks questions regarding the design solution. Questions such as “is this the best solution of all the possibilities” or “is this the right material choice” or “am I correct in assuming this can be treated as in this simplified fashion”.

Mistakes will still reveal themselves in projects, but engineering is not about past projects, it is about taking action now on the current project and taking it to a lower state of imperfection. Since problems in engineering are rarely simple or straightforward, it takes a high level of self reflection, teamwork, and attentiveness. Since our mistakes live as long as us, it also takes great deal of humility. The best of us recognize that these mistakes are lifelong reminders that we are at times idiots too, just like everyone else.   So we need to succeed in reducing idiocy by being attentive and by participating actively in every project.

This picture above is the worlds second largest portable hammock we designed last year that brings people together to a public park.  I think we succeeded in reducing idiocy on this project, and that is the definition of success.

20: Worry Often

Worrying about your design will make you better.   You will be better able to prioritize which part of the project needs more attention and hopefully this worry comes prior to construction so it can be corrected if needed.  James Gorden in his book Structures writes:

When you have got as far as working drawings, if the structure you propose to have made is an important one, the next thing to do, and a very right and proper thing, is to worry about it like blazes...it is confidence that causes accidents and worry that prevents them."  [Gorden]

In Henry Petroski's book Remaking the World, he states:

Many engineers see to have spent so many sleepless nights while their designs were progressing from the back of an envelope through increasingly complex nd detailed calculations anddrawings to the realization in an artifact upon whose safety the lives of so many depend.  If engineers do sleep, it is often with a pad and pencil nearby.  They are there to record not dreams, but nightmares, nightmares about collapses and explosions to be checked upon waking against the realty of a design.  And it is a good thing, for otherwise there might be more tragedies than we can imagine." [Petroski: 1997, 68]

• Settings >> Advanced >> Code Injection >> Footer