Been talking with a lot of people who are burned out at work right now. I got quite burned out at the end of college and in the middle of my PhD. Today, I work way more than I did back then and am able to feel really fulfilled. Here are some lessons that helped me get here. 🧵 1/
First and foremost, it's helpful to recognize that you're burned out. Are you feeling less creative? More irritable? Over the years, I've learned to recognize micro-burnouts (from "I need lunch" to "I need a vacation") and I like to believe that's kept me from macro-burnout. 2/
Working sustainably is key to preventing burnout. For me, i's not about limiting hours but about building in recovery. The recovery needed depends on the intensity and duration of the work. If I go for longer without recovery, the recovery will need to be longer/more involved. 3/
Here's a surprising lesson I learned about work recovery: it's not about doing nothing, but about clearing your head. For me, yoga, running, and cycling are decently good. Active mind recovery like writing or producing Zoom shows is not for everyone, but works well for me. 4/
What do if you're badly burned out? The feeling you can't ever get excited about anything again is just a feeling. Often it's not time you need, but a change of scene or different, more meaningful work. New work may be last on your list of wants, but it could be the way out. 5/
Of course, this thread only applies to people lucky enough to be able to do fulfilling work. I've also been fortunate enough never to have gotten into an extremely deep burnout funk. I suspect there are many people similar to me though! I hope this thread can help. 6/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Every now and then, I see a thread about how functional programming languages are The Way, wondering why they aren't more popular.
A big problem is that people talk about functional programming as The Way for Everything. FP has its place. All tools have their roles. 🧵 1/
The elegance of functional programming makes it an appealing "silver bullet" candidate.
But here are the domains where FP really shines: 1. Programming education 2. Prototyping language features and analyses 3. Domains where you're mostly specifying transformations
2/
I fell in love with Scheme and SML in undergrad. I taught myself Haskell and extended it for my senior thesis. In grad school I worked in Haskell, then OCaml, then Scala.
But by the end of grad school, I was mostly using Python.
Why aren't there more startups based on programming languages and software analysis?
There's definitely a need for SOMETHING, as developers have so much pain.
I was recently on a panel where someone asked this question. I didn't have time to answer then, so here's a thread. 1/
There's often a gap between the creators of "principled" programming tools and the needs of working developers.
There are two common technical assumptions: 1) code correctness is a top priority and 2) it's possible to understand the whole system.
Often, neither hold. 2/
In programming languages and formal methods there's the dream of "soundness:" if there's a bug, the tool will find it.
People don't want to know all of their problems. They want a prioritized list of problems that matter. This technical goal is often at odds with user needs. 3/
@kaifulee Jeannette Wing, who co-developed the Liskov Substitution Principle. Leader in formal methods research. Head of @SCSatCMU 2004-2007 and 2010-2012.
My answer: figuring out how to build a team that balances user-focused product thinking with the deep technical expertise required to power it (in our case).
Thread. 🧵
@the_prion@AkitaSoftware At Akita, we're making it easier to detect the API regressions that matter. We want to do this as non-invasively as possible, with the highest information content possible.
This means keeping code changes/perf overhead as minimal as possible, while keeping false positives low.
@the_prion@AkitaSoftware Keeping code changes and perf overhead as low as possible is not easy, and constantly requires balancing software architecture decisions with user-facing tradeoffs.
Keeping false positives low is also a really hard trace analysis problem that also has many user-facing tradeoffs.
A professor friend told me that some female students in her dept asked her how she dealt with being in a male-dominated field. She told them she was an internalized misogynist and didn't have any female friends, but then I taught her to be friends with women again.
Thread. 👇
It's a very human phenomenon to distance yourself from the traits that other people don't respect in you! Think about all the high school movies where the nerd ditches their nerd friends to be cool. 🥸
For any woman who needs to hear it: befriend and champion other women.
Related: I was recently talking to a group of younger female CS alums from my university and they said it was rare for them to have such a technical conversation with a woman.
I was taken aback, but realized that I also felt that way before I found other technical woman friends.
When we talk about "developer experience," we really need to separate dev tools into two categories: ones that simplify things away and ones that help developers engage with complexity. DX needs are different for simplification tools vs complexity-embracing tools!
Thread. 👇
In the "simplification" category of dev tools are all kinds of automation tools: APIs like Stripe and Twilio; SaaS products like Netlify; domain-specific languages like GraphQL.
You want these tools to be as one-click as possible and shield the developer from most details.
The most classic example of a dev tool in the "complexity-embracing" category is a debugger: it shows you your stack trace; it shows you a call graph. It lets you get where you need to go by giving you tools to explore a complex system.