Readit NewsI 100% agree with you but also sad fact is that it’s easy to understand why people don’t want to take this role. You can make enemies easily, you need to deliver “bad news” and convince people to put more effort or prove that effort they did was not enough. Why bother when you probably won’t be the one that have to clean it up
> You can make enemies easily...
Reading it with hindsight, their problems have less to do with the technical trade off of micro or monolith services and much more to do with the quality and organizational structure of their engineering department. The decisions and reasons given shine a light on the quality. The repository and test layout shine a light on the structure.
Given the quality and the structure neither approach really matters much. The root problems are elsewhere.
My observation is that many teams lack strong "technical discipline"; someone that says "no, don't do that", makes the case, and takes a stand. It's easy to let the complexity genie out of the bottle if the team doesn't have someone like this with enough clout/authority to actually make the team pause.
It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads.
Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.
It's kinda nice.
Main downside is the hot reload is not nearly as nice as TS.
But the coding experience with a C# BE/stack is really nice for admin/internal tools.
CharlieDigital commented on IBM to acquire Confluent confluent.io/blog/ibm-to-... · Posted by u/abd12
Kafka is really not intended to improve on this. Instead, it's intended for very high-volume ETL processing, where a classical message queue delivering records would spend too much time on locking. Kafka is hot-rodding the message queue design and removing guard rails to get more messages thru faster.
Generally I say, "Message queues are for tasks, Kafka is for data." But in the latter case, if your data volume is not huge, a message queue for async ETL will do just fine and give better guarantees as FIFO goes.
In essence, Kafka is a very specialized version of much more general-purpose message queues, which should be your default starting point. It's similar to replacing a SQL RDBMS with some kind of special NoSQL system - if you need it, okay, but otherwise the general-purpose default is usually the better option.
Of course this is not the same as Kafka, but the comment I'm replying to:
> Ah yes, and every consumer should just do this in a while (true) loop as producers write to it. Very efficient and simple with no possibility of lock contention or hot spots. Genius, really.
CharlieDigital commented on IBM to acquire Confluent confluent.io/blog/ibm-to-... · Posted by u/abd12
Ah yes, and every consumer should just do this in a while (true) loop as producers write to it. Very efficient and simple with no possibility of lock contention or hot spots. Genius, really.
I've implemented a distributed worker system on top of this paradigm.
I used ZMQ to connect nodes and the worker nodes would connect to an indexer/coordinator node that effectively did a `SELECT FROM ORDER BY ASC`.
It's easier than you may think and the bits here ended up with probably < 1000 SLOC all told.
- Coordinator node ingests from a SQL table
- There is a discriminator key for each row in the table for ordering by stacking into an in-memory list-of-lists
- Worker nodes are started with _n_ threads
- Each thread sends a "ready" message to the coordinator and coordinator replies with a "work" message
- On each cycle, the coordinator advances the pointer on the list, locks the list, and marks the first item in the child list as "pending"
- When worker thread finishes, it sends a "completed" message to the coordinator and coordinator replies with another "work" message
- Coordinator unlocks the list the work item originated from and dequeues the finished item.
- When it reaches the end of the list, it cycles to the beginning of the list and starts over, skipping over any child lists marked as locked (has a pending work item)
Dead simple design, extremely robust, very high throughput, very easy to scale workers both horizontally (more nodes) and vertically (more threads). ZMQ made it easy to connect the remote threads to the centralized coordinator. It was effectively "self balancing" because the workers would only re-queue their thread once it finished work. Very easy to manage, but did not have hot failovers since we kept the materialized, "2D" work queue in memory. Though very rarely did we have issues with this.
CharlieDigital commented on IBM to acquire Confluent confluent.io/blog/ibm-to-... · Posted by u/abd12
IBM have an absolutely stellar record of blowing acquisitions. The highly motivated newly acquired team will be in honeymoon phase for 3 months, and then it slowly dawns on them that they’ve joined an unbelievably rigid organization where things like customer satisfaction and great products don’t matter at all. Then they’ll be in shock and disbelief at the mind boggling Byzantine rules and internal systems they have to use, whose sole purpose is to make sure nobody does anything. Finally, the core IBM sales force will start to make demands on them and will short to ground any vestiges of energy, time, opportunity and motivation they might have left. The good team members will leave and join a former business partner, or decide to spend more time with the family. They’ll meet often at the beginning to relive the glory days of pre-acquisition and recount times where they went went above and beyond for that important early customer. But then these meetings will become fewer and fewer. Finally they’ll find a way of massaging their resumes to cast the last years as being “at the heart of AI infrastructure”.
> ...and internal systems they have to use, whose sole purpose is to make sure nobody does anything
CharlieDigital commented on CATL expects oceanic electric ships in three years cleantechnica.com/2025/12... · Posted by u/thelastgallon
Stick the batteries in containers and you just swap them and load them whenever it is convenient.
That is a neat solution that would make it part of the standard physical interface of the port.
All of the machinery is already designed to handle containers so it just becomes another type of container.
CharlieDigital commented on Why "all-in-one" productivity tools confuse new users · Posted by u/suffei771
I think the key is the mental model, as you said.
One danger is trying to reduce multiple different concepts to a single concept. For example, instead of thinking about an email, a task, and a calendar entry as separate things, we could just have a generic concept like an "entity" which has attributes like a time/date or a list of people or a body of text.
Programmers love that kind of abstraction. We love having a few simple pieces that we can combine in various ways to get what we want. That is literally what we do when we program.
Normal people, though, hate that. Instead of giving them a tool to get their job done, we've given them a puzzle. They need to figure out how to combine the pieces. And what's obvious to us, is absolutely not obvious to them.
I haven't seen your UX, so I don't know if this is an issue, but I would focus on the mental model. As a user, what do I need to know to start using the tool? If that's more than a single sentence (to start) then you're in trouble.
I'm always happy to brainstorm with people. Hit me up if you want to chat sometime.
> Normal people, though, hate that. Instead of giving them a tool to get their job done, we've given them a puzzle
On the other hand, highly integrated or opinionated tools need to be both easy and flexible enough to fit existing models/processes or it will simply overwhelm new users. Or it has to have some other benefit that is significant enough that users are willing to change their models/processes.
There's a lot of good research and writing on this topic. This paper, in particular has been really helpful for my cause: https://dl.acm.org/doi/pdf/10.1145/3593856.3595909
It has a lot going for it: 1) it's from Google, 2) it's easy to read and digest, 3) it makes a really clear case for monoliths.