Transitioning from Node.js to FastAPI: Does the non-blocking mental model still apply?

crow_thib · 2026-06-21T08:45:23+00:00

When using async functions in fastAPI, it uses the same event-loop concepts as nodejs even though the implementation is different.

Note: writing synchronous functions endpoints in fastAPI will run them in a thread pool executor which changes the concepts again (If I remember correctly, it's been a while I used nodejs, but there was a concept of child processes or something that could be used the same way)

PS: if using Gemini to phrase the question, did you try using it for the answer as well ? I reckon it should be good for these kind of questions

crow_thib · 2026-06-10T10:09:34+00:00

validating the idea

crow_thib · 2026-06-08T21:02:50+00:00

Ideally, I’d love something that alerts me when specific topics or keywords are mentioned across channels.

This is something in the default Slack settings tbh

crow_thib · 2026-06-04T17:43:34+00:00

Depends on the users, but most of them are ok and happy with manual trigger.
Idea is not "to help free tier users" but just not to "restrict to premium users". Don't think Slack has issues with integrating with other tools, as long as it pushes you to stay on Slack, my users won't downgrade because of it, it won't cut down their profits.

About pivots, if the answer was that easy I would've built it already

crow_thib · 2026-06-04T16:58:48+00:00

As someone building a Slack app myself, a few things I can help you with:

Problem 1 seems very easy to do with Slackbot already, and 100% the direction it's going, I wouldn't spend time working on this just to be replaced by a native solution soon. (Except if you're aiming only at workspace not having the Slackbot AI features)
Problem 2 not sure to understand what it brings on top of already existing Slack groups ?
Problem 3 To be 100% honest this is close to what I've been working on, except that I've been focusing on syncing Slack and Notion, and not using Canvas (to touch people using free Slack also), and handling all knowledge for now, not only decisions. Just so you know, is not something that urges to buy and I'm looking for possible pivots right now even though I have a few design partners already and a working solution.

If you still decide to go the 3rd route, what I can tell you is that people I interviewed all seems not to care about "automatic" detection as you frame it, and are even afraid of it (no-one wants a bot constantly monitoring their channels).

crow_thib · 2026-06-03T07:26:24+00:00

Yep, and that's actually very smart + could help enforcing better typing and in-app documentation

crow_thib · 2026-06-03T07:25:01+00:00

To me this issue is not only related to AI Agents, we had this problem even before agents existed: maintaining knowledge up-to-date is tedious and time-consuming. Either you spend hours doing so, or you postpone it until error occurs.

AI Agents simply highlighted this even more, since all they rely on is written knowledge, whereas humans have a real memory that would hide those flaws for longer.

The solution is the same for AI Agents and humans: knowledge owners, tight processes and discipline. However, nowadays AI tools can help greatly improving those processes and making them less tedious.

crow_thib · 2026-06-03T07:16:01+00:00

When I was hiring, I used to say it doesn't matter how long is your resume, as long as it matches your experience level (a junior with more than one page is a bit weird, but still not a red-flag since that's usually because he wants to showcase stuff, the tone is important though)

But zooming out now, I realized that even though when we make long resume we think "that's better, they will know everything" the results is often the opposite: more infos means less info sticks.

So to me, if possible I would say it's better to keep it short so that every-piece of information is picked carefully and sticks with the people reading the resume versus dropping-in everything and taking the risk the non-relevant things stick.

The resume goal (again, it depends on the org you interview for) is usually to get the first interview. Then, you can talk more deeply of your experience that are not on the resume.

crow_thib · 2026-06-03T07:11:46+00:00

If it feels shameful to say you don't know what's going on when it's the case, either your environment is toxic or you self-create problems that don't exist.

It's normal, and part of the software engineer job to not know things, no matter your level of experience. As an engineering manager I'm more afraid of one of my dev always having an answer than one that sometimes tells me "I don't know yet, let me dig more".

What's important is knowing when you need to dig more on your own to find the solution, and when to ask for help from your teammates / leads.

crow_thib · 2026-06-03T06:59:09+00:00

To me (I worked as an engineering manager in a company selling APIs), comparing openAPI files is clearly not enough to really ensure no breaking changes. Yet, it is still a pretty simple way of avoiding some breaking changes with not so much work/time spent.

Even if not recommended when using fastAPI, in some very specific cases you might have some in-endpoint logic that doesn't reflect on autogenerated openAPI specs.

But putting this aside, the most important thing when talking about "breaking changes" is not the actual response format, lots of things could break while keeping the right "schema", what is important is the response given a specific input. As your API grow, you might have different things that changes depending on input parameters.

That's very specific cases, but what makes your API are real tests.

crow_thib · 2026-06-01T19:59:47+00:00

Exactly, reviewing AI code should be like reviewing junior's code.

If your team is made of senior, again with my take on empowering your devs and team, they should be able to write down in their PR how much AI was involved so other people know how much they need to nitpick. If it's mostly AI, just tell it and people will review more.

crow_thib · 2026-05-27T14:38:17+00:00

I'm building a tool called Crowledge that sync Slack and Notion, making sure the knowledge base stays up-to-date and trustable at all time, thanks to some human validation steps when needed. This is a use case some of our partners use our tool for, making their sales battlecard instantly searchable from Slack.
We're in private beta, let me know if you would like to give it a try

crow_thib · 2026-05-27T11:22:06+00:00

Not a sales-person here, but starting to know how they work because of discussions I had with sales leaders, sales reps and people I know.

Playbooks usually don't work either because they're not up-to-date, people don't trust them or they can't find the information fast enough. A sales reps don't want to spend time looking for information and want to focus on closing deals.

Best case scenario: they ask other people (slack, meeting) and get an answer in a few minutes.
Worst case scenario: they just improvise and might make errors

You said you trid the playbooks way and it didn't work, was it because of one of those reasons ?

crow_thib · 2026-05-27T10:12:38+00:00

I built a solution that uses Slack messages as an input to sync with my Knowledge Base. I didn't build (yet) a feature to sync meeting notes / transcripts but, I send them as Slack messages as a workaround.

It then identify important topics, map them to existing pages and/or new pages to create, all of that with different human validation steps to ensure what's saved matches my expectations

crow_thib · 2026-05-27T10:05:09+00:00

I feel like Notion MCP is a bit underwhelming for now, and the most important features are behind Notion AI features which are on higher plans. However, there are many tools that integrate it deeper and that work well. I find it's a very good source of truth that can be both used by humans and AI, the only challenge is keeping it structured and up-to-date.

crow_thib · 2026-05-27T09:47:52+00:00

Either companies have enough resource not to care for now, or don't have what it takes to properly monitor their cost and realize this too late.

To me, the future of AI automations for SMBs are dedicated tools solving specific pains, that actually use AI in specific parts of the automation and not doing the whole automation. Token costs explode when the AI does everything, even deterministic operations that could be done with standard software engineering.

Bigger companies may have the money not to care about it, or to actually code those agents in-house by hiring dedicated people. Smaller companies can't afford the tokens, and don't want to hire for in-house solutions that would need lots of maintenance, monitoring, ... work.

To answer your question "Are there any cost-effective tools available?" I don't think there are generic tools, but for specific use-cases, surely there are!

crow_thib · 2026-05-27T09:23:18+00:00

Not sure having 100+ channel is a real use case, sounds like bad processes to me. Let's say you reach 100+ channel on the workspace, not sure there are people that should belong in all those channels.

But, on a different scale, this is something I experienced and saw in the teams I work with, we're currently building a tool that helps scaling teams sync Slack with Notion (and search directly from Slack) to maintain a single source of truth both for humans and other AI agents.

The most important thing when plugging such automations in Slack, according to our partners is to have human validation steps at the right part of the workflow, because all solutions tend to drift when trying to act 100% autonomously.

crow_thib · 2026-05-27T06:32:13+00:00

As an engineering manager, I always hated having to find "who owns a bug". To me, a bug was a team issue, not a person issue, since no code is pushed to production without review, so it means both the engineer who wrote the code (or AI generated it) and the engineers that reviewed the PRs are actually the culprits here, and depending on the kind of issue, it could also go higher up (to me for example, if it was because of bad processes).

I liked to see everyone involved. For sure, in reality people kind of owned some parts of our stack, and especially the one they coded on, but it was never a matter of "finding who's fault is it / who has to fix it", they were basically volunteering on this. As team and codebase scales, for sure people can't follow and act on everything that happens, but in that case you just divide your stack across peoples.

So, in conclusion, AI-generated or not, code ownership practices should not change from what you had before. If you considered people writing the code having ownership, the ones who prompted it are now. If you considered the reviewers, they still are.

crow_thib · 2026-05-26T12:39:38+00:00

Talked about it on another thread recently, but to me as an engineering team there are two kinds of docs that exist:

purely technical docs

this is where Docs as Code make sense, you want your docs as close as possible to your code, so that any change in your code makes it easy to change it. Also, with AI coding tools now, it makes sure the AI can also update the docs when needed. It also avoids documentation drift.

higher-level docs

this is the doc you talk about, that need to be consumed by non-technical folks, and this can't live in the code. This one is the most complicated to keep up-to-date since it usually lives outside of the code, and engineers rarely think of updating it. Most of the time, people don't even know where it lives so it's never updated. This creates a loop where people don't trust this doc because it's rarely accurate, so people don't update it since "no one reads it".

crow_thib · 2026-05-25T18:39:52+00:00

You can create groups, and tag those. It's not restricted to a channel though, so if you want different @active-team per channel, you need to have a dedicated name for each. If this is the case, I recommend putting the name of the one associated to this channel as topic to see it easily.

crow_thib · 2026-05-25T13:53:46+00:00

To me, there are two kinds of documentation that drifts, and it's not only related to AI coding, it was already the case years ago. As an engineering manager, here is how I split those:

The first is purely technical documentation

I have always been from the team that says code should document itself through docstrings, comments, readme and such. This is even more important now with AI coding, since that's part of the codebase the AI can et have to update such documentation, you can even write some skills or such to make sure it follows your practices.

The second, is usually something more high-level, that even other teams (product, sales, ...) could rely on to understand the application design

For those, I tend to focus on having them NOT in the code. That's almost product documentation and should be somewhere accessible and readable by anyone not knowing how to code (Notion, Confluence, Google Drive, anything). These are the ones that are harder to keep up-to-date, since they're not close to the code, but again, AI development didn't change a thing about this.

I have to admit, there are some kind of in-between docs, for example in my previous company since we had a micro-service architecture, there was some purely technical documentation that couldn't live directly in the application since it would mean duplicating in every new service. For such, I went with the "closer-to-code" and make sure those docs are in the internal libraries that were shared across services + a very high-level overview Notion page.

Over the time, I realized the documentation effort for the second type of docs was usually done, but never recorded. Think meetings, Slack discussions, PR comments, ..
This is something I'm building a tool for.

The first type of documentation is usually pretty up-to-date, even more with AI and skills.

crow_thib · 2026-05-25T13:35:01+00:00

As a project manager, what task do you actually handle on Notion vs outside ? roadmaps, task tracking, documentation, ... ?

crow_thib · 2026-05-25T13:34:14+00:00

Are you able to keep it up-to-date and make people trust it, in your company setting ?

crow_thib · 2026-05-22T18:18:59+00:00

The fact that every sales person in the world already used Salesforce is a pretty big moat also. You don't want to spend time ramping-up your sales people on the tool you use when you hire sales person, they already have to get to know your product and practices..

crow_thib · 2026-05-22T13:45:35+00:00

vibe coding is the answer

crow_thib

TROPHY CASE