• 4 Posts
Joined 1 year ago
Cake day: July 2nd, 2023


  • Do you know what pattern matching is great for? Finding commonly cited patterns in long debug log messages. LLMs are great for brainstorming problem solving. They’re basically word granularity search engines, so they’re great for looking things up are more niche knowledge that document search engines fail on. If the thing you’re trying to look up doesn’t exist, it will make shit up so you need to cross reference everything, but it’s still incredibly helpful. Pattern matching is also great for boilerplate. I use the codium extension and it comes up with auto complete suggestions that don’t have much logic, but save a good amount of key strokes.

    I didn’t think the foundational tech of LLMs are going to get substantially better, but we will develop programming patterns that make them more robust and reliable.

  • It can potentially allow 1 worker to do the job of 10. For 9 of those workers, they have been replaced. I don’t think they will care that much for the nuance that they technically weren’t replaced by AI, but by 1 co-worker who is using AI to be more efficient.

    That doesn’t necessarily mean that we won’t have enough jobs any more, because when in human history have we ever become more efficient and said “ok, good enough, let’s just coast now”? We will just increase the ambition and scope of what we will build, which will require more workers working more efficiently.

    But that still really sucks because it’s not going to be the same exact jobs and it will require re-training. These disruptions are becoming more frequent in human history and it is exhausting.

    We still need to spread these gains so we can all do less and also help those whose lives have been disrupted. Unfortunately that doesn’t come for free. When workers got the 40 hour work week it was taken by force.

  • They add a lot of overhead and require extra tooling to stay up to date in a maintainable way. At a certain scale that overhead becomes worth it, but it takes a long time to reach that scale. Lots of new companies will debate which architecture to adopt to start a project, but if you’re starting a brand new project it’s probably too early to benefit from the extra overhead of micro architectures.

    Of course there are pros and cons to everything, don’t rely on memes for making architecture decisions.

  • It’s just not worth it until your monolith reaches a certain size and complexity. Micro services always require more maintenance, devops, tooling, artifact registries, version syncing, etc. Monoliths eventually reach a point where they are so complicated that it becomes worth it to split it up and are worth the extra overhead of micro services, but that takes a while to get there, and a company will be pretty successful by the time they reach that scale.

    The main reason monoliths get a bad rap is because a lot of those projects are just poorly structured and designed. Following the micro service pattern doesn’t guarantee a cleaner project across the entire stack and IMO a poorly designed micro service architecture is harder to maintain than a poorly designed monolith because you have wildly out of sync projects that are all implemented slightly differently making bugs harder to find and fix and deployments harder to coordinate.