Structure First. Make It Work. Ignite Others.

When a hurricane dataset froze my screen at 2 a.m., I came up with and wrote down three principles that now guide my PhD journey: structure first, make it work, ignite others.

At 2:07 a.m., my VSCode froze on a 15-minute power-outage log from Hurricane Beryl (July
2024), work I’m doing under Dr. Ali Mostafavi. The script should have rolled through
thousands of rows. Instead, it looped on a bad join. I wanted a perfect pipeline, and I needed
a working one. That night I wrote three lines that now steer my graduate life as an
Engineering PhD student: Structure first. Make it work. Ignite others.

1) Structure First
Graduate school multiplies variables, including but not limited to datasets, deadlines, drafts,
people. When the surface looks chaotic, I then start by drawing edges. What is the unit of
analysis? What counts as “done” for this task? What is out of scope for this week?
For the Beryl project, the edge was strict: compute customer-minutes of power outage per
ZIP per day before any modeling or visualization. No exceptions and no side quests.
Structure isn’t bureaucracy, but rather it’s load-bearing clarity. I keep one page per effort:
goal, inputs, outputs, failure modes, handoffs. Meetings shorten, code reviews improve, and
I spend less time arguing with my own assumptions. When the scope is explicit, I can say no
without guilt and yes without fear.

2) Make It Work
Real systems reward runnability, the ability to run, more than elegance. I still love proofs, yet
I ship prototypes. On that Beryl script, the “perfect” design used a stack of abstractions. The
working version used a plain groupby (grouping rows by ZIP and day), explicit sorts, and
defensive checks for duplicated timestamps. It ran in minutes. Only then did I refactor.
“Make it work” doesn’t mean ignoring correctness or errors. It means sequencing standards:
correctness at today’s resolution, reliability under today’s load, then performance and polish.
I test on a small slice before the full run. I log intermediate tables to catch silent errors. I treat
every dependency as risk and keep a rollback plan. In the wild, simple systems degrade
gracefully, clever ones can shatter. This principle also changed how I learn tools: if a
method, library, or model won’t serve a live research question this month, it goes to a
parking lot. Curiosity stays but also delivery leads.

3) Ignite Others
Nothing durable in graduate school is truly solo. My best weeks came from short, specific
coordination: a five-minute check on a colleague’s map projection; a one-page runbook
when a room change broke a workshop plan; a shared glossary so “ZIP,” “ZCTA,” and
“service area” stop colliding; a weekly meet up with my PhD advisors and mentors. When I
write docs, I write for the next person at 1 a.m. with a deadline and a bug. When I ask for
help, I attach a minimal reproducible example so the other person can succeed quickly.
Igniting others isn’t just cheerleading, but rather it’s engineering for handoffs. Clearer
interfaces, smaller blast radius (scope of failure), fewer surprises. People respond to being
set up to win. Work accelerates because trust replaces friction.

What These Principles Changed
They gave me a way to choose under pressure. When time is tight: I draw the boundary
(Principle 1), ship a small working slice (Principle 2), and leave the path brighter than I found
it (Principle 3). The order matters. Without structure, I can build the wrong thing quickly.

Without runnability, I never reach users. Without ignition, I carry everything alone and burn
out.

They also cut noise from my calendar. I commit to fewer things, finish more of them, and
then make the finished ones easier to maintain. The compounding shows up in calmer
mornings, tighter error bars, and teammates who bring their best because the system lets
them.

Therefore, here is how I start this week:

• Pick one active project (for example the most important one right now). Define the smallest unit a peer can verify as progress. Write it down.
• Implement that slice in the most boring way that works. Add two assertions and one log.
• Leave one artifact that reduces someone else’s time to first success, it can be a short README, a tiny demo, or a checklist.

Graduate school isn’t a test of stamina. It should be a test of systems. These three principles
are the simplest system I know for turning chaos into work that moves. If they help you finish
a page, fix a script, or run a better meeting this week, I will be very glad to see that they’ve
done their job.