Posts tagged "Hot Takes"

Your Daily Standup Should Be a Slack Message

It’s 9am. You’ve just made your coffee. You’re ready to be productive. Then your calendar reminds you that you have standup in five minutes. You sigh, open the video call, and wait for everyone to trickle in over the next seven minutes while Dave figures out why his microphone isn’t working again. Finally, the ritual begins. Sarah goes first. “Yesterday I worked on the API stuff, today I’m continuing with the API stuff, no blockers.” Fantastic. Groundbreaking information. Absolutely could not have been a single line of text.

Crypto Solved No Problems That Regular People Actually Have

Crypto has been around for over fifteen years now. Bitcoin launched in 2009. Ethereum in 2015. We have had a decade and a half of innovation, billions of dollars of investment, countless startups, multiple boom and bust cycles, and a generation of developers working on blockchain technology. Name one problem crypto solved for regular people. Not hypothetical problems. Not problems that might exist in authoritarian regimes. Not problems that only crypto people have because they got into crypto. Real problems. The kind normal people experience and would pay to fix.

Reply All Should Require a CAPTCHA

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.

Most Meetings Could Be an Email, Most Emails Could Be a Slack, Most Slacks Could Be Nothing

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 Are Hazing Rituals We Keep Because We Survived Them

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 Where Productivity Goes to Die

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.

Docker Compose Is All You Need and Kubernetes People Are in Denial

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.

I Am Glad GraphQL Is Dead, What a Fucking Mistake That Was

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 for 90% of Teams Who Adopted Them

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.

If Your API Needs a 40-Page Docs Site, Your API Is Bad

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.