Some feedback:
- The constant interrupting each other made it hard to listen to
- Also the interviewer Theo/T3.gg giving his CEO take on strategy to sandbag silverlake after finding out more context behind silverlake and automattic's relationship led me to have an unfavorable impression of the guy
I don’t think that’s fair to say the person is not engaging content in a meaningful way. Have you read the article? It’s pretty clean cut aside from understanding who the perpetrators were. The ceo of a bank got conned and went to prison, and there’s emphasis on calling the con a “pig butchering scam”
Thanks, yeah it does sound like we share the same thoughts regarding paying for solutions that just work
I'm resistant to moving over to Apple because of pure vendor lock in, but also I can decouple passwords from my Apple ID. For example, I use a mac for work but I don't need to sign in to my personal apple id on my work laptop to get access to passwords.
I've been writing Ruby for the past 5 years or so and I think it's safe to say that these are very much opinionated takes on Ruby. There is no _one right way_.
A critique:
1. Verbosity vs Idiomatic, to me I find there are times the verbose approach is actually easier to read and understand
2. Long Expressions to Detect nil - this seems a bit like a strawman, sure there are better ways than to check the presence of an object/method chain, but doing the safe operator can bite you in the leg by compacting the complexity
3. Overuse of self - I skimmed through the Rectangle class declaration... it reminds me of writing Java. I rarely see self#method= used
4. Collecting Results in Temporary Variables - I think this is debatable, there's value in condensing method implementations when it makes sense, but also having temporary variable assignment can lead to better readability
I agree in general here, but safe navigation is almost always better, because you are reducing the amount of syntax being loaded into the developers head for the same effect, which helps to avoid getting bogged down and missing the bug, or losing sight of the overall goal. The level of terseness to employ is a balancing act and very nuanced, but safe navigation is pretty much a no brainer.
Regarding (3), I agree, after seven years on a massive Rails project working with tons of very talented Ruby developers, self#method= is typically avoided. However self#method is usually preferable -- when there's no assignment prior to reading the name, it's highly clear that the name is a method. There's always exceptions though.
Re (4), this is true but the decision of which calculation merits a temporary variable (assuming it's not needed for multiple use) can be pretty arbitrary. Elsewhere in this thread there is the sentiment that extra temporary variables increases debuggability which perplexes me, since most commonly Ruby debugging is done in a command line debugger like pry/byebug, and in that context you can simply evaluate part of the "packed" expression as needed. In languages which primarily use graphical debuggers and perhaps do not have the ability to evaluate arbitrary expressions, this is much more of a factor.
I found the original commit [1] since the other Github link in the thread shows the removal. I'm not entirely sure what the thought process was around adding it to begin with
Gusto adopted it when I was there (I left at the end of 2022). Like other comments, it's a bit polarizing but I found it to be useful when working in large codebases because you one didn't have to reason about return types and could just read them from function signatures.
Getting it to play nicely with Rails and other gems that did metaprogramming magic was a constant pain in the butt though.
My take is that there’s such variance in people’s skill levels and so it’s really hard to cater educational programming content. Personally, I’ve found getting introductory books/courses and skimming through it until you hit something that you don’t understand and then diving deeper into that bit.
It is interesting, though, that you can easily get intermediate training and coaching in basically any sport. But the thing you do for money? Take this very ad-hoc approach.
I’m sure you can find individual coaches but the cost will exceed what most people are willing to spend or invest. Take executive coaches for example, they exist but from what I understand they’re largely private coaching and cost $$$.
Concepts and excercises in sport don't change that frequently comparing to programming. Programming is very ad-hoc indeed, it has way more variables for the intermediate level so that the coach won't have enough time to digest the details.
