Lean

@d4rm_ 🥹

es terrible tener 256 GB de disco

A quien veo acá?

@DamianCatanzaro Baby steps. Los principios siguen siendo los mismos de siempre. Ni hablemos de feedback rápido, repetible.

Charlando con amigos que no son devs y se pusieron a hacer cositas con AI me di cuenta de porque gastan tantos tokens y queman límite a 2 manos: - Usan todo en un mismo chat por lo que el chat va creciendo y creciendo y creciendo y cada vez le mandas mas contexto. Cuando pensamos un proyecto hay que irlo separando en pequeñas funciones, cada función va a ser un desarrollo en si, ejemplo en OpenCode hacen /new y arrancan una sesión nueva, el mismo OpenCode es lo suficientemente inteligente para saber a dónde buscar en la carpeta que esta parado. Estaba viendo que algunos usaban Cursor y gastaban 900k a 3M de tokens por request, es una locura, mis ventanas de contexto no superaban los 150k de tokens en la totalidad del chat, siempre piensen cada chat cómo una funcionalidad, no cómo un proyecto y no solo van a tener más tokens para desarrollo sino que el modelo se va volviendo más tonto a mayor cantidad de tokens pasado cierto umbral.

@brenditech Hola! me pasas info del club?

El libro que estamos leyendo en el club de lectura este mes 🤯 Te dan ganas de irte a vivir al campo y comunicarte mediante señales de humo.

@davefarley77 No immediate cost of not applying them.

What's the NUMBER 1 reason people ignore software practices that they KNOW work far better than what they currently do?

@pepicrft That's right. What matters is the pain. There are problems without a significant pain.

offering a solution to a problem doesn’t imply people will pay for it, specially if 1 they were not aware of the problem 2 and therefore they don’t grasp why a solution is needed you can also trick the system and make them believe the problem is more serious than what it really is and drive emotional sales

@gptcrosa En la cancha se ven los pingos

Tarde o temprano te das cuenta que esta es la manera. Anthropic, como siempre, adelantados.

@valentinajemuov We write tests to refactor.

Unit Tests should NOT mirror code If your unit tests are mirroring your source code structure - one Unit Test per class, then you're doing it wrong. -- Register: “Stop Breaking Production: ATDD in Legacy Code” (Sep 24, 5 PM) - maven.com/p/f39276/stop-… #tdd #unittesting optivem

@davefarley77 YES! We don't write test just to have tests. We write tests to keep reshaping the system safely, to change its structure without affecting its existing behavior. Refactoring is the real goal, tests enable refactoring.

Refactoring isn’t optional. I hear teams talk about "refactoring sprints" or treating it as a luxury. That’s completely backwards. 1/6

@MatManferdini Back in the old days, everything lived in the view controller. It was hard to maintain, not testable, but that's what we did. Now, everything lives in SwiftUI views. It's similar, just nicer. VM-ish shape tends to emerge naturally when you want automated testing.

I'm working on an article on SwiftUI view models. Is there something you disagree with? Give me your best argument in the comments and I might include it in the article.

@corneliusmark @MatManferdini Sometimes it's hard to see that UIKit (or SwiftUI) is an ~external~ uncontrolled dependency, you can't change it if you want to. We're just using it, not designing it. With that in mind, is better to treat it as legacy code (because it has no tests).

@MatManferdini Never apply another architecture than the one the frameworks have been designed with in mind. Not adhering to that always results unnecessary extra work.

@MatManferdini Yes! Beyond the power of the tool, the real impact (and a bit of the hype), what really matters is the training. We have almost free access to trained models, but not to train them. I recall Tesla training vision—they even built their own "IDE" for it.

It is impressive how AI keeps writing code I tell it to not write. Despite all my guidelines, links to articles, and code examples, LLMs still write code the wrong way. There is no way of making them follow even simple design patterns if they learned the opposite online.

@MatManferdini @Dimillian A real project isn’t where you practice DI, testing, or architecture. You should’ve figured that out before. Businesses pay for execution, not for coding experiments and practicing.

This experience from @Dimillian is interesting because I have never had it, but I have witnessed much of the opposite. Not saying it's not true. However, I have seen plenty of projects crushed by technical debt and poor architecture. One startup had to hire a third party and spend tens of thousands of euros to correctly rewrite their MVP from scratch because it was so bug-ridden it was unshippable. One large company had a project that was three years late because it was also full of bugs caused by a total absence of architecture. It took me days even to find the source of a bug. At my first job as an iOS developer, the app was plagued by the botched architecture we inherited from the initial consultants who built it. Once, a two-week sprint took four times longer. I was tasked with adding unit testing, and it proved to be practically impossible. The whole team agreed that we had to rewrite the app from scratch, but management always said no, as that would have meant months of development with no new features. There might be startups failing because they can't ship an MVP fast enough. However, I have seen numerous quickly shipped MVPs that didn't gain market traction anyway. That's more of a market research/position problem than a technical one. I agree with @Dimillian that there are many projects with overly complicated architectures and rigid patterns, such as VIPER, that are often implemented for their own sake. I see many of them online. However, the solution is YAGNI, not discarding architectural patterns entirely. Design patterns were created to solve problems. If you don’t have a problem, you don’t need the pattern that solves it.

@fwpolverini @PatoBullrich Cual shell?

@PatoBullrich Estoy en tandil no hay NAFTA casi en ningún lado, solo un Shell te carga cupos de 5000 pesos

Es terrible lo que estamos viviendo con este gobierno. Recién quise cargar nafta. Fui a cinco estaciones de servicio y me dijeron que no había. ¿Ustedes para cuánto más tienen combustible?

@tottinge Fastest feedback is the key. It's also interesting to run these REPL-based cycles inside a test, once it's stable, add the assertions and leave the test to know if something breaks. That test can be deleted if becomes irrelevant.

"But you can't do TDD when in discovery mode" Absolutely. I agree 100%. I do a lot of REPL-based work when I'm not sure how things can be put together or how an API can/should be used, etc. I don't have a problem with this. Do you?

@housecor Not only typescript

A common TypeScript mistake: Needless optional fields. Me: “Why is this field optional?” Dev: “In case someone doesn’t pass it.” Me: If the field is required, require it. Requiring fields (when possible) clarifies intent, simplifies the code, and improves type safety.

@notengoid @alexbunardzic Documentation doesn’t execute.

@alexbunardzic Documentation >> TDD, in my honest opinion

What is the software development practice that makes many software developers feel the most threatened? In my experience it's TDD. No other discipline causes so many people to deny it so vehemently.

@MrMcSwiftface Are you writing the tests after writing the code?

I’m pro unit testing but I don’t think I’ve ever seen one catch a legitimate bug

@twannl When the error is thrown (to try/catch) it has no type. I prefer not to lose the error type. The tuple of two optionals is the worst of the options by sure.

Async await in Swift makes it less needed to use the Result enum. Personally, I've not been using it anywhere else than inside completion closures. Do you still see value for the Result enum? avanderlee.com/swift/async-aw… #swiftlang #iosdev

@mecid The view model should access domain objects (product) and expose the visible things (formatted text) so the view renders them. I’d put formatting in the vm and move it to a vm’s collaborator if needed (repeated/similar formatting needs). But that’s an implementation detail.

Assume you have a Product type with the title, price, and created date properties. You should display it on the screen, but before, you should convert the price and date to strings. Where would you put that formatting logic?