Every email client on earth has made it trivially easy to commit one of the most devastating acts of workplace communication: the unnecessary reply all.
One click. That is all it takes. One click and suddenly forty-seven people who did not need to be involved are involved. One click and an email thread that could have died quietly explodes into a cascade of responses, counter-responses, and people asking to be removed from the thread, which of course they send as a reply all.
You have a meeting on your calendar. It is thirty minutes long. There are six people invited. The topic is something that could be summarised in two sentences. By the time everyone joins, exchanges pleasantries, gets distracted, and finally discusses the actual subject, you have burned three person-hours of collective time.
That meeting should have been an email.
But wait. You sent an email. It was three paragraphs explaining a decision. Nobody needed to respond. Nobody needed to discuss. You just needed people to know something. Now six people have another email in their inbox, another thing to read, another context switch in their day.
Technical interviews do not predict job performance. We have known this for years. Study after study shows that whiteboard coding, algorithm puzzles, and system design interrogations have almost no correlation with how well someone actually does the job.
We keep doing them anyway. Why?
Because we went through them. We suffered. We ground LeetCode for months. We memorised sorting algorithms we have never used professionally. We practiced answering questions about designing Twitter’s backend despite never working at that scale. We did the hazing, and now it is our turn to haze.
Notion is not a productivity tool. Notion is a tool for feeling productive while accomplishing nothing. It is a creativity sink disguised as a workspace. It is where work goes to become content about work.
I have watched people spend more time building their Notion setup than actually doing the tasks the setup was meant to track. I have done it myself. This is not productivity. This is procrastination with better aesthetics.
I am going to say something that will upset a lot of people who have invested significant portions of their careers into container orchestration: Docker Compose is probably all you need.
Not Kubernetes. Not ECS. Not Nomad. Not whatever managed container platform your cloud provider is pushing this quarter. Docker Compose. The thing you used in tutorials before graduating to real infrastructure. That thing. It is enough.
Kubernetes is incredible technology you do not need Kubernetes can do amazing things. It can manage thousands of containers across hundreds of nodes. It can self-heal, auto-scale, handle rolling deployments, manage secrets, configure networking, and orchestrate workloads across multiple data centres. It is genuinely impressive engineering.
GraphQL is dying and I could not be happier. The hype has faded. The conference talks have dried up. The true believers have gone quiet. Teams are quietly migrating back to REST and pretending they never suggested GraphQL in the first place. The fever has broken.
Good. It was a fucking mistake.
The problem it solved did not exist GraphQL was supposed to solve over-fetching. Your REST API returns too much data, they said. You are wasting bandwidth, they said. The mobile clients only need three fields but you are sending back fifty.
Microservices were a mistake. Not the concept itself, which has legitimate uses at genuine scale. The mistake was convincing an entire generation of developers that their CRUD app needed to be split into 47 independently deployable services communicating over a message bus designed by someone who watched one too many conference talks.
I said what I said. Come at me.
Netflix ruined everything This is Netflix’s fault. Not intentionally. They shared how they solved their genuinely massive scale problems, and the rest of the industry collectively lost its mind.
I should not need to read a novel to call your endpoint.
If your API documentation spans forty pages, multiple guides, a getting started tutorial, a concepts section, a best practices section, and a troubleshooting FAQ, your API is not well documented. Your API is badly designed. The documentation is compensating for failures that should have been fixed in the API itself.
Good APIs are self-evident. You look at the endpoint, you understand what it does. You look at the request, you understand what to send. You look at the response, you understand what you got back. The documentation exists to confirm what you already intuited, not to explain an incomprehensible system.
Imposter syndrome is real. Plenty of people, especially those from underrepresented backgrounds, genuinely struggle with feeling like they do not belong despite evidence to the contrary. That is a real thing that affects real people and deserves real support.
But somewhere along the way, the discourse around imposter syndrome went completely off the rails. It became a content genre. A personality trait. A thing people perform on LinkedIn for engagement. And I think it is doing more harm than good at this point.
You are a startup. You have twelve users, three of whom are your mum, your co-founder, and your co-founder’s mum. You have six months of runway. You have not found product-market fit. You are still pivoting weekly based on whatever feedback you got from the last person who agreed to a demo.
And you want to build a mobile app.
No. Stop. Put the Xcode down and step away from the keyboard.