I absolutely adore Enumerable, but I don't remember everything it can do all the time. I don't feel guilty or inferior because of that. There's too much information in the world to remember all of it.
I strongly suggest reading Don Norman's The Design of Everyday Things, specifically the chapter about knowledge in the head vs. knowledge in the world. The more we have to remember, the more mistakes we make. The more we need to rely on our memory to make tools available to us, the fewer tools we're likely to use in practice. This is how humans are.
I'd posit that the fewer details we have to remember in order to code, the more we can think about the bigger questions: What are the edge cases? What are the user needs, and is this code I'm writing actually fit for purpose? Will the next person editing this code be able to understand what I wrote, or should I break down the problem in a different way?
That's the kind of understanding and productivity I want in my team. I don't care whether my teammates know what Enumerable#grep_v does without looking it up in the docs. I do care whether they know how to read a requirements document and ask clarifying questions. I do care whether they notice that a method or class is getting too big and feel the need to split it up. I do care whether they know to prioritize shipping features as a team over finishing a personal task list. There are so many things I care about more than their proficiency in Ruby (or other language) trivia.
So... different strokes for different folks?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I absolutely adore
Enumerable, but I don't remember everything it can do all the time. I don't feel guilty or inferior because of that. There's too much information in the world to remember all of it.I strongly suggest reading Don Norman's The Design of Everyday Things, specifically the chapter about knowledge in the head vs. knowledge in the world. The more we have to remember, the more mistakes we make. The more we need to rely on our memory to make tools available to us, the fewer tools we're likely to use in practice. This is how humans are.
I'd posit that the fewer details we have to remember in order to code, the more we can think about the bigger questions: What are the edge cases? What are the user needs, and is this code I'm writing actually fit for purpose? Will the next person editing this code be able to understand what I wrote, or should I break down the problem in a different way?
That's the kind of understanding and productivity I want in my team. I don't care whether my teammates know what
Enumerable#grep_vdoes without looking it up in the docs. I do care whether they know how to read a requirements document and ask clarifying questions. I do care whether they notice that a method or class is getting too big and feel the need to split it up. I do care whether they know to prioritize shipping features as a team over finishing a personal task list. There are so many things I care about more than their proficiency in Ruby (or other language) trivia.So... different strokes for different folks?