string ones are those most of the Rubyists remember.

Refinements themselves present a significant hurdle to adoption by virtue of their limitations and overall introduction of conceptual complexity. So it’s a tough sell to recommend this for anything outside of personal projects or places with incredibly strong esoteric Ruby knowledge (like, say, hidden away within Rails).

a more nuanced view of context.

they’re just too familiar with the code to think it's complicated

Wittgenstein makes a similar observation, pointing out that “the aspects ofthings that are most important for us are hidden because of their simplicity andfamiliarity (one is unable to notice something – because it is always beforeone’s eyes).” 3

Phenomena can be so familiar that wereally do not see them at all, a matter that has been much discussed by literarytheorists and philosophers. For example, Viktor Shklovskij in the early 1920sdeveloped the idea that the function of poetic art is that of “making strange”the object depicted. “People living at the seashore grow so accustomed to themurmur of the waves that they never hear it. By the same token, we scarcelyever hear the words which we utter . . . We look at each other, but we do not seeeach other any more. Our perception of the world has withered away; what hasremained is mere recognition.”

the research says is that students often

psychologists call the mere-exposure effect: doing something many times makes us believe wehave become good at it – completely independent of our actualperformance (Bornstein 1989). We unfortunately tend to confusefamiliarity with skill.

From day one, your team will love the familiarity of a spreadsheet, and the power of a database.

Rather than write new tooling we decided to take advantage of tooling we had in place for our unit tests. Our unit tests already used FactoryBot, a test data generation library, for building up test datasets for a variety of test scenarios. Plus, we had already built up a nice suite of helpers that we coud re-use. By using tools and libraries already a part of the backend technology’s ecosystem we were able to spend less time building additional tooling. We had less code to maintain because of this and more time to work on solving our customer’s pain points.

The problem domain and the data involved in this project was complicated enough. We decided that not having to worry about unknowns with the frontend end-to-end testing stack helped mitigate risk. This isn’t to say you should always going with the tool you know, but in this instance we felt it was the right choice.

This particular project team came in with a lot of experience using testing tools like RSpec and Capybara. This included integrating with additional tools like Selenium WebDriver, Chrome and Chromedriver, data generation libraries like FactoryBot, and task runners like Rake. We had less experience doing end-to-end testing with Protractor even though it too uses Selenium WebDriver (a tool we’re very comfortable with).

There are times to stretch individually and as a team, but there are also times to take advantage of what you already know.

The fact we’re using ActiveRecord (or something looking like it) doesn’t mean Trailblazer only works with Rails! Most people are familiar with its API, so we chose to use “ActiveRecord” in this tutorial.

Familiar interfaces borrow from well-established patterns. These should be used consistently within the interface to reinforce their meaning and purpose. This should be applied to functionality, behavior, editorial, and presentation. You should say the same things in the same way and users should be able to do the same things in the same way.

Slots can already be pretty confusing to comprehend, I think it is better to stick to what people (may) already know.

It's friendlier to contributors. Dart is substantially easier to learn than Ruby, and many Sass users in Google in particular are already familiar with it. More contributors translates to faster, more consistent development.

If the react cargo cult didn't have the JSX cowpath paved for them and acclimated to describing their app interface with vanilla javascript, they'd cargo cult around that. It's really about the path of least resistance and familiarity.

The only "issue" it has is that its unfamiliar. People have been working with HTML for years and are comfortable with it. That's basically the only reason that people find it more readable. If you make an effort to spend sometime with hyperscript, it becomes as familiar and readable as jsx.

But the reason I wanted to go back in that moment was the same reason students want to stick with familiar grading systems: I know how it works, I know how to communicate about it, I know how to get the best results from it, and it sticks within the letter-grading system I’ve used for 20 years as a teacher and longer as a student. I can recite all the dangers and disadvantages of letter grading, but because it’s the system I’ve known for pretty much my entire life, there’s still a certain comfort to it, and whenever things get weird or challenging or unpredictable, I get an atavistic desire to go back to what is familiar.