When I was and undergrad and junior grad student, I regularly burned myself out on deadlines. I actually work WAY harder now. And I'm able to do it because I learned to manage my energy better. Here are some lessons I learned.
Thread. 👇
The most important thing I learned was to recognize if I'm not working productively on something and step away. To make a sports analogy, pushing through fatigue is how you get better but you shouldn't push through injury. Taking a break early can give you a lot more time back.
Another lesson was to take recovery seriously. Previously, this meant sitting in a catatonic state after I had overworked myself. I now have processes for winding myself down daily, weekly, monthly, and annually. They include meditation, yoga, writing, and doing non-work things.
Also: rest doesn't have to be passive. As a former runner, I learned that cross-training (doing other aerobic workouts) was important for staying fit and preventing injury. Actively working different parts of your mind can be more effective than resting your mind altogether.
And sometimes, recovery just means doing nothing. To everyone who feels pressure to always be doing something: it's a whole lot more productive to rest BEFORE you get burned out than after. If ever you want to feel better about doing nothing, just ask me how much Netflix I watch.
I saved one of the biggest lessons for last: reducing angst overhead. A lot of the time I used to spend working, I was actually angsting. This took energy and did not get me anywhere! This was such a big lesson for me I wrote a blog post about it here: jxyzabc.blogspot.com/2016/03/the-an…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
"Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints," Cousot & Cousot, 1977. Introduced abstract interpretation for statically analyzing program properties. Now used by Airbus.
"Design and synthesis of synchronization skeletons using branching time temporal logic," Clarke & Emerson, 1981. The first paper on model checking for program correctness. Led to the 2007 Turing Award.
Just had an good conversation with @panmanphil about data flows:
🧐 Why enforcing privacy/access policies in software is hard
😫 Why static and dynamic analysis aren't the solutions of people's dreams
🛣️ Why data visibility/data mapping is The Way
THREAD 👇
@panmanphil 🧐 Enforcing security/privacy policies on data flows is not as simple as checking a rule as data leaves the database. *Which* rule you check for *what* data matters and is hard to keep track of. Either devs need to track this or software needs to track this. It's hard for devs.
@panmanphil 😫 Automatic policy enforcement requires automatic data tracking. Tracking data at runtime comes with unappealing performance overheads. Tracking it statically, before you run, gives you way too many false positives. Anything short of this leaves major gaps.