Brandon from Flightcontrol writes an in-depth exploration of strategies for handling data in software systems that serve multiple clients or 'tenants'.

It emphasizes the importance of incorporating 'teams' functionality from the outset to avoid future complexities. The guide discusses various models for organizing data, including single versus multiple databases, and provides insights on implementing robust access controls, handling user sessions effectively, and ensuring data isolation across different tenants.

It also compares different access models from companies like the GitHub, Google or Linear.

A classic internet story where a university's statistics department could not send emails beyond 500 miles.

Full story in the link below:

Bret Victor takes you to 1973 to deliver a presentation on an overhead projector about the future of programming. He shows the latest innovations from the 60's and 70's and how they will change the future of computing.

'The most dangerous thought that you can have as a creative person is to think that you know what you're doing, because once you think you know what you're doing you stop looking around for other ways of doing things and you stop being able to see other ways of doing things. You become blind. I think you have to say: "We don't know what programming is. We don't know what computing is. We don't even know what a computer is." And once you truly understand that, and once you truly believe that, then you're free, and you can think anything.'

A beautiful presentation about innovation.

Dan Abramov's talk, "The Wet Codebase," discusses the challenges and lessons learned from creating abstractions in coding.

He narrates a scenario where attempts to follow DRY (Don't Repeat Yourself) principles led to overly complex and less maintainable code due to forced abstractions and unintended coupling. Dan emphasizes the importance of considering the trade-offs of abstractions, like accidental coupling and the difficulty in removing entrenched abstractions.

Also has good advices over testing concrete code and resisting premature abstractions, suggesting that sometimes duplication is preferable to the wrong abstraction.

PD: For the past years, this has been my go-to talk to share with people that might be too strict with DRY!

Félix López shares how they defined and created their on-call process and their core principles.

Frequently on-call implementations are a controversial topic due to the fact that you might be asking people to work on weekends, Tinybird seems to have created a sustainable process to make it as less painful as possible.

The On-call process is a touchy subject for a SaaS company. On the one hand, you must have it, because your prod server always seems to go down at 2 a.m. on a Saturday. On the other hand, it places a heavy burden on those who must be on call, especially at a small company likeTinybird, where I currently head the engineering team.

I have actively participated in creating the on-call process in three different companies. Two of them worked very well, while the other didn’t. Here, I’m sharing what I’ve learned about making on call successful.

Great talk from Sam Newman explaining with examples how to implement trunk-based development, continuous delivery and how feature branches help to implement these practices in a "post-GitHub" world.

Talk Abstract:

During the evolution of the ideas behind Continuous Delivery, many of us came to the conclusion that having branches for features was not a good idea, and resulted in some fairly problematic issues.

This was contentious at the time, with lots of discussion around whether or not feature toggles or feature branching was the right way forward. Roll on several years, and through Git and GitHub, branches are everywhere. Is this a problem?

This talk re-examines the role of feature branches and feature toggles, and looks at them in the context of new research and technology to try and distill down some sensible lessons in a post-GitHub, but hopefully not post-factual, world.

The article describes key practices that distinguish highly effective engineers.

These habits include writing clear, simple code that serves both humans and machines, adhering to consistent coding standards, and embracing testing to avoid surprises in software functionality. I

It emphasizes the importance of collaboration, iterative improvement, and a focus on end-user problems.