Something we discussed a while back was renaming “mentoring” to “code review”. The logic is that Code Review is more accurate and gives a clearer expectation to a student of what will happen. Mentoring often signifies a deep personal relationship to people, and that feels like both a commitment and potentially overwhelming.
For example. I hear a lot of people commenting that they were just having fun learning a language and didn’t want to take on a mentor. Whereas I feel like if we said “Would you like your code reviewing” they might be much more open.
As our rate of requesting mentoring/review is currently very low, this feels like a potential way to increase the request rate.
Does anyone have any thoughts or opinions to share?
What happens in practice is probably somewhere between mentoring (a long term relationship) and code review (a quick look at how the specific piece of code is written).
And I know that we could argue what code reviews should do, but very often they are often only done as part of pull request…
I think by calling it a “code review” we could get more clicks, but perhaps less value. In my experience I’m getting a lot from mentors. They often go beyond talking about the code I have written. We engage in conversations about the solutions, the approaches, learning. I’m trying to do the same when I mentor. It takes time but is very beneficial. It goes way beyond “looks good to me”.
And we already have automatic “code review”, so I would prefer to keep the “mentoring” for the human interaction, even if in practice it is often more “coaching” than “mentoring”.
One improvement I would like to see is a way to have more stable (but non-blocking) relationships. So I start interacting with one mentor I’d like an increased chance I will get the same one in the next task, so we could continue the exploration of the language, continue the discussion. Without that sometimes I get conflicting recommendation, or see mentors putting a lot of effort into explaining to me what I have already heard from somebody else earlier that same day.
How to make it non-blocking? Perhaps you could have a time window when a request for mentoring is visible only to mentors who already interacted with you on that track? Or ability to request help from the same mentor as the last time? That could mean more commitments from mentors. It’s just a rough idea right now. But with those changes it would be much more “mentoring” than it is now. Wether it would drive more engagement I don’t know. Could you run a survey on Exercism.org and ask people why they don’t engage in mentoring?
Right now I am averse to being known as a code reviewer. That is only a small part of what I do: I also point out interesting stuff, recommend learning resources, answer questions, …
How are «have your code reviewed by a mentor» / «discuss your solution with a mentor»?
Less value on average or less value in total?
Not sure what to think of the former (it varies a lot by track); I somewhat doubt the latter. Slightly relevant: the mere addition paradox (a.k.a. Repugnant Conclusion).
To add context here btw, in v2 100% of exercises were submitted for mentoring (it was compulsary). Now it’s more in the region of 0.1%. We’ve gone from thousands per day to <100 per day.
So while I do feel like maybe having code review might mean that there are more lower quality conversations, my instinct is that there would also be more high quality interactions that currently aren’t happening as well.
I think the mentors would still be referred to as mentors regardless of this change.
I myself have avoided seeking mentorship because of the connotation/commitment so I prefer the sound of “code review”. However, to @michalporeba’s point aren’t code reviews already happening as part of the pass/fail + analyzer system?
If it’s inferred that I will gain value (as a student, I would benefit) from a human code review, doesn’t that lower the perceived value of the automated systems in place that tell me whether or not my code passes?
I feel like the change in label might be confusing, as it might feel like Exercism is using mentors to compete with itself, instead of using them to augment the learning experience.
I wonder if the low usage isn’t due to what its called, but rather where it’s offered.
I personally don’t want to seek discourse before I complete an exercise, so I probably won’t use mentorship in its current form where it’s tied to exercise submissions.
However, I could definitely see myself wanting to seek out a conversation from a mentor after I complete (or more generally, independently of submitting) an exercise, especially as I’m looking at different community solutions.
That’s the value of mentorship to me: understanding nuance, not solving the problem.
Maybe the way to drive more conversation and engagement is to decouple the feature from the pass/fail mechanic. That’d more accurately reflect the real world value of mentorship imo.
So this is very interesting. Because this is the only place it is offered. You can’t request a mentor until got the tests passing and have submitted the solution, and in fact the tab then is unlocked next to the community solutions. But clearly that’s not been your perception as you’ve been using the site, and presumably then also not the perception that lots of others are having.
I think code review and CI are very different things. CI is pass/fail, code review is “Is my code any good?” At least that how I use code review in the real world. So I agree it’s fighting a little with the analyzer system, but equally the analyzer system is largely powered by mentoring too. A lot of the feedback you get is mentors writing feedback while mentoring someone on the same thing as what you published, then converting it into automated feedback. To me the two should augment and support each other not clash. But again, I’m not arguing we’ve got that correct right now.
This is my expectation. I’ve heard this lots over the last few years and I think a lot of people are missing out on great conversations because of it (on both sides - students and mentors).
Regardless of the rename, it seems that we also need to do a better job of communicating the application, commitment and value of mentoring.
I like it. I’ve had few people walk away in the middle of a session because the things i was asking them to do were probably too much for them. They never said they are leaving. If it’s called a code review, the student knows that it’s just that and they don’t have to commit. Most of them aren’t interested in true mentorship anyway.
Mentorship requires dedication from the mentor as well, but most mentors don’t really have much time. When i was a beginner few years ago and requested mentorship, i came across someone that said that my code is good without giving any advice at all. Looking back at it my code sucked, but the mentor wasn’t even interested in giving a proper review so i assumed the mentor was right and moved on.
Short story long, calling it a code review frees both mentors and students from a commitment that never existed in the first place.
An interesting discussion with two clearly opposing views. Some people prefer low commitment (on both sides) quick code review, while others are finding values in a more in depth discussion. Could we have both? Could you either request a quick “code review” or more detailed “mentoring” session?
In fact I find myself requesting either in the comments and sometimes feeling bad for the mentors who write a lot despite me asking for something simple. Why I do this? I have started Go track yesterday. Sometimes I want to explore a concept more, because I want to make sure I understand the Go way of doing things and what happens behind the scenes. But then in other cases I’m happy that my solution works, it looks more or less like many of the published solution, but I still will ask something like “how can I make the solution look more like go”.
As for when to seek conversation with a mentor (a coach perhaps would be a better term) is not after I have solved the problem, but when I struggle. I wish there was an option that after so many failed attempts you get a popup that says “Would you like to ask one of our volunteer mentors for assistance with this exercise?” That is exactly when I would get the most value from mentoring, and when I would appreciate it the most.
I think code review allows for both levels of commitment and is better. I was hesitant to mentor cause it sounds like you need to add a lot of value to the code that you’re reviewing.
A few people have asked that their solution be reviewed as if it were a PR. So they’re looking for a code review.
And a few first-timers have expressed themselves as if they expect that the person mentoring them the first time will be their mentor indefinitely. So they are looking for a mentor.
It would be nice to increase the amount of people looking for feedback. It’s not only the students who “don’t know what they don’t know”. I still learn something new from students fairly frequently. So to have more mentees (or whatever you want to call them) would selfishly help me, too.
Having an increased chance that you will get the same one in the next task may be as simple as an ask in the exercise that you have just completed with them, by supplying a “private mentoring link” in a comment on that prior exercise.
Often just asking the question will give you the answer, and increases that “chance” greatly, rather than hoping they pick it up before someone else does.
This is supported on the platform, it just currently is not talked about (as far as I am aware of) in the content provided by the platform.
I kind of like the idea of the “non-blocking” suggestions. One of them could be an e-mail or notification being sent “One of your ‘Favorite’ students submitted a new exercise on track ‘whatever’, here is a link to accept.” kind of thing. But if it is picked up by another mentor, that is another event where we should know before we click and find that it is not available.
feeling bad for the mentors who write a lot despite me asking for something simple.
Probably no need to feel bad for that. You asked, you got more than you asked for. Pending no “it was given, I must do something with it” compulsion, which some of us have, hopefully you can choose to take what you need from it, and potentially come back later when you want more from it.
The reason to not feel bad for it, though, is I know some mentors that have been doing this long enough have “snippets” that are selectively given, based on what is there, and those snippets, while representing time of effort, are now being reused, and so require very little effort to give in the same or very similar circumstance.
I think what might be nice is having some “pre-packaged” often asked student requests at various levels, such as being able to pick:
I would like to know if my code is idiomatic
I would like to explore other ways to solve this
I would like to dive more deeply into… (Fill in the blank)
After selecting, being able to go into more free flow questions, if there are any.
I’m a bit skeptical this change will increase mentoring requests, but since I don’t have real data to back this up, I think we can just try it and see how it goes. If mentors are still called mentors and we say “get your code reviewed by a mentor”, this can attract people that are both looking for a simple code review and people who are interested in a more deep mentorship and everything in between.
The reason I say I’m skeptical about this increasing mentoring requests is because I feel the biggest decision for most people is more in the lines of “do I want to show this code to someone else or not?”. I think calling this “show your code to someone else” either mentoring or code review doesn’t really matter for some people, they just don’t want to show their code. I’d say the same happens for people who do want to show their code - if they already decided they are willing to get their code seen by someone else, I don’t see the wording affecting their decision.
Even though I don’t think the wording affects the decision someone takes regarding mentoring, I do think “code review” is slightly better at managing expectations, and it’s probably worth doing just for that fact alone.
Actually, I think there may be some somewhat “cannibalistic” mentors out there, . A fair amount of my testimonials use words like “nice”, “kind”, “encouraging”, “friendly”, etc. in a way that makes me feel that they have had encounters that were not “nice”, “kind”, “encouraging”, “friendly”, etc… Or, perhaps the interaction just went against their dreaded expectations.
