I’m with Andre here - I am skeptical that a rename will overcome what Matthijs gets at - there are a significant number of people who are hesitant to share their code (or don’t feel the need to for whichever reason).
“code review” feels very judge-y to me, and may or may not discourage people. It all depends on their perception of (and experiences with) the term.
But testing a rename out would at least give us data.
Some other “names” that come to mind:
Get a critique from a mentor (again, judge-y)
Get a review from a code coach (I don’t like the sports metaphor, but it feels friendlier)
Part of Exercism’s take on the exercises is to gain fluency in a language. One of the areas that a “student” of the track may lack is what kind of things in a given exercise lends itself to such a fluency.
Every excercise, including TwoFer or Gigasecond which are usually easy (compared to later exercises, at least) to solve, can give a chance to really explore the fluency aspect, as the problem is simple enough that exploring the language itself does not combat against solving the problem given.
The practice exercises are for practice, and if you believe you got enough out of it, that is fine, really. But I think sometimes we short-change ourselves by not reaching out and saying “Is there anything that I am missing here, other ways that I can explore the language given this exercise? Are there some choices I made without realizing, maybe, that I even had a choice?”
I am a struggler: to me ‘code review’ sounds terribly intimidating. It’s what proficient, equally competent coders do amongst themselves because no one’s perfect, no one has all the possible enhancements figured out, all the traps avoided. I think that we strugglers need guidance – mentoring, coaching, teaching, not ‘code review’. But others here, dabbling in their 14th language seem a bit insulted at the notion of someone ‘mentoring’ them. Perhaps one asks for ‘code review’ in practice exercises, ‘mentoring’ when in ‘learning mode’? I also feel that allowing mentoring only for passing code excludes the casual struggler who might not even know what the ‘command line’ is, but might become a serious student with a little bit of good mentoring; I like to think that ‘Exercism is for everyone’
What about some A-B testing? Compile a list of phrases (“Request mentoring”, “Discuss code with a mentor”, “Request code review”, etc) and see which randomly selected phrases gets the most results? Or is that asking too much?
While we are on this topic, I wanted to ask about the right time to ask for mentoring. Initially I would submit the request for mentoring as soon as I finish an exercise. Then I would head out to community solutions and start reviewing them. For many of the mentoring requests, the suggestions made by the mentors were already covered in the community solutions. So, I did not feel that they added much value.
Then, I tried reviewing the community solutions and for many of the exercises, I felt I got what I wanted, but still I submitted for mentorship and I did not get any meaningful feedback from my mentors.
But there were other cases where I had engaged in a long conversation with a mentor and found it very enriching. But most of the mentors I got did not provide any meaty suggestions - so, I am wondering how to strike a balance between community solutions and learning on my own and using a mentor? I would appreciate your thoughts on this.
As a mentor, I am just as happy to receive requests of the form
I am content with my own solution, and I see X, Y, and Z in the community solutions and that all makes sense to me. The only question I have is: is there anything else to this exercise that I might find interesting?
Such requests are appropriately easy to handle: if there isn’t then the answer is “Nope, you’re good!”, and if there is then I can elaborate liberally.
If you suspect another mentor might have something interesting to say, you can resubmit your request.
It seems like there are plenty of good reasons for and against rebranding mentorship. Does this have to be a binary decision? What about adding a manual code review option? It could feed into the current mentoring pipeline. Keep code reviews brief and mentoring as is. Hopefully, this solution would keep the people who like mentoring and add those people who would prefer code review.
Adding some nuance to what being mentored means might open the door wider for those hesitant to engage in what they may perceive as a mentoring relationship. Suppose we offered a menu of typical mentoring questions and maybe an indication of what to expect with each option. In that case, those who don’t feel worthy or aren’t initially trying to become an expert might be more inclined to make the request.
@IsaacG Probably asking too much I’d like to, but realistically it’s more time than I have right now.
@siraj-samsudeen Good question! I agree with what @MatthijsBlom said. I think it’s probably always ok to ask the question and see what happens. A big point of mentoring is that we don’t know our own knowledge gaps so sometimes someone will see something in our code that we haven’t noticed ourselves. But also, sometimes the community solutions do a great job in showing us those things ourselves. The big question I’d ask is “Why did you not think of the perfect solution yourself?” - writing the code eventually isn’t the key thing, it’s about thinking in the correct way in the first place, and so maybe working with mentors to help determine how you can think more idiomatically is the key thing here.
We’ve done two things:
Added a feedback tab to the editor where automated feedback and mentoring both appear. This is useful for being able to reference feedback once a mentoring session is in progress (and is the foundation for some other improvements coming soon). It’s also another opportunity to nudge someone to improve their code.
Changed some of the labels to say “Submit for Code Review” rather than “Request Mentoring”. Let’s see what happens and we can change it back after a while if we don’t think it helps. “Mentors” are still “mentors”.
I also strongly agree with the opinion that code review should be mentoring. I’d argue that code review that doesn’t include useful discussion or mentoring isn’t being done well (and is effectively just a second line of CI). Code Review IMO should be an opportunity for a discussion about how best to solve a problem and write code, not an exam-marking exercise. So I’m happy to use this language here, at least as an experiment
This stuff will be rolling out in the next day or two. Thanks to everyone for contributing to the discussion. It’s been very helpful to read.
Under 1% of people submitting exercises request mentoring. Despite us plastering it everywhere offering it them for free, emailing them about it any more. So clearly there’s some sort of huge disconnect between the people craving it, and the people requesting it.
Often though, disconnects like this are based in lack of clarity about a process, fear of failure/rejection, or similar. So us focussing more heavily on telling people it’s safe and easy is probably the first way we should start. I suspect “Code Review” as a concept makes the process immediately clearer and therefore might lead to an uptick. But it might not and we might need to focus more heavily in other ways!