Comments by "Brent Jacobs" (@br3nto) on "ThePrimeTime" channel.

  1.  @ba8e  No. CTO is too broad and likely more IT department focused. Developing and maintaining software systems and all the processes that go along with it requires a specific skill set. It needs to be its own thing.
    1
  2. This is happening everywhere… your prime minister or president will be asking chat gippety how to handle different complex situations. Oh no… my approval rating is dropping… what should I do chat gippety?
    1
  3. 57:21 rails is one of the greatest things ever
    1
  4. 14:56 this just tells me that error messages and debugging techniques need to improve
    1
  5. It’s no different than types vs dynamic languages. The type guys are incredibly religious there too. They don’t see how there could possibly be other methodologies of programming, or the benefits of it. They don’t seem to realise that types are like shackles. Languages that are not reliant on types focus on data and data flow, and data transformation. That icky messy world of raw data from the real world.
    1
  6. 11:21 domain duplication happens everywhere. Any client calling a server will have a duplicated domain definition. Any actor using a protocol will have a duplicated domain definition. This is only made worse when the clients/actors/servers are written in different languages.
    1
  7. Yeah I’m moving more and more to the no-build camp. This craziness is adding more complexity not less. I don’t think the extra complexity is worth it. If there was a clear path to simplicity, and we had to get more complex first to get to the simplicity, then sure. But I can’t see how this solution leads to simplicity… the proposed solution is basically a complexity multiplier.
    1
  8. 1:49 pragmatism isn’t avoiding unpopular opinions or decisions. It’s making sensible real-world achievable choices rather than the theoretically best choices.
    1
  9. 13:28 yeah that example sucks
    1
  10. 4:27 and 16:22 I think Primeagen is not understanding Dave’s approach. Dave’s TDD is much more atomic than testing an entire complete function, edge cases and all. In the first TDD iteration for writing a function, a function will have 0 edge cases, in the next, a new test added, to test an edge case which will fail at first, then the function is updated to meet the new expected behaviour of the two tests, rinse and repeat. You don’t write the entirety of the behaviour of the function up front, you build it up piece by piece. So a buggy test isn’t really likely because it is so atomic. Now you might argue that the tests are then too fine grained and brittle, however, they test the functionality that is expected of the program and the stakeholders, so if a requirement changes, you remove the no longer applicable tests and one by one add new ones with the new requirements.
    1
  11. 22:23 yeah that’s the point of TTD for existing code… it forces you to update the code in ways that makes it testable, which in my experience, does actually make the code better and nicer to work with and improve over time. All code that can’t be tested is difficult code to work with and to change because it’s just so highly coupled to everything around it. Adding TDD for code like this forces the decoupling and improves the design over time. It just takes a really long time… sometime it effectively equates to a full rewrite… but you can do it very piecemeal, so easy to prioritise other more important dev work.
    1
  12. 23:02 I assume if testing embedded systems, you’d actually test the expected behaviour of the embedded system rather than mocking it.
    1
  13. 41:51 If tests are testing behaviour, then it should be a relatively easy refactor. A refactor may involve changing the method signatures or design structures, but the behaviours being tested remain. So the tests need to be refactored to ensure all the behaviours are still being met by the changes. This is fundamentally the Refactor step. Improving the design, and using the existing test to see what you broke, then fix it. But it also forces you to make smaller refactoring changes, which in theory, is better for stability, and the sanity of the other developers who are also making code changes.
    1
  14. 44:55 the problem with test driven debugging is that your code needs to be in a state that is already testable… if it’s not, then how do you even add the debugging tests? Catch 22.
    1
  15. 8:39 the code is indented and wrapped in a `do` block. The indented code doesn’t look like it’s changed. Or maybe it has. It’s demonstrating how structural changes mixed with code changes are hard to rationalise and review. I don’t understand why the new method doesn’t indicate the added whitespace on the indented lines.
    1
  16.  @bacon-SG  sure. And Ruby can do the same
    1
  17. 3:59 is code changing more frequently because it’s wrong and needs fixing or because it’s not easier to iterate and change??
    1
  18. 27:04 it could also be a more iterative paradigm is taking hold.
    1
  19. 10:13 I don’t understand how unhandled edge cases is a proof of the decline of software engineering. That’s not a software problem, that’s a human problem.
    1
  20.  @pretzelboi64  it’s a human problem. If the software doesn’t handle an edge case, a human didn’t write the necessary code to handle the edge case. Either by choice or because they didn’t know the edge case existed, or because of trade offs with deadlines. Many softwares do handle ridiculous edge cases. So it’s really cherry picking to make this statement. Many softwares follow a CI/CD pattern unlike bridges, where the software gets constant updates and new features. The older features in theory should get more stable and less bug prone, where newer code is likely to have less error handling…. It’s still not proof of a decline in software engineering.
    1
  21. 7:08 web assembly is like Java applets… where did they go?
    1
  22. @ what the difference between an MVP really? A prototype proves the concept… so in theory it is the minimum viable product. Usually though… there is an exisiting system in which the prototype must be delivered through and integrated with… so why bother proving the concept in anything but the actual system that will deliver the product… in which case the prototype is pretty much the MVP.
    1
  23. @ as an example… my team just spent the last 6 months rebuilding something that was prototyped 6 months earlier… but we couldn’t use anything from that prototype because it didn’t use real data, it didn’t use our system, it didn’t use the front end libraries we were using, sure it prototyped the product and looked cool… but it was a worthless prototype… it was just a gimmick
    1
  24. 22:51 learn just enough of new tech to realise you don’t need 90% of it but also enough to know when you need to start applying the 10%. Then you can defer the actual learning when you actually need to know.
    1
  25. 6:31 Builder is just an wordy constructor. Sure it's fun to return self or this but you could just create a constructor that’s signature is in the shape of how things are needed. Pass in a new Bun With Sesame, and new Toppings with new Swiss Cheese and new Fish Patty. Works the same, but without this intermediary builder class.
    1
  26. Simplicity is often in the eye of the beholder
    1
  27. 17:39 I don’t have the time to learn everything and also achieve all the things I want to achieve. So I outsource to Google, Stackoverflow, ChatGPT, other devs. It’s probably not a really problem just using the resources available. I company can’t actually do anything so it outsource everything to people. So it should be fine for people to outsource too.
    1
  28. Ok yeah I get what he is saying about meta work. Spend hours talking about the task to be done, the knowns and unknowns, who in the org may have the relevant skills, the correct communication paths to reach those people, find out those people are on holidays, so wait till they get get, then all meet and gather info from that expert, then meet back the next day to discuss the info gathered from the expert, then talk about the task to be done, and the knowns and unknowns, and then document our current knowledge, then do it all again. Yeah meta work takes up orders of magnitude more time than the actual work.
    1
  29. 5:04 what no one cares to admit is that OO is a superset of FP. Just a little invisible elephant in the room.
    1
  30. 30:47 it’s easier to go from monolith to micro services than it is to go back to monolith
    1
  31. 7:24 so demand for actual developers is gonna go through the roof! We gonna get so much $$$ to fix all the mess 💸🤑💸
    1
  32. 6:54 singletons are awesome until you need two or you realise that client apps may have two or more contexts in which they are using your library, but you're forcing them to singletons. It's basically always a bad idea. Why bother going to extremes to make sure only ever one is created? Just create one instance. Super easy and scalable.
    1
  33. Type vs var keyword - that’s the ultimate discussion. Var should of course be used everywhere unless Type is explicitly required. The reason is simple: var is like an interface to a concept. This requires a slightly different way of thinking when reading code. The “concept” is described by the expression after the assignment operator. This means the variable name and the expression must be descriptive and readable, so it leads to self-describing code that is easier to read/understand. And because we are coding to an interface (of a concept), future devs are free to refactor as they wish as long as the concept holds; they aren’t constrained by the type decided previously.
    1
  34. 2:20 this has always been true though?? And SSR is way safer than CSR. Validate all you want on the client side and it really means sweet jack all… it all needs to happen on the server again anyways… plus the decades of learnings of what’s safe and what’s not… so “are you rendering unsanitised user input” should always be no.
    1
  35. 7:19 the had a better namespace separator when they first introduced the concept, but then they changed it to a / at the last. I think the separator was ::, which is used to access static members.
    1
  36. We’re getting so close to not having to code…. They just need to integrate CSPs, LLMs, and whatever the AST manipulation technique is, and boom! AI that could verifiably write code that meets the constraints given to it. Just open an issue, assign it to an AI helper, and in a short period of time you’ll have your new feature. I can’t wait!
    1
  37. 9:27 he’ll yeah!! No mocks!!
    1
  38. This is why so many countries are introducing sovereign chip legislation. The actual tech is locked behind patents, closely held institutionalised knowledge, and extremely complex and lengthy processes that are expensive to replicate. It takes a year or more to create the mirrors need in the photolithography machines. So I assume most countries will be creating older tech from older lithography machines.
    1
  39. 15:36 1326 lines doesn’t scream “unit” to me. Would that test even be understandable? Will it break at the drop of a hat?
    1
  40. I don’t think lines of code covered is a good metric for test. The metric for a good test should be: does it test a requirement, and does it effectively validate that my program meets that requirement.
    1
  41. 6:41 How would a transaction help? The transaction would complete and commit the change and they’d be in the exact same situation.
    1
  42. 9:03 I always do the opposite. I remove all semicolons unless they are explicitly required. Semicolons are unnecessary bloat.
    1
  43. 9:36 They aren’t required after let statements. But required because of the weirdness on the next line.
    1
  44. 5:22 ORMs are just a typed interface over the database. It’s the same as having and api layer between client and server. It’s literally no different. If SQL and database were actually useful on their own, we would simply get rid of web services and have all clients directly call databases.
    1
  45. 13:05 You should at least test that the features you want to support work as intended. So everything not covered by a test is just “unsupported” functionality
    1
  46. 7:38 breakpoint classes are frustrating… does the css apply or not apply when above or below that breakpoint.. so many permutations of possibilities of what will apply when.
    1
  47. We wouldn’t need tailwind if html allowed attributes like style:hover=“…” style::before=“…” etc. or supported some syntax to allow inlining of all or most of the special css pseudo classes and elements, selectors, combinators, etc.
    1
  48. 5:12 don’t encapsulate address and SSN… that’s GDRP gone too far
    1
  49. 4:48 is Deno ugly too?
    1
  50. 3:19 if you find you have fůcked up your db design, just throw in a migration and fix it… db schemas (and it’s ORM twin) aren’t static
    1