Every performance review season, I send out the following email to the team. Having refined it over the last 3 years, it’s finally at a state where I feel good about sharing this externally, in case it’s helpful to others:
Here’s my biannual email with some misc. performance review tips. Many of these might be familiar to you already, but here’s a refresher nonetheless!
For your reviews, start thinking about the content early / jotting down notes, especially for the impact questions for you and your peers. I personally find it very difficult to list all the different…
Most projects should have a Directly Responsible Individual (DRI). This role might have different names depending on the company: project lead, tech lead, benevolent dictator… (ok, I might have made up the last one). At the end of the day, it’s the project DRI’s responsibility to make sure the project is successful.
This is worth repeating and internalizing because the buck stops with the DRI. If the project fails because it wasn’t staffed with the right people, or the elegant technical solution you built didn’t solve the actual product problem your customers have, or any of the other myriad reasons…
At Plaid, we make heavy use of Amazon-hosted ElasticSearch for real time log analysis — everything from finding the root cause of production errors to analyzing the lifecycle of API requests.
The ElasticSearch cluster is one of the most widely used systems internally. If it is unavailable, many teams can’t do their work effectively. As such, ElasticSearch availability is one of the top SLAs that our team — the Data Science and Infrastructure (DSI) team — is responsible for.
So, you can imagine the urgency and seriousness when we experienced repeated ElasticSearch outages over a two-week span in March of…
As a female software engineer, I am counted in most diversity statistics and involved in many diversity initiatives. I’ve been to Grace Hopper for the last 5 years, including giving a tech talk last year on web performance. I was a mentor for Women Who Code, teaching algorithms and coding weekly to women entering the tech industry. I am literally on this list of women engineers even though I have no idea how I got added in the first place.
Here’s a surprise for you: I am not that diverse.
I’ve always found that writing book takeaways as I read helps me process the information from these books. And I got some good feedback the last time I wrote a book takeaway for Creativity, Inc. So here’s a long overdue 2nd installment in my very informal book takeaway series. This time, I’m reading Drive by Daniel H. Pink, a classic read on the theories of motivation.
Almost everything in this post is taken directly or summarized from the book, with the exception of “Angela’s Notes” which are my own thoughts that I’ve sparingly sprinkled below.
As a software engineer, I spend a lot of time reading and writing design documents. After having gone through hundreds of these docs, I’ve seen first hand a strong correlation between good design docs and the ultimate success of the project.
This article is my attempt at describing what makes a design document great.
The article is split into 4 sections:
A design doc — also known as a technical spec — is a description of how you plan to…
Since starting my career as a software engineer, I’ve learned that scoping is one of the hardest things to get right. Unfortunately, CS programs in universities don’t really teach you how to scope projects. So here’s my attempt at consolidating what I’ve learned on this topic.
Scoping isn’t something that you can spend a day on during the project and never think about again. In fact, to scope a project accurately, you need to pay attention throughout the project during:
When I was a bright-eyed senior at MIT interviewing for my first full-time job, the part of the interview process I dreaded wasn’t the algorithm design or the complexity analysis. It was the moment at the end of each hour-long interview when my interviewer would ask me: “Are there any questions I can answer for you about <company>?”
This question scared me. I didn’t know whether asking a tough question would reflect poorly on me and reduce my chances of receiving an offer. I didn’t want to appear like someone who would be difficult to work with. …
After many friends independently suggested this book, I finally bought Creativity, Inc by Ed Catmull (Pixar) at a bookstore in SFO. Even though the book is about Pixar’s process to foster creativity, it is actually extremely applicable to software engineering and the general process of developing products and company culture. So I figured I’d share some of my personal takeaways. Disclaimer: I don’t claim to accurately reflect the author’s point of view. These are just some of my learnings and thoughts as I read the book.
Also, in case it isn’t clear, spoiler alert.
The main idea repeated time and…
Eng manager at Plaid, previously Quora & MIT