#staffplusnyc — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #staffplusnyc, aggregated by home.social.
-
@PlaneSailingGames Oh yeah, same experience when I was live posting at #StaffPlusNYC except that the client kept autocorrecting it to #startrek /o\
I'd like that feature too.
-
Snagged a (signed!!) copy of The Staff Engineer's Path by @whereistanya at @TheLeadDev #StaffPlusNYC yesterday - real excited to dig into it! Thank you Tanya!! 🙌
-
Fire alarm goes off at the hotel at 23:00, NYFD calls for a building evacuation. Nothing like trekking down 15 flights of stairs, having just fallen asleep. Judging by the lack of urgency and the multiple groups of high school seniors, I am (wildly) speculating that someone bought some weed and tried to smoke it in their room. More stories to tack onto my wrap-up of #LeadDevNYC and #StaffPlusNYC.
-
After a good and very full day at #StaffPlusNYC hosted by @whereistanya , it seems timely that @readwise have me this highlight first in my review tonight.
-
And that's a wrap! Thank you so much to all of the organizers, speakers and behind the scenes folks for a fantastic experience today. 🙏 I love this conference. #StaffPlusNYC
-
[I'm back!]
Different types of mentors: you might have technical mentors, people who can help you with career paths, industry mentors who you can learn from.
Once you know how you want to approach the mentoring journey, look at documenting the goals. Organizations have a north star. Find your *personal* north star too.
Who do you want to be? Where do you want to be? Then: what goals do you need to get there? What mentors will you need?
-
Last today at #StaffPlusNYC, we have Rodney Cobb on mentoring and discovering his inner artist.
-
Four ways to be vulnerable:
1. Admit what you don't know. Ask for help when you need it.
2. Share when you're struggling.
3. Develop an awareness of how vulnerability feels.
4. Find a friend to practice being vulnerable with. It gets more comfortable the more you do it. -
Vulnerability needs boundaries. It doesn't mean you should freak out and scare people.
-
But then she watched Brene Brown's TED talk and read her book. She learned that vulnerability is at the root of building authentic connections.
Vulnerability doesn't mean that the discomfort goes away. You might still feel anxious and nervous... but you can frame it for yourself as excitement, which helps.
-
Christina felt that it was important to project a professional image, and she avoided being vulnerable: she didn't feel comfortable asking questions, making mistakes, letting her guard down, asking for help.
But by avoiding being vulnerable, she was limiting the connections and trust she could build with her team–and running straight towards burnout.
-
Now we have Christina Chan on leading with vulnerability!
As leaders and role models, we have the power and the privilege to create the culture we want to have. We do this by leading by example and leading with vulnerability.
-
Then an even bigger corp came along. And they wanted 500k users in a single instance... within 10 weeks. 😅 Would it work? They definitely couldn't run 500k headless chrome instances to find out.
So they started building Koi Pond. A koi is a Slack client simulation in a single goroutine. "Just had to reimplement the Slack client in go". The koi work in formations to simulate real group behaviour.
LIVE DEMO!
-
So, next load testing software: Puppet Show, which used the actual Slack client via lots and lots of headless chrome instances. The puppets would check in with the Puppeteer and do realistic things that a user would do. It was very high fidelity testing. But it was *really* expensive.
-
3. And the thundering herd of all of the slack reactions heading down the websocket pipe at the same time.
"It balloons a bit quickly." 😅 (I can believe it.)
-
So the API blaster was working ok, but then EvenBiggerCorp came along. They wanted a channel for all 300,000 of their users, 100,000 active at the same time. That's a bit scary for at least three reasons:
1. Massive fan out. If someone says good morning in the channel, it's fanned out to 100k clients all at once.
2. Event floods. People chatting to each other in lots of channels, with all of those fan outs happening all on top of each other.
-
Great walk through the Slack architecture. Sorry, no way I can reproduce this via live-post; you have to watch the talk!
-
Slack had a massive customer who were already pushing the boundaries of what the systems could handle... and wanted to do more.
To make sure it was safe, the team created a tool, "API blaster", which does what it sounds like.
But it didn't test one critical component, the websockets stack.
-
Next at #StaffPlusNYC we have Slack's Maude Lemaire with a talk about moving from "letting our customers load test in production for free" to having a really deliberate load testing strategy.
-
Making the connection let him sponsor someone as the first principal IC in the Shanghai office. Part of the job is advocating for others. If you don't get to know people, their motivations, their goals, you limit your potential for building great products with great teams.
-
It was impossible to find times that everyone could meet. Everything was over email.
Still, they had a working product in six months, without ever meeting. It was a success, but it didn't feel good. He didn't have any relationships with the people on the team. He didn't know them as people. The pandemic made that worse.
So he started having 1:1s just learning about people, deliberately making a connection, building trust. When you're remote, you have to do that deliberately.
-
Tension: the team wanted to own the project. David's supposed to be a consultant architect, but it feels like he's on the outside looking in. They have design meetings at times he can't make it to.
The team wants to be autonomous and not blocked on Redmond, but David is the "gate" they have to go through,.
-
But then...
A PM wrote a spec for an Azure service that's based on SignalR. The library's going to be offered as a major service. And the team working on that product will be in Shanghai.
David's still the architect for the project, but now he's the only person who's remote.
-
Being in the same location means it's easy for the bond to transcend work.
Customers started to use the product, and a community started to form around it. David got to start engaging with customers about the thing he'd helped build.
Then he found out that SignalR was going to be integrated into MS Office. (He found out from a news article.)
And then someone wrote a book about it. And then it was used in Bing Chat.
Lots of growth. Still very much his project though.
-
He started a side project, working in his free time, and got permission to open source it. But then he got permission to turn it into an official project. Now his project had seven people: it wasn't his toy project any more.
A moment of growth: realising the new contributors weren't slow, they just didn't know the tech. Once they got a chance to learn, it was great to see them growing in their roles.
They got an office where they could work, play, and whiteboard together.
-
David joined Microsoft at the heart of the Steve Balmer era. Lots of exciting things happening, and competing in the age of the internet.
Two big applications that seemed like game changers at the time: Etherpad and Google Wave. Really interactive, collaborative software.
David wanted to build something to understand how apps like that were made. He started working on SignalR.
-
Next we're going to hear from David Fowler, recently promoted to distinguished engineer at Microsoft. 👏
We're going to hear a story of growth.
-
-
Final episode: Typewriter. This episode tells us about resourcefulness and problem solving. sometimes the right thing is to stay out of a problem Because it's an excellent opportunity for someone else.
-
Story 3: the episode Promises. And we're looking at another data migration story. Polina originally refused the project because it looked like another ten year migration. But she got a promise that she could trust: an engineering-wide OKR.
We need trust in our interfaces, our relationships, and our commitments.