On another read-it-later service
That in which I talk about why did I build another read-it-later application and why it matters. I talk about what problems did I try to solve and what was important to me.
This is where I write about the things I know most about: Code, Coffee and Music.
That in which I talk about why did I build another read-it-later application and why it matters. I talk about what problems did I try to solve and what was important to me.
That in which we discuss how to talk about our tools and how does AI fit into it.
That in which I talk about why "insights" are overestimated. Execution and needs are more valuable and less talked about
That in which I talk about how engineering was not the real product bottleneck and how the current LLM’s are making this obvious right now.
That in which I go over how to build a simple but effective feature flag system.
The one in which I talk about my rules of thumb when starting on a new team. How to disrupt as little as possible and be as useful as possible. How to affect change and most importantly, when.
The one in which I talk about implementing ELO scores and fixing bugs
The one in which I duscuss building versus buying and why/how I decided to build a simple queuing system at work.
The one in which I share our experience on going through the SOC-2 type 2 audit
The one in which I duscuss git worktrees and how they can help you work on multiple branches at the same time.
That in which I talk about maintenance, mobile layouts, audio generation, etc.
That in which I talk about onboarding flows, multi-language support and first users.
That in which we talk about the latest updates in working on the vocabulary builder
That in which I give an update on the progress so far to catch up with my lack of updates
The one in which we go through the differences between a final product and an evoulutionary product. How to think about them, what to expect and how to handle evolutionary products properly.
The one in which I talk about layering as a philosophy for product development.
The one in which we talk about what really makes a product when compared to simply a collection of features.
That in which I talk about the idea for FalaGym and the direction I intend to take with it
That in which I talk about my current principles for maintaining a healthy backlog when working on a team and moving fast.
That in which I discuss when it pays to be efficient and when, maybe, you should forget about it.
The one in which we try to understand the real difference between a fact and an opinion and, after that, try to determine when shoul you value facts more and when should opinions have a higher value.
The one in which we talk about the differences between when you are building something compared to when you are crafting something.
The one in which I talk about understanding the problem before trying to solve it.
The one where I talk about limiting the scope and polishing the experience when starting something
Reflections on things I wish I had known when I was at the start my career and that I wish I have shared with people around me struggling with their first jobs, first managers and first disappointments.
Some reflections on how it feels to turn 34 years old.
You must use AI when coding. However the way you leverage the assistance will have a dramatic impact on your future as a developer in small and big ways. It pays to be mindful of it.
Keeping notes on what you are working on during the day has some surprising benefits and helps the brain to travel light.
Justifying your failure is the most efficient way to make sure that you don't learn from it. And yet, this is the default response for most of us...
MVP should not be shitty. The meaning of minimal should mostly refer to the scope that is covered in the initial implementation. Let's break this down.
Becoming more productive is one of the rare things in life that is absolutely good. No matter how you spin it, everything else being equal, it is better to be more productive then less. So here are a few thoughts on how to become more productive.
When people around me are talking about shows and getting excited about it, I don't really feel like I am missing out. I often quench my curiosity by asking questions around the show and what makes it a good one and in most cases that is enough.
With the new year starting it is time to take account of the past year, learn from it and see what I can adjust to make the new year even better.
This time I will talk about how and why I decided to change my keyboard layout from QWERTY to Colemak and why you should too.
Let's look at how to (properly) handle the safe area in react native, beyond the simple strategy of slapping a safe area view everywhere.
Sometimes we would like to combine to types into a complete new type. Typescript offers a simple way to do that through intersection types. See how.
There is a common parttern of using useState with an object as its contents. In this article I show (and make a reminder for myself) how to have an object as your state and how to update each part of it individually whenever you need to.
There are many ways to handle authentication when you are building your GraphQL api. Here I describe my current and preferred approach for tackling this while keeping it as simple as possible.
Teams deal with technical debt differently. Sometimes they don't touch until it breaks, some others they activelly manage it. How do you do it?
The impostor syndrome is real and presents itself in many ways. We need to talk about it. We also need to find ways to avoid that it leads us into self-sabotaging and missing oportunities. Here's my rant on it.
After having struggled for a while to make full use of Typescript, ESLint and Prettier with Next.js I finally managed to get it all working and decided to write it up for myself and whoever else finds it useful.
Time to look back at 2021 and reflect on the things I did well, what could have been done better, good times and what to aim for in the year that has started.
You cannot be creative. Creativity only exists as a verb. You can do creative instead.
A simple collection of tips and flows that I use every single day in git and github for work, pleasure and profit.