The name of the function, what goes in and what goes out in most cases should be enough to get a good idea on what the function does.

It also helps to make a diagram of how everything ties together. Just boxes and arrows is enough.

When writing your own code, it takes a bit of experience to know when to put something in its own function. It’s very obvious when you’re replicating code. It’s also very common to cut things up when a function gets too big. Look for bits of functionality that you can give a good name.

I can strongly recommend the SponsorBlock extention (also available in revanched).

I always write it as a select, before turning it into a delete or update. I have burned myself too often already.

With Influx 3 the preferred language is gonna be their SQL dialect. Flux is on its way out and I suspect it will get deprecated in the near future. Flux saw very slow adoption and SQL can do everything as well.

The one that blew my mind is that plate tectonics is only a widely accepted theory since the 70s.

They’re nice if they also migrate your db schema. That way you define your schema once and use it both to setup your db and interact with it via code. I do write raw sql for more complex queries, e.g. when there’s recursion.

I was big into downloading before streaming services were a thing. Music streaming is one of the few services that’s totally worth my money: no hassle and I rarely have to resort to other platforms to find what I want (very different from video streaming, which totally sucks when it comes to that).

Netherlands too. Amsterdam is even planning to change major inner city roads to 30km/h (minor roads already are).

It’s bought by Avast. I immediately uninstalled it when I learned about the news. No way that they don’t want get a return on investment by e.g. selling your data.

Consent-o-matic is better (actually sets the minimum amount of cookies) and is developed by university employees, whom I trust more.

Oh, it should absolutely be the team’s decision and you’re also totally right that Kanban requires a more mature team. People indeed need to be able to recognise and ask for help when they’re stuck (which means being vulnerable, but also simply being able to formulate the right questions). People also need to be able to give feedback to their team members when they feel or see that someone is struggling or not delivering enough.

To facilitate I always have some form of retrospective in my teams, even when doing Kanban. Sometimes only once every other month, sometimes every two weeks. Highly depends on the maturity of the team and customer.

I work in a company where we say that everyone is an expert (and to a very large extent this is really true). We create teams of experts, including more business savvy people. Everyone respects each others expertise and makes sure they can apply it as best as possible. We don’t infringe upon each other’s expertise. We might ask another expert about the why or the how, but we should not assume we know better. Obviously this happens sometimes, but then we remind each other that we’re all experts and that an engineer wouldn’t like to be told by marketing how to do their job either.

I think this fits nicely with ‘stay in your lane’ and actually makes it easy to remind people to do so. It’s in the core values of the company that people excel in their lane and cooperate with people in other lanes.

I would even argue that points, stories and sprints are not things you need. If you go kanban, you don’t need sprints. You still need to be producing and you probably want to get a feel for complexity so you can prioritize, but that can be done without points.

Stories are also very scrum specific and you can turn them into whatever format you want. I usually still call them stories, but they’re basically just a little card that describes the context (why do want something) and the deliverables (what will be implemented to meet that want).

I like the concept of reducing cognitive load for the stream-aligned teams. This means all efforts go towards enabling them as much as possible in supporting the business. It also makes it relatively easy to judge if a platform team is doing the right things.

I started a little over half a year ago with Go, coming from Python like the author. I definitely enjoy working in a strongly typed language and Go is usually quite fun to work with. This week I’m actually implementing a concurrency pattern for a ‘real’ problem, so eager to see how that works irl. I’ve yet to come across something where generics really make sense, but definitely curious to explore that with a real case as well.