I Wrote a Paper

It has been nine months since my last post. Yes, I am still alive. No, that marathon did not kill me. Despite my prolonged absence, I am happy to report that it has been a productive year. Regrettably, most of my mental energy had been directed at my day job rather than this website. There’s quite a few exciting projects at work that demanded my attention, which meant not much time for anything else. After a particularly grueling summer, I am ready to shift focus. I have about 6 side projects, and 17 reading journals on the backlog. As expected from yours truly, rather than writing or coding anything substantive, I’ve spent the past 2 weeks adjusting typography, font size, and the color schemes. This is known in the procrastination industry as yak shaving.

Why was I so busy this summer? Well, aside from working overtime every week, my spare time was spent solely on writing my first paper, which I presented in September at the Annual SEAOC Convention in Portland. I just want to say: Holy shit, writing is really hard. Unlike my blog posts, which are essentially more verbose form of shitposting, there is a level of rigor and clarity of mind that is demanded in academic writing. I also wanted my first paper to be good; a mindset that guarantees misery. Anyways, after a summer that can only be described as a mélange of excitement, confusion, aha-moments, scope-creep, development hell, rewriting the same paragraph over and over, self-doubt, anger, acceptance, I did eventually submit my paper, on time, but with mixed emotions. On some level, I wish I had started sooner so I can run more experiments. At the same time, I’m glad I did not, because I know I would have submitted minutes before the deadline regardless of if I had 2 weeks or 2 months to work on it.

SEAOC 2024 Convention

I’ve always wanted to attend an engineering conference, not in the “I love Legos” college admission essay kind of way, I really did want to attend one! It would be amazing to meet legendary professors in person, learn about the engineering wizardry behind fancy buildings in architecture magazines, pick up on industry trends and new software, meet Ashraf (CEO of Computer & Structures Inc) in his outlandish LED suit at his equally outlandish CSI parties, meet vendors, and leave with a bag full of pens, rulers, highlighters, stickers, calc papers, and other swags. (I even got a cutting board this year…)

I’m pretty sure my company would have sponsored me if I asked, but the problem is I am too awkward and I have too much pride. The only acceptable way forward was for me was to submit a paper abstract and hope it gets accepted. “It’s not like I want to go. My abstract was accepted so I must present at the convention. I have no other choice”. And so I submitted a short abstract. It’s based on some work I did last year with EZanchors (GitHub Link Here). I only had some vague idea of what I might want to explore; no results yet. A month later, the stars must have aligned because my abstract was accepted. I’m going to Portland!

Photo: Morning Walk In Portland (2024 SEAOC Convention)

The Writing Process

“You’re 90% done. Congratulations! You only have 50% left.” - Tim Ferris

I spent the next 2 months doing absolutely nothing, because: “I already have all the tools in place! I just need to run a few numerical studies, then write the results down. It shouldn’t take more than five days.” Oh sweet summer child…

First of all, there were at least eight bugs to fix and three new features to add, so no, the tools were not in place. Second, even if the tools were in place, I had yet to map out what experiments to run, what comparison to make, and what data to post-process. What I had in mind was vague at best, and incoherent at worst. Third, even if I managed to generate results that somehow matched my hypothesis exactly, I still had to write them down. This last point turned out to be the crux. Through the process of writing, you tend to discover hidden assumptions, imprecisions, mistakes, and perhaps new ideas. Therefore, the process of writing is iterative rather than one-directional. A finish line is hard to define and progress hard to measure. In theory, you could iterate forever and never finish. I haven’t even mentioned the PowerPoint presentation. Make sure to practice beforehand. You’ll be presenting in front of other engineers from all over the US. You have nothing to lose except your reputation. Good Luck.

The programming tasks turned out much more manageable than I had expected. As for writing, maybe I lack the talent or the necessary practice, but I severely underestimated how long it will take me to write (by at least 10x). Writer’s block wasn’t much of an issue. I had way too many things in my head as is. It was a relief to put them down on paper. The problem was the unattainably high bar I set for myself. I value writing that is short and succinct with a high signal-to-noise ratio. In reality, my first drafts are usually unreadable. High quality proses don’t just flow out of my head. On average, I have to rewrite each sentence at least three times in order to get the wording right.

