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

  1. 5:10 The problem with MVPs is that they very easily and quickly become the production code. Once you get an MVP out, so do the requests for changes and improvements and additions. Before you know it, you have a full blown core system written in a scripting language. So do you choose what’s easiest or should you pick what you want to end up using?
    116
  2. The push to AWS, Azure, etc, is basically the same as choosing to be a renter vs a home owner. There’s pros and cons to each.
    72
  3. 10:03 sounds like they worked him to exhaustion for years without giving him the required resources, then the cherry on top was to replace all his years of effort. I’d explode too.
    11
  4. 14:41 but they aren’t mean answers. They’re blunt, not mean. I think SO moderators suffer the same problems as call center operators. You can burn out, and get annoyed at the same bad questions over and over. At that point, the SO mod should probably hand the reins to someone less jaded who still has the capacity to be friendly.
    9
  5. 22:44 Ruby should be higher than Python on all those lists. Ruby is actually awesome. It has amazing libraries, it’s super flexible which makes integration with other systems amazing, it has awesome frameworks like Arel, ActiveRecord, ERB, and Rails which make it a breeze to build some amazing stuff very quickly. You can easily make command line tools either by making the file executable, or using libraries like rake. The meta programming functionality is next level. It interoperates with C. So if something is slow, build the parts you need in C instead. It’s a super flexible and concise language.
    9
  6. 4:00 Often I find that complexity in code is built rather than inherent; the programmer just wrote complex code instead of the simple code.
    8
  7. 25:53 that is such a good explanation… nothing is hard when you have the foundations… it’s just time consuming.
    8
  8. The problem is that software is so soft and so explicit that the software IS the documentation. Really the only way to verify that it does what it should do correctly is through tests. So tests document the requirements. So, all documentation from software is derivable. The problem comes from non-software engineers getting into the mix. Software doesn’t have a person in the C-suite with specific software engineering training and experience (which it should), and product managers and UX teams who don’t have software engineering training have gotten into the software engineering pipeline. I’ve seen software engineers being pushed down to basically factory worker level. The lowest rung on the organisation hierarchy. It makes no sense. No other professions do this. You don’t have a non-engineer managing engineers building airplanes. You don’t have non-doctors managing teams of doctors. You don’t have non-academics leading teams of academics.
    8
  9. 6:54 you could probably do currying with anonymous classes. It looks like local variables in scope can also be returned, so it’s basically a closure too. But just generally, creating a class or stuct is creating a closure over its field/properties, the benefit though is that classes and structs can have more methods, where as what people traditionally think of as a close is just a single method.
    7
  10. If the problem that Dave is trying to solve is to increase the frequency of feedback on code changes, the answer isn’t by default to push to remote master and run tests, but rather to test before every commit or perhaps before every push. If the problem to solve is ensuring everyone has the same version of reality, then frequent rebasing is the way to go. But I get the dilemma of having a develop branch. Sometimes develop can be too far in front of master (like how a feature branch can be too far in front of develop), and the size of changes in the next deploy becomes too large and increases the chances of unintended side effects. In that case, frequent deployment to prod gives the necessary quick feedback to address any issues in a manageable size. The reason develop and feature branches exist is to provide a buffer between what is going out and what is being developed. The management of the size of that buffer is important, but the tools used to manage that buffer isn’t as important than the methodology of managing effectively.
    6
  11. 2:20 Ruby is actually a very Awesome language. Makes you feel like God.
    6
  12. Don’t stackoverflow shame. It’s a legit source of knowledge. Otherwise, any and all Q&A should be deemed illegitimate, which would be stupid.
    6
  13. 8:36 just inspect element? This is the same thing as extracting html into components or partials, but for styling. If its fine to extract html into partials or components (or whatever terminology you use) then it’s fine to do the same with styling. If you don’t, then how do you know you are applying consistent styling and not missing something and unknowingly creating small visual inconsistencies? Then later on, some developer has to decide whether the omission was purposeful or not.
    5
  14. To be fair this isn’t a SQL directly from browser to the database issue. They could have had any number of layers between the browser request and DB query and still have a bug like this. The problem is using the id given in the request from the browser.
    5
  15. 19:20 he didn’t destroy the second half of the vid… all his points were surface level deep, but when you dive in with any rational thinking you realise his fears are based on misunderstandings of what ORMs really are and how they should be used.
    5
  16. 1:37 Clean code used to mean something back before 2016… but now it’s lost all meaning because devs apply it to almost anything… in a similar vein to how everything is agile now 😅
    5
  17.  @ThePrimeTimeagen  lol yeah… of course… but also some logic to this… if a dev is not caring about the small things, they probably aren’t caring about the big/important things either. Or if they do, they probably aren’t getting the big things right either. My guess is there’s a correlation there.
    4
  18. 8:54 there are sooo many improvements that can be made to SQL even without inventing something by totally new. First, put FROM statements first. How can you get code completion in your SELECT clauses without knowing which tables the data will come from? Second, name table relationships. Instead of joining, you use the relationship name. There are so many query patterns that could be abstracted, though I guess that’s what stored procedures are for. The other thing that gets me is that all RDBMs are also inherently object/graph databases. So in theory, they could all have object/qraph QL applied. The other other thing, is that SQL or an improved derivative language could be used by clients instead of GraphQL to query APIs. The whole data persistence part could be abstracted so that you get secure decoupling between the domain data and the persisted data.
    4
  19. 6:45 this is similar to the Roko’s Basilisk argument.
    4
  20. 5:02 My watch later list is maxed out because it’s filled with technical heavy vids that I don’t have time to watch 😂
    3
  21. Async await still sucks because it spreads like a disease. And you end up awaiting everything. So everything may as well have been synchronous. The code to kick off multiple async functions and await the completion of both also isn’t that nice to write or read. Especially if you have to await the return of one or more before kicking off addition async functions. I like the go syntax for this: a, b =: <-c1, <-c2
    3
  22. REPLs are awesome at design work… quickly test a concept… does this work? Yes! Does this do what I expected? No! Why not? Oh! I understand now! I guess exploration for me is a fundamental part of design.
    3
  23. DHH is so inspiring. I love what he’s saying, and I hope it resonates with the rest of the software engineering community and inspires everyone to bring back the simplicity. I also can’t wait to work on another Ruby/Rails project. It’s by far my favourite language and framework but haven’t got to work with it for five or so years.
    3
  24. Nah, nitpicking is good. If you don’t fix it now, it’ll sit around annoying everyone forever… inconsistent casing, spacing, indenting, naming, use of concatenation instead of interpolation, use of concatenation instead of multi-line stings, no new line at the end of files, EOL whitespace, new lines not added between methods and between logically grouped statements and expressions… all of it should be closely guarded and protected and fixed.
    3
  25. Makes sense. Return XML as a response and the responsee can further query and manipulate the results using XPath and then convert the output using XSLT. I actually don’t understand why XPath and XSLT haven’t been applied to JSON, YAML, ProtoBuff, etc etc etc.
    3
  26. I don’t understand the problem with promises already running in the background and the value being memoized. Just pass around a function instead. You can then call the function as many times as you like and get new values each time.
    3
  27. 8:20 why you dissing on Ruby when it has similar performance to Python which runs so much AI and data tasks?
    3
  28. 7:15 tip #75: add fraudulent flags via one or more table joins
    3
  29. 4:03 they know sharding isn’t new right?
    3
  30. 1:37:08 awww man that’s why I miss Ruby. Feeling like a god! You can kinda get that sense in other languages when many large pieces fall into place, but in Ruby it’s just next level because it happens so simply all the time. But we live in a world where many people expect and want types, so I don’t think many from that paradigm will like it.
    2
  31. 16:03 solve learned helplessness - just keep going till the goal is complete. Simple.
    2
  32. 12:02 what’s great about importmap is that you can do both. You can have a project that uses both unprocessed JS AND pre-processed JS. 🤯. I know that defeats the argument against no-build but the choice should be about how and where we manage complexity. E.g only put what you need through a build step, and the rest leave untouched. Maybe that just adds more complexity or maybe that makes things simpler… that’s for each team to decide and manage.
    2
  33. 3:25 I imagine the rate of change for younger languages would be higher. The only thing changing that would be new paradigms that fundamentally change how we think of programming vs the culture of change for that language.
    2
  34. Locality of behaviour is so contextual though. It depends on what behaviour you’re looking at.
    2
  35. 3:25 blerg! Why do peeps use JSON for this 💩. At least choose something easier to write and read like YAML.
    2
  36. In a large company it completely makes sense to build your own… especially if the cost is ultimately cheaper to build and maintain, and reliability is ensured.
    2
  37. 8:24 that’s why we need a Chief Software Engineer in all C-suites, and a Software Engineering vertical similar to the IT vertical.
    2
  38. Actually, I don’t understand why there aren’t XPath APIs (like GraphQL APIs, but using XPath). Or…. SQL APIs for that matter.
    2
  39. 17:30 nooo… an ORM shouldn’t be chosen so you can switch database tech, instead chosen to be a client written in your language of choice to manage your persisted data. Just don’t use raw SQL in code. If the db schema changes, you’d have no IDE support to help you change all the places that may need changing. You and your team will likely get to a point where you’re fearful of changing the db schema, which is bad. The exception to this should be when you abstract the SQL behind a stored proc, the SQL of the stored proc should of course be managed by the migrations, and therefore should be in the code… but the calls to the stored proc should be done via an ORM.
    2
  40. 0:01 oh dude… ORMs aren’t trying to make SQL obsolete… this is gunna be painful. ORMs are no different from using a client written in your favourite language to speak to an API written in another language. So if you have a problem with ORMs, you have a problem with any type of system to system integration.
    2
  41. 16:31 also, Dave focuses on tests for expected behaviour, not expected failure. So if failure is expected behaviour, he’d write tests that verify the failure is happening in an expected way. Make sense?
    2
  42. 1:25:26 you can also hash the password on the front end so your backend never even gets access to the original password! Still need to do the usual hashing and salting and preventing of time attacks on the backend of course.
    2
  43. 7:04 oh dear… why is there YAML here
    2
  44. 2:09 lol power bi.
    2
  45. 7:10 it’s not just readability that can be based on preference. I think how you code up and encapsulate complexity can be based on preference too.
    2
  46. 4:09 nooo! It’s gif as in gill… and mut as in nut and char as in charcoal… everyone one knows that… any other pronunciation is just people taking the piss
    2
  47. 5:30 “there’s no argument that says it’s more efficient to forego types”. I remember when I moved from Ruby to C#. I felt like suddenly my hands where tied behind my back. I was trapped and forced and confined into a very limited way of doing things. It was so frustrating. I had to relearn my entire way of thinking. It occurred to me that dynamic languages is actually about fluid data transformation. Many different streams of data flows through a program and gets transformed and combined and manipulated. Dynamic languages are very good at working with disparate data. Typed languages on the other hand are unforgiving when working with the shape of data. Everything must be precise and methodical and there must be no deviations. There is a magic to dynamic programming once you realise this. Dynamic typing gives you built-in discriminated unions… the hot topic of the day. If static typing always mattered for efficiency of type checking, then every develop that chooses static typing would never choose to use schemaless databases.
    2
  48. Software engineering defs needs to be a degree. We could do it by apprenticeship, but it’s an engineering skill and those base skills need to be taught consistently. Anyone can do a home renovation or build a cubby or shed, but not everyone can build a building or bridge. Same with software scope.
    2
  49. 7:03 how is multi-dispatch different from overloading??
    2
  50.  @isodoubIet  ahhhhhh! Ok got it. Thanks!
    2