When I started Akita, we had an office and people loved coming in.

In 2020, I pivoted almost my entire team. A big part of it: finding people who worked well remotely.

What I learned about remote vs in-office: they require VERY different cultures. You can't just flip a switch!

🧵/ Before 2020, I had my biases about offices.

To me, the office was an essential character in every story of innovation. I believed that every early-stage startup needed to be colocated to make it.

How else could you build trust? How else did the magic happen?

2/

When ChatGPT came out, I was excited about the ability to prototype with AI. Everyone now has an ML team at their fingertips!

What I underestimated: how much ChatGPT is a *UI* prototyping tool.

Quick thread about how our team prototyped 4+ new capabilities in < 1 week. 1/ At Akita, we’re building the fastest time-to-value monitoring solution, helping teams get set up to find and fix any API-related issues in under 30 minutes.

We do this by passively watching and analyzing API traffic. This means we’ve got a ton of data about our users’ APIs. 2/

Today, software is more like a rainforest rather than a planned garden. Code bases are more complex than ever before; the rise of SaaS and APIs means prod is the only source of truth.

But dev tools haven’t caught up.

Dev tools need a ChatGPT makeover. Here’s what I mean.

1/ Software engineering used to be about writing self-contained code.

Today, most software engineering is about making assumptions about how the mess of reality works, trying your best to code against that, seeing how things shook out, and repeating until it all works.

2/

I was @AdeetiU's guest at an MIT alumni event focused on MIT EECS's initiative to increase gender representation among grad students.

Afterward, we talked about how intimidating was to be a young woman in a male-dominated field.

In case it helps others, here's what helped me. @AdeetiU There's a lot of advice for women not to get talked over, to get a seat at a table, etc.

What was most helpful for me was to realize that a lot of gender differences are cultural differences. They're often not personal and they're often not consciously discriminatory.

Like many of you, I've been following what's been going on at Twitter Eng with great interest.

The current situation is undeniably extreme and terrible for many employees.

But it does share common patterns with I've been seeing across the software industry.

Quick thread. 🧵/ First off, Twitter isn't the only company to cut costs. And they're not the only ones to do it by reducing the size of their eng team. 😔

Similarly, Twitter isn't the only company with high churn. One in three American workers switched jobs during the Great Resignation. 2/

Upon popular request: skincare products as developer tools, a thread.

Starting with CeraVe Facial Moisturizing Lotion with SPF as a linter. One of the highest-leverage, lowest-cost things you could invest in. Prevents headaches and slows down aging. People often think you need to do heavyweight static analysis for code correctness, when simple static type-checking can go a long way.

Similarly, you usually don't need a harsh heavy-duty cleanser; a lightweight oil one is enough.

Next: Simple Cleansing Oil as TypeScript.

Earlier today, I talked with a (non-founder) eng leader who was wondering how much they should pick up "founder" tasks unrelated to their main job.

My take: non-founders should focus on building career equity in the form of a portfolio of personal wins. Here's what I mean. 1/ The question of what founders "get" out of a startup, versus
the rest of team, comes up often: with founders, people thinking about joining startups, etc.

A lot of people think equity is about the cash payout. The career equity is far more important—and in your control. 2/

How can it be that there's so much investment in dev tools (from both buyers and investors), but developers are still underserved?

One major reason: many well-capitalized dev tools are "exec tools" or "luxury tools." Many developer needs remain unmet.

Thread. 🧵 1/ "Exec dev tools" nominally target developers as the user, but they're primarily solving the problems that execs care about. It makes sense that these tools do well since execs do the buying. But they often meet exec needs at the expense of developer needs. 2/

I've recently talked with several people who struggle with work from home and can't wait to get back into the office.

While I'm further along the hermit scale than people might guess, I did pick up many WFH/work-alone tricks from my many years as a PhD student.

A thread. 🧵 1/ In the office, it's often about managing time but at home it's more about managing energy.

At home, you lose half your afternoon not by talking with too many colleagues in the snack area, but by talking with too few colleagues and dipping below a productive energy level. 2/

In the last few years, I've talked with hundreds, if not thousands, of software developers.

What I've learned: there's a HUGE gap between what developer-influencers are writing about, versus the daily reality of most developers. BUT PEOPLE DON'T TALK ABOUT THE OTHER STUFF. 1/ A disproportionate amount of writing and tooling comes from companies like Facebook, Netflix, LinkedIn, Google, and Amazon. Many people assume there's a trickle-down effect: great engineers at companies with money to burn come up with good solutions to problems everyone has. 2/

Been going through a lot of resumes recently.

When I had been on the other side of the process, submitting resume and cover letters felt like lobbing random stuff over a fence.

Here's a quick thread that might be helpful to people applying to jobs. 1/ There are two main things I look for on resumes:
1. evidence that someone gets stuff done and
2. the ability to communicate this to me.

More so than what companies someone has worked at, I look for bullet points and results. What did this person do and what was the impact? 2/

A few months ago, as users started throwing more API traffic at the Akita client, we started seeing multi-GB memory spikes. 🙀

At first, we hoped for an easy solution. There was none.

This is the story of @markgritter's 25-day journey taming memory usage in a #golang client. 1/ @markgritter The first thing @markgritter did, as you would do in most languages, was to profile the system for obvious bottlenecks.

There was one, in the #gopacket reassembly buffer. Memory was persisting even though it wasn't getting used.

Mark fixed this, but the problem persisted. 2/

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/

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/

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/

Taylor Swift as notable #AAPI computer scientists. 🧵

Andrew Yao, 2000 Turing Award Winner. Known for proving Yao's Principle. See also: Yao's Millionaire's problem.

#AAPIMonth Raj Reddy, winner of the 1994 Turing Award for pioneering work in artificial intelligence. Mentor to @kaifulee.

#AAPIMonth

Earlier today, @the_prion asked me what the hardest part about starting @AkitaSoftware was.

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.

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.

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.

Something I've been thinking about: "bonus skills," the skills that don't necessarily get advertised, but are often the most transferable across life stages.

Here's a thread of the bonus skills I learned at different stages of my education and career. Curious to hear yours. In undergrad, I learned how to:
📚 Skim hundreds of pages in one hour and have something intelligent to say.
🙇🏻‍♀️ Be okay with not being the smartest or the most interesting person in the room.
🤝 Be okay relying on other people when working under high pressure.

Thought about this Tweet a lot today. Yes, I agree that Parler will come back, but I have yet to see people talking about just how powerful it is that the major players in the build-yourself-an-app starter kit have decided not to support Parler.

A small thread. 👇

https://twitter.com/EthanZ/status/1348698052450775041

Back in "the day", you had to run your own servers and build most of your app by hand. You needed a small army of technical talent to scale your site, and even then it was still slow going.

Today, you can build and scale an app like Parler user mostly off-the-shelf components.