Another high bar I set for myself was my insistence on getting to the bottom of rabbit holes. I enjoy diving down rabbit holes. They’re like a good whodunnit mystery novel. However, a mystery novel that ends with a big question mark is incredibly unsatisfying. The same can be said about a rabbit holes where you emerge with more questions than answers; more confusion rather than clarity. I put all papers into two buckets based on this categorization.

• Bucket #1: “This is a complex topic. Make sure to think really hard!”

• Bucket #2: “This is a complex topic. Here are the nuances, and here are some key insights”

The world is really complicated. Any topic you can think of, even the seemingly simple ones, are in actuality not that simple. The deeper you go, the more nuance you tend to encounter. The only people who don’t appreciate this fact are the ones who haven’t thought deeply about anything non-trivial. Surrounded by all this complexity, it is easy to lose oneself - like I have - in all the gnarly details that one forgets the big picture. What’s the point of all this intellectual exploration? I’m actually not sure, but it’s certainly not to show off how sophisticated you’ve become with smart-sounding words and Greek-letter filled math equations. As an practicing engineer, I value practicality and insight. I admire those who can wrestle with complexities without fear, and emerge victorious with sometimes surprisingly intuitive insights. I admire authors who can write papers in the second bucket, and I strive to imitate them.

Having just gone through the trial by fire, here’s what I learned about writing:

• Writing reveals blind spots - It’s only when you try to put ideas on paper that you realize you don’t understand something as well as you had imagined. In some cases, it will reveal a startling lack of understanding. Putting ideas into words is a very strict test that demands precision. Talking about a subject can help too, but there is nothing as exacting as writing.

• Writing is thinking - As I’ve said in the past, writing is almost analogous to thinking. Through writing, you tend to discover hidden assumptions, imprecisions, mistakes, and perhaps new ideas. What ends up on the final draft is rarely what you had in mind originally. In other words, writing is not merely a tool for record-keeping. To quote Leslie Lamport: “If you’re thinking without writing, you only think you’re thinking”. Until you can put your thoughts on paper, they’re just amorphous blobs of unthought; vague, underdeveloped, and inarticulate.

• Writing is really hard - After reading Paul Graham’s essay on writing, I am beginning to suspect that writing is just really fucking hard, way harder than most people realize. To be clear, I am not referring to the low-quality, transitory, bullet-point style writing found in emails, social media posts, or texts. I am referring to essays - ones on non-trivial subjects with fluid proses, clear and well-organized sequence of ideas that smoothly transitions from one to the next. Writing is incredibly strenuous mentally. My daily limit for writing is only about 3 hours before my brain turns into mush. For comparison, my limit for programming is about 6 hours, and reading about 8 hours.

About The Paper

Here’s the abstract. Unfortunately, I signed a copyright transfer agreement so I can’t publicly share my paper online. If you’d like to read more, please refer to the 2024 SEAOC Convention proceedings, accessible online (not uploaded by SEAOC yet. Will update with link once it is available).

In layman’s term, and at the highest level of abstraction, the paper is about improving earthquake readiness of buildings. Over the past century, engineers have focused extensively how to improve the structure of our buildings; making sure they don’t collapse and kill people in an earthquake. But it turns out even if a building does not collapse, it might still be made unusable for many months; sometimes permanently. The main goal of earthquake engineering in the 20th century was to preserve lives, in the next century, greater emphasis will be placed on “functional recovery”. In other words, the goal post as shifted from preserving lives to minimizing repair cost, and down time. After an earthquake, how does one go back to work when there is no running water or electricity at the office, all the doors are jammed, elevators don’t work, and your desk looks like this:

Photo: Office Closed After the Napa 2014 Earthquake

And this is just what you can see. Imagine what might happen to the back-of-house mechanical and electrical equipment like sprinklers, HVAC units, plumbing, pumps, and etc. This is a well-understood risk. In essential facilities like hospitals - which must remain operational during and after an earthquake - engineers preventatively brace equipment so they don’t slide out of position or tip over. There are literally thousands of non-structural components in a hospital, and thus thousands of braces. Given the abundance of bracing, it is important to accurately assess how much to specify. We want to fully anchor things down, but we don’t want to be overly conservative and start anchoring down water coolers because “the numbers said so”. This paper outlines how to more accurately assess how many anchors are needed, taking into account not just earthquake force magnitude, but also directionality.

---

Comments