As a tech lead or eng manager, you so frequently get request from above or from other teams to drop what you are doing and work on this thing they need, *now*.
During my 4 years at Uber after asking these questions, 9 out of 10 times it turned out it wasn't really urgent:
1. "What is the impact of this work you're asking for?" If the impact is unclear: sorry, but we can't do the work. Why would we?
Just this question made the requester realize half the time they just think it's urgent, but don't know what the work will actually result in.
2. "Do you have a spec that is agreed with stakeholders?" A writeup answering the "why" and the "what" that is signed off by relevant business folks.
I've seen so much engineering work thrown out as later the business goes "that's not what we wanted, why didn't you tell us?"
3. "We're not committing to any work before we have done a rough estimation."
With #1 and #2 done, many stakeholders will come and say "drop what you're doing, this is a 3-day work we need ASAP."
Hold your horses. You don't make estimates: the team doing the work does...
4. Make the cost of dropping what you're doing very clear.
This cost is always forgotten by the person coming with the request. But it's a relevant one: wrapping up work, onboarding to the new work, then later onboarding to the old work. Plus a hit on morale for a sudden change!
Uber has some very hectic times when there were reasons we needed to do some new work ASAP. Like a regulation change that means the company would be banned from operating in a region if not building something.
Even in such a place, most "urgent" things turned out to be noise.
The way I always approached these requests was to educate the person coming with them, and have them realize their work is actually not as urgent or as important or as impactful of what the team is already doing.
Doing so meant building empathy both ways, and less hard feelings.
A huge upside of this approach: when committing, you *can* commit with a very high certainty that you will not be interrupted with your work.
The alternative: take on this "super urgent" work, then someone else comes along saying " I need you to drop what you are doing *now*..."
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The more I use GenAI coding tools, the more I am convinced keeping to "traditional" software engineering practices is what works most productive here. As in 10x more productive. E.g.
- Small changes
- Test that the change works before moving on
- (unit) tests wherever you can
Amusing how error-prone all of these models are
I catch how often it generates buggy code thanks to testing and adding unit tests (I have it usually generate tests and then I tweak for my test cases)
Don't know how people are productive who let it run loose tbh
All those non-devs parroting how GenAI is the end of software development don't do actual development. And esp not wit these tools.
I am pretty confident Meta will have no "AI engineer that will start contributing increasing amounts of code" beyond being a companion like today
One interesting I’m seeing with GenAI coding tools:
The MASSIVELY help technical founders at small and mid-sized startups prototype, challenge dev team, and ship products faster.
A recent example I’ve seen (cont’d):
Founder: “here’s a product idea we should do.”
Dev team: “Ok. We’ll build a prototype. It will be ~2 weeks.” 1 month later there’s a prototype. Another 2 months to ship to customers.
Now: founder builds prototype in ~4 hours, shows to dev team. Team builds a more prod ready one in a week and ships to customers!
I have only seen this work with *technical* founders. Ones who used to live and breathe code and built the first version of product themselves. But as team grew to 10-50+ ppl this was no longer an option.
GenAI is revitalising them - and the product iteration shows it!!
Meta created React Native. It’s used (with components at least) in their flagship apps: Facebook (iOS, Android), Instagram (Meta Quest), Messenger (desktop).
Google created Flutter. And yet none of their flagship apps use it (Gmail, YouTube, Maps, Calendar).
The only flagship Meta app not using React Native is WhatsApp.
Google does build a lot of smaller apps with Flutter.
Just odd that Flutter can be used as modules (for a few screens) but Google, for some reason, doesn’t do with major apps.
Food for thought.
Flutter powers more apps than React Native: but more iOS apps are RN than Flutter.
Large-scale case studies published are mostly RN. Flutter case studies are usually smaller apps.
More details on each technology, and other Flutter and RN alternatives:
This is how Copilot Workspace works. Covered 8 months ago in @Pragmatic_Eng at
I personally think it's a clever workflow that aims to make devs more productive (and not replace them, like tools like Devin advertise themselves to the business) newsletter.pragmaticengineer.com/p/the-pulse-92
My first impression is that this workflow is pretty good. It hallucinates / doesn't do what it needs to do, but I can correct it early enough.
For experienced enough devs who know what they are doing: this workflow could work pretty well: better than the "give a prompt and the AI does the magic" stuff