The myth-busts, hot takes, explainers, and tools worth keeping.
⚡Myth Buster· 1
⚡Myth Buster1:13:30
Don't Trust AI for Quotes, It Makes Them Up
Camille recounts asking ChatGPT for quotes while writing her book and getting interesting-sounding lines that were never real, even after repeatedly challenging it. She ties it to the fake critic quotes in Francis Ford Coppola's Megalopolis trailer, which was pulled. The lesson: AI can summarize well but invents quotes, so always verify.
ChatGPT gave her compelling quotes that were not real, not a single one
Even when challenged, it just produced another fake quote
AI's fabricated 'quotes' are good summarizations, not actual quotes
Ties to the Coppola Megalopolis trailer with fake critic quotes that was taken down
General reminder: don't assume what AI tells you is true
“and they were not real they were never real not a single quote”
“so don't ask it for quotes because or if you do make sure it's a real quote”
#ai#chatgpt#hallucination#writing
◆Hot Take· 3
◆Hot Take14:30
Why Major Rewrites Are Usually a Trap
Engineers often convince themselves the only fix for a painful old system is to build a new one from scratch. Camille argues this rarely works because teams massively underestimate migration time and how much undocumented business logic is buried in legacy systems. She recommends staged evolution, uplifting well-contained pieces, over a full go-away-and-rewrite.
Engineers underestimate the time to migrate from old system to new
You must keep supporting the old system while building the new one
Legacy systems hold undocumented, weird business logic that's hard to replicate
Better approach: staged evolution, uplift contained pieces, not a full rewrite
Ask whether the system actually needs to change or is just annoying to engineers
“Engineers notoriously notoriously notoriously massively underestimate the migration time for old system to new system”
#rewrites#legacy-systems#migration#engineering
◆Hot Take28:30
GraphQL: Popular But Poorly Regarded by Senior Engineers
Camille flags GraphQL as both popular and thought poorly of by most senior people she knows. Her impression is that it promises front-end engineers they won't have to collaborate with backend engineers and can just build whatever they want, which rarely works out in practice. Unless you're Facebook, make sure you actually know what problem you're solving.
GraphQL is popular yet regarded poorly by many senior engineers
It seems to promise front-end engineers freedom from collaborating with backend
That promise rarely works out well for those who adopt it in practice
If you're not Facebook, be sure of the problem you're solving
“it is one of the things that is both popular and thought relatively poorly of by most of the senior people that I know”
“graphql is kind of trying to promise front-end Engineers that they don't really have to like collaborate with backend engineers”
#graphql#tech-stack#engineering#hot-take
◆Hot Take40:30
You Should Probably Have Fewer One-on-Ones
Camille holds direct-report and manager one-on-ones sacred, but pushes back on doing one-on-ones with every peer and stakeholder. They don't scale, since relationships grow linearly with the number of people. Worse, for stakeholder management they hide problems: an unhappy stakeholder never hears that everyone else is happy, so relying on private meetings backfires.
Keep one-on-ones with direct reports and your own manager sacred
One-on-ones with every peer and stakeholder don't scale
People who don't want a one-on-one may resent being asked
Private one-on-ones hide problems from unhappy stakeholders
Respect your own time; don't load up on meetings just because you're a manager
“you should have one-on ones with your direct reports and your manager and you should you should hold those sacred”
“your unhappy stakeholders kind of aren't hearing that”
#management#one-on-ones#meetings#stakeholders
✶Explainer· 6
✶Explainer03:00
The Things PMs Do That Annoy Engineers Most
Camille lists the easy-to-fix ways product managers irritate engineers. The first is hoarding credit, since PMs are usually the front-facing person and can absorb all the glory for work engineers did. The second is acting like technical details don't matter, which reads as a lack of empathy for engineering work.
Hoarding credit is an easy fix: share credit and let engineers speak to their contributions
Acting like details don't matter shows a lack of empathy for engineers' work
Engineering done successfully is all about the details
You don't have to understand every detail, but don't dismiss them as unimportant
“engineering done successfully really is all about the details”
Hoarding All the Ideas Makes Engineers Over-Engineer
When PMs try to own every product idea and detail, engineers lose their creative outlet in the product itself. Camille says they then redirect that creative energy into the technology, obsessing over frameworks and over-engineering things that don't matter for delivery. Quashing an engineer's voice in the product pushes them to find control in the tech instead.
PMs hoarding ideas removes engineers' creative outlet in the product
Engineers then use engineering skills as their creative outlet
This leads to over-engineering and obsessing over the 'right' framework
She can predict over-engineering wherever engineers' product voice is ignored
“I see Engineers start to over engineer things because Engineers are like well I need to take control of something”
Camille says staying credible as a hands-off leader isn't about writing code but about paying attention and asking good questions. Surround yourself with smart technical people, listen to them debug and discuss real problems, and guide with questions rather than dictating library choices. Engineers distrust long-hands-off leaders who try to tell them which tools to use.
Being technical is about knowing what's going on and asking good questions
Don't dictate library choices when you've been hands-off; engineers won't trust it
Guide with 'have you considered this' rather than commands
Surround yourself with smart technical people and listen to them constantly
She stays credible by listening to smart engineers, not by writing code
“not that I'm writing code because I'm not but I am listening to a lot of very smart people talk about technology”
The Biggest Surprise of Management: You Don't Own Your Time
New managers are most often surprised that they lose control of their own time, which the team and company increasingly own as you become more senior. People expect authority and freedom but find management is really a service job, not command-and-control. In tech especially, snapping your fingers doesn't work; people revolt, so you nudge, direct, and set guardrails instead.
You don't own your time as a manager; the team and company do, more so with seniority
Expectations of freedom plus authority don't match reality
Management is a service job, not command-and-control
In tech, ordering people around makes them revolt
The job is nudging, directing, and setting guardrails, not making every decision
“you really don't own your time as a manager”
“management really is a service job you are serving the team you are serving the company”
#management#leadership#career
✶Explainer58:00
Platforms Are Products, So Staff Them Like Products
Camille insists platform engineering must involve software engineers, not just ops/SRE folks, or you get scripts and enablement rather than a coherent platform. Platforms are ultimately products, so they also need product managers to drive impact- and outcome-based work. Leaving platform direction to engineers and engineering management alone won't produce great results.
Platform teams need real software engineers, not just ops/SRE
Without software engineers you get scripts, not a coherent platform
Platforms are products and need product managers
Focus on impact/outcome measures: cycle time, cost reductions, unblocking launches
You won't get great results leaving it to engineers and eng management alone
“frankly you need to be platforms are products ultimately”
Camille says platform teams generally make sense around 50-plus engineers, not at 10. The signals are duplicated effort (the same kind of people solving the same problems on every team) or a core scaling issue that needs a dedicated team. Don't jump in early; it's for matured companies where centralizing functions pays off in cost and efficiency.
Roughly 50-plus engineers is when a platform team starts to make sense
Not something to start at 10 engineers
Signal 1: same people on every team solving the same problems (inefficiency)
Signal 2: a core scaling or technical challenge needing a dedicated team
Best for matured companies where centralizing is worth the investment
“it tends to be like you have 50 plus Engineers I don't think this is the kind of thing that you start when you are…”
Stop Playing Telephone Between Engineers and Stakeholders
A third PM annoyance is becoming a middle person who relays technical questions they don't understand back and forth between askers and engineers. Camille says it wastes everyone's time and frustrates senior engineers. If it happens often, it's a sign to connect people directly rather than filtering everything through yourself.
Relaying questions you don't understand is a waste of time for everyone
It especially frustrates senior engineers on projects
'Let me get back to you' repeated often means you're losing something in translation
Frequent telephone-playing is a signal to connect people directly
“I think that is very annoying and frankly it's kind of a waste of time for everyone”
#product-management#communication#management
▲Takeaway10:00
The Best PMs Aren't Threatened by Other People's Ideas
Camille says the strongest product managers welcome ideas from a team full of smart engineers rather than feeling threatened by them. They also understand that engineers who think they could do the PM job usually don't grasp all the elements it takes. The best PMs build relationships so engineers feel heard while appreciating what the product role actually contributes.
Great PMs aren't threatened by smart engineers having ideas
Many engineers think they can be PMs but underestimate the job
Build relationships so engineers can share ideas and appreciate the PM role
Engineers accept that many ideas won't go anywhere if someone actually listens
“the product managers that have have done the best they're not threatened by other people having ideas”
#product-management#leadership#collaboration
▲Takeaway21:00
Get to Technical Mastery Before Moving Into Management
Camille advises staying hands-on technical until skill is 'in your bones' before making the leap to management, so it becomes a rusty-but-recoverable capability like a second language or instrument. In her estimate, real mastery took roughly ten years of intense study and full-time coding. Don't take the first management offer if you haven't put in that time, and don't rush if you still love writing code.
Stay hands-on until technical skill is 'in your bones'
Mastery becomes recoverable like a second language or instrument
Her own path suggests roughly the 10-year range of writing code
Especially important for women/underrepresented people whose skills get underestimated
Don't become a manager just because it's offered, or if you still enjoy coding
“one piece of advice I give everybody is don't stop being a Hands-On technical until you feel like it's in your bones”
“somewhere in the 10year range of like really having spent a lot of your time over those years in writing code”
#career#engineering-management#mastery
▲Takeaway27:00
Don't Chase Every New Framework
Riffing on indie hacker levels.io running everything on PHP and jQuery, Camille agrees that much of tech is over-engineered and that keeping up doesn't mean obsessively chasing every trend. The catch is scale: what makes one person productive won't necessarily make ten, a hundred, or a thousand people productive. Be aware of new tech without letting it dictate your stack.
So much of tech is over-engineering things
What works for a one-person show doesn't always work in a scaled organization
Keep up with what's changing, but don't obsessively chase every trend
Balance tech that makes one person fast vs. tech that makes many people fast
“so much of tech is over engineering things”
“what works as a oneperson show doesn't always work in a scaled Organization”
#engineering#over-engineering#tech-stack#scaling
▲Takeaway45:30
Work Fewer Hours, But With Real Focus
Camille argues that working long hours lets you sidestep the hard work of figuring out what actually matters. She believes in working hard in a focused way over fewer hours, backed by regular audits of your time to cut what doesn't matter. Forcing yourself to log off, and building heavy focus habits early in your career, is how she got to mastery.
Long hours let you avoid figuring out what's actually important
Regularly audit your time and cut things that don't matter
Focused work over fewer hours is more productive
Force yourself to log off to create real boundaries
Heavy focus early in her career was a key reason she reached mastery
“older work kind of lets you just sidestep doing the hard work of figuring out what's important in the first place”
“working hard in a focused way for Le but over fewer hours I think is a more productive way to approach work”