Hello Team Trongate,
I have just uploaded my new short video to the Trongate YouTube channel: https://youtube.com/shorts/x4kdZ4E5gsw?si=65ETwGxo190djm4F
I hope you guys like it!
New Short Video: How to Be a Successful Software Developer
10 days ago
10 days ago
#1
10 days ago
#2
Lovely setting, good message.
Would enjoy seeing a topic such as technical debt addressed, here’s a primer video https://youtube.com/shorts/mLinl_fWbzw?is=P9EG9YQ3S3xkrK2F
Would enjoy seeing a topic such as technical debt addressed, here’s a primer video https://youtube.com/shorts/mLinl_fWbzw?is=P9EG9YQ3S3xkrK2F
10 days ago
#3
Great topic Jonas, that video appeared on my feed too - he does make a great point.
10 days ago
#4
Thank you, Jonas. I've watched the video you linked, and while he makes some fair points, he doesn't quite define what "bad" code actually looks like.
He implies that bad code is simply code you have to revisit later, but that definition doesn't hold up. We revisit "good" code all the time. Whether for language deprecations, new features, or updated documentation. Revisiting a codebase is a natural part of its lifecycle, not an inherent sign of failure.
He also defines technical debt as the "implied cost of rework" caused by choosing an easy solution over a "better" approach that takes longer. This suggests that simple, fast solutions are naturally inferior to "modern" patterns. In my experience, the opposite is often true.
Over-engineered frameworks often sell the dream that "it takes longer now, but it will pay off later." It rarely does. Instead, you end up banging your head against a wall six months down the line, debugging deep layers of abstraction, managing endless dependencies, and applying pointless updates just to keep the "modern" stack alive. You eventually realize you would have been far better off doing it yourself, the simple way.
If I had to choose between maintaining a "modern" framework-heavy codebase or an "old," slightly messy, but simple one, I'd pick the simple one every time. In my view, true technical debt comes from UNNECESSARY COMPLEXITY, not from choosing an easy solution that works.
This is a fascinating topic, and I might make a video on it, even if it ends up being a bit controversial.
He implies that bad code is simply code you have to revisit later, but that definition doesn't hold up. We revisit "good" code all the time. Whether for language deprecations, new features, or updated documentation. Revisiting a codebase is a natural part of its lifecycle, not an inherent sign of failure.
He also defines technical debt as the "implied cost of rework" caused by choosing an easy solution over a "better" approach that takes longer. This suggests that simple, fast solutions are naturally inferior to "modern" patterns. In my experience, the opposite is often true.
Over-engineered frameworks often sell the dream that "it takes longer now, but it will pay off later." It rarely does. Instead, you end up banging your head against a wall six months down the line, debugging deep layers of abstraction, managing endless dependencies, and applying pointless updates just to keep the "modern" stack alive. You eventually realize you would have been far better off doing it yourself, the simple way.
If I had to choose between maintaining a "modern" framework-heavy codebase or an "old," slightly messy, but simple one, I'd pick the simple one every time. In my view, true technical debt comes from UNNECESSARY COMPLEXITY, not from choosing an easy solution that works.
This is a fascinating topic, and I might make a video on it, even if it ends up being a bit controversial.
10 days ago
#5
Yes! It’s a topic that’s very much relevant especially nowadays with so much AI generated code.
True, in that video he breezed over it but in earlier videos he’s described it as code that’s tightly coupled and can’t easily be changed.
E.g. a change in a seemingly unrelated module that breaks others in unexpected ways. Fragile, brittle.
I see how it can be understood that way, a better wording would be: do proper engineering — think through the problems and decide on the simplest solution, applying the principles of least surprise.
Code is a liability and you’re still responsible for owning the libraries you’re shipping — a topic that ties nicely into all the NPM and supply chain drama going on.
Besides, controversial opinions is baked into Trongate’s genome already ;)
True, in that video he breezed over it but in earlier videos he’s described it as code that’s tightly coupled and can’t easily be changed.
E.g. a change in a seemingly unrelated module that breaks others in unexpected ways. Fragile, brittle.
I see how it can be understood that way, a better wording would be: do proper engineering — think through the problems and decide on the simplest solution, applying the principles of least surprise.
Code is a liability and you’re still responsible for owning the libraries you’re shipping — a topic that ties nicely into all the NPM and supply chain drama going on.
Besides, controversial opinions is baked into Trongate’s genome already ;)