I can't count the times I've worked on systems where loose coupling, and no proper data definitions and typing in event buses led to spaghetti that goto spaghetti soup could only hope to emulate. These kinds of systems often rely on anecdotal hearsay and lived memory as documentation systems, and debugging prod logs lead to a bunch of "oh yeah, I remember now!" Sure, it's easy to rewrite little modules/actors/microservices in schemaless, loosely coupled software - but with each rewrite, something of the original intent and lived knowledge will be lost. This is more akin to credit card debt, or high-interest rate variable mortgage.
The problem I see is that the tech debt often lives in the in-betweens, in the contracts between services, in the models being passed around. I would like to see a more concrete discussion of what it looks like to reorganize a 17,000 line monolith into deletable, one week chunks.
Much truth in there. However, not all debt is contained within one one-week bit. Then fixing that is not just a week. And when the behavior of the system emerges from the connection of small bits of behavior that's also nothing to rewire within one week.
Hey Tretton, I’m Nik and I’m researching consultants’ problems on RU-vid (I’m not selling anything). What are your biggest problems with RU-vid? (Don't have enough time, aren't getting enough leads through it,...) Your response would mean so much to me, so thanks
I don't buy this. The idea that you write a ton of small programs such that they aren't interdependent upon each other is not practical for most applications. Any sufficiently complex program will have dependencies such that when X changes, you also have to change Y. In the worst case, this cascades and now you have to change A, B, and C.
As Greg suggests, small programs have more advantages than disadvantages, but things are not that much simple always and also things are not viewed technically always.. Programs size and in other words programs boundaries are political aspects in many companies… To be happy with it or not, it happens that around programs some form of ownership is created.. Finally, programs size are in most cases further than just a technical issue
Writing small programs inside a a big program is ok and not a new idea. But, overhead of managing and understanding too many small connected programs is still complex.
Geat talk!! Greg again confirmed that in IT there is too much teenager-like attitude 'won't learn from elders - my world is very different. Let's invent!'
That was great. The state monad was a twist for me because of the "life force" analogy. I always thought that it would be something for a logger at the end. This was a very good presentation
In an event sourced system, does anyone know how to delete the code and still enable replayability of events? Keeping around old models for replayability doesn't seem like a great idea, but how do you do it otherwise?
Great question! You've touched on a core challenge in event-sourced systems, tbh. The short answer for that would be "Event versioning" (meaning, we have to introduce new event versions for model changes, keeping old events compatible), "Upcasting" (transform old event versions to the current one on-the-fly, eliminating the need for old code) and "Archival" (archive obsolete models and events, using snapshots to capture system states). For the long one, we need to ping Greg 😅
Fantastic talk! This solved the mystery of options and async in multiple programming languages for me at once. I wish I could like it more than once. Great job!
Won't help. They will listen to it on 2x speed, pretty much the same like they read only first page of Royce's at best. Most never bothered to find it.
imo CLI puzzles have their charm, but nothing beats the adrenaline rush of cracking an AoC challenge. It's like comparing a leisurely stroll through a garden to a thrilling rollercoaster ride.
one bad thing about adventure of code is that it does not encourage you to solve the problem. I quit after like 5 days last year, and this year I quit after first one lol. I thought it was supposed to be for people who wants to learn to code, and for them who can code to help a bit. I hope someone does a Adventure of code for those who dont code that much but wants to learn.
If you want you learn, take some AoC problem that you like and look up some videos about it here on RU-vid. There is plenty to choose from and some are very beginner friendly. Happy holidays, and happy coding!
There's many tutorials that will hold your hand on the internet. If you wanna learn, that's what you can start with. AoC is different. It presents problems to you in a way that's not too different from what you might experience while working as a programmer. It is then up to you to find a solution.
AoC is about giving people problems to solve that are small enough to solve in a short time, if you put the effort into solving them. Think "exercises" instead of "coaching". It will meet you exactly as far as you are willing to meet it. If one doesn't want to learn independently, AoC is a terrible "learning" experience. If one does want to learn by being confronted by things beyond their grasp (and then using other resources to learn how to solve such a problem), it is great "learning" experience.
okie, we can say we think different :) I see many people write they dont even bother after a few days, so I guess we are a few that dont think its a good way.
Why don't you edit the video and cut out the mute part or at least put a text on the video with info? I bet many of the viewers like me frantically tried to restore bluetooth earphones connection or phone sound settings... save us the hassle :)
