José Postiga

Rought week, huh?... First Clerk, now Cloudflare...

Outsourcing is a great way to scale, but it isn't a "get out of jail free" card for system design. Build like you don't trust anyone—because, eventually, every API returns a 5xx.

"It's not our fault, it's [SaaS Provider X]" is a valid explanation, but it’s a terrible customer experience. To the person paying the bill, a failure in your supply chain is a failure of your product.

I've talked about this in the past, but doesn't hurt to say it again: when a system fails, your paying customers aren't going to check your status page to see which sub-processor is at fault. They are going to look at you.

If your auth provider goes down, your users can't log in. If your payment gateway glitches, your revenue stops. If your headless CMS hangs, your storefront looks broken.

In a world of "Everything as a Service," our tech stacks are often just a collection of APIs held together by hope. Even if your own infrastructure is bulletproof and your code is pristine, you are only as reliable as your weakest third-party dependency.

Receiving spam/phishing attempts trying to impersonate
Disney+ from an email account of a Brazilian banking system is something I never expected to happen...

Is Facebook dead? I can't even justify holding an account there, anymore...

It's working Vodafone!

How dificult should be the process of updating an email account? My bank seems to not be able to send a confirmation email to verify the new email I want to use is valid... I'm losing my mind...

Ok, I'm probably stupid, but am unable to comment on a comment, in @notion.com , when the thread is resolved... What the hell?...

The perception of fault is a reality of ownership. We take the heat so the customer doesn't have to navigate the complexity of the supply chain.

But to the customer? That sounds like an excuse. If they pay us, the "whole product" experience is on us. If a vendor breaks, it means our resilience strategy failed, or our vendor selection process needs review.

Nothing is more frustrating for an engineering team than dropping everything to patch a bug caused by an upstream vendor. It feels like cleaning up a mess you didn't make. It’s even worse when shared customers are affected. It is incredibly tempting to say, "It’s not us, it’s [Vendor Name]."

Customers don't care about your dependency tree.

There is a hard truth in SaaS: You can outsource your infrastructure, your payments, and your CRM, but you cannot outsource your responsibility.

So it's extremely evident to me that AI models, and their owners, need to at least make ways for authors to have a little more control or take crediting way more seriously!

At the very least, to be known... This throwing us back 30+ years, where if we wanted knowledge we would have to buy books. And this would starve the models of training data, eventually, which would also make them less interesting.

I'm very concerned that this can push such businesses or individual maintainers to close access to, for example, documentation (at least anything beyond the basics of what it is and how to install it) in favor of taking back control and to have new ways to publicize other work and direct attention.

This will cause, and has caused already, businesses to lose revenue. Worst, or equally worst, is that open core businesses (to speak in a topic closer to my heart as an engineer) that depend on such revenue to fund constant work on their open source projects that everybody else can freely use.

This also added a possibility for them to upsell or direct our attention to other things. Now, in the age of AI, it's no more "X person has this awesome article about the problem and how to solve them" and more "X model can fix or teach about that". No author, no references, nothing... It's brutal!

The Internet used to be a place where we easily had access to "free" knowledge. It was an open digital world. As we scrolled and ingested such content, there was opportunity to learn about the authors and distributors of such knowledge.

I honestly can't make changes to GitHub's actions' yaml files without Claude Code's assistance... 🤡

"Tell me who you are without telling me what you do professionally." - What a powerful question... Answer this yourself, and see how it eventually shapes the environment you'll set yourself in, in this new year.

I just deactivated the auto-renewal of several of domains I registered for side projects. Accepted the idea those will never see the light of day. It's liberating...

"As software gets older, it gets bigger. As it gets bigger, it gets worst." - @t3.gg
So much truth in such simple phrase. As projects evolve, and as feature appetite grows, so does teams. And with that comes a lot of organizational problems. People forget to refactor and evolve.

Having technical documentation in a different repository than where the code is, is a recipe for disaster. The docs and the code will evolve in different paces. There's a reason why we put tests alongside code, and the same should apply to your docs!

"Don't just color the picture." - A powerfull message in such a simple sentence.

Credits to Jeffrey Way. Heard it on a Laracasts podcast episode "This is Why You Can't Get a Programming Job".

I found that the best motivator to get shit done and succeed professionaly, for me, is having a family that's dependent on you to just do whatever you have to do to thrive.
In terms of dopamine injection, nothing beats ensuring I take care of my family.

Somebody at @jetbrains.com is having a nice start of the week. To whomever is solving this: Don't worry, I also caused a small hiccup on our production environment, too, and on Sunday, of all the days!...

Raise your hand if you're the author of some prod disruption in the past week.

Reminder that using a service-oriented architecture where all services access the same database engine/instance is not how you create a high-availability system...