what is mentoring?

What is mentoring?  Listening?  Advising?  Helping?  I was looking for the definition of mentoring today and came across some interesting things.

dictionary.com lists two definitions:

1, a wise and trusted counselor or teacher.

2. an influential senior sponsor or supporter

These are both correct, but not very helpful to me.  Sometime later I came across an article that really expresses what I was looking for.

Mentoring is about one person helping another to achieve something. More specifically, something that is important to them. It is about giving help and support in a non-threatening way, in a manner that the recipient will appreciate and value and that will empower them to move forward with confidence towards what they want to achieve. Mentoring is also concerned with creating an informal environment in which one person can feel encouraged to discuss their needs and circumstances openly and in confidence with another person who is in a position to be of positive help to them

Parts of this initial paragraph really jump out at me.  I’ve listed the relevant keywords and phrases here with my thoughts on them from both being a formal/informal mentor/mentee:

  • helping – Why am I not surprised the first verb in the description is so critical?  Mentoring really does boil down to helping someone else.  The mentee is still responsible for themselves and everything pertaining to the situation.  Whereas the mentor gives advice/opinions/guidance to help the person.
  • achieve something – The goal might or might not be known to the mentee.  Sometimes there is a specific issue that one wants to discuss.   In that case there is a pretty clear goal.  Sometimes it’s just to hear advice on what is coming.  This is kind of vague.  For example, technical people are known for needing to improve their soft skills.  Yet we don’t tend to seek out advice on the topic.  A good mentor will bring it up anyway helping the person at least realize there is an opportunity out there.
  • non-threatening way – This should go without saying.  The idea of mentoring is to be guidance not “do this or else.”
  • appreciate and value – I found this phrase particularly interesting.  Usually I appreciate and value my mentor’s advice right away.  However sometime it takes time to sink in.  I received some advice related to answering questions about a year out of college.  About two years later, I told the person giving the advice that it finally clicked and now I understand what he was talking about!  At the time I did appreciate that the advice was given, but I wasn’t at the point yet where it could be useful.
  • empower and move forward with confidence – The mentee really is responsible for themselves and the mentor is just trying to help that person succeed.
  • discuss needs and circumstances openly and in confidence – One needs to know what’s going on to provide useful help and advice.  Yet often when we need advice, it’s because something problematic is going on or our innermost desires conflict with others.  Not the easiest thing to talk about in general.  Especially for technical people like us who are more comfortable with computers and logic.  Being assured of confidence allows one to “just talk” as if one is talking to a friend.  Sometimes that means your mentor (or one of your mentors) should be someone you know well or someone you don’t work with directly.
  • informal environment – Some environments are more informal than others.  Part of managing someone involves mentoring and providing career guidance.  This type of mentoring is extremely valuable because a manager knows more about a person’s job than anyone else.  It’s also valuable to have someone to talk to who is NOT your direct manager.  For one thing, it’s uncomfortable discussing things directly relating to your manager with your manager.  For another, no matter how much you trust your manager, there’s still a nagging feeling that the person is your manager which affects openness.  It’s hard to present an idea you haven’t thought through directly to your manager.  It’s also useful discussing things with someone else to gather more points of view.  This “other person” to talk to doesn’t need to be formally named a mentor.
  • in a position to be of positive help – There are multiple levels of help.  Sometimes a person just needs someone talk to.  Expressing ideas to someone else helps clear ones head and make connections between ideas.  This is the really basic level of help.  At higher levels of help, it advances it to making suggestions and asking questions to help the person think about solutions and next steps.

Formal mentoring tends to be easier to visualize.  As an example of informal mentoring, I talked to a collegue at JavaRanch (where I volunteer, not my “real” job) about something this weekend.  This is someone who I really respect – especially when it comes to process and team dynamics.  And with mentoring!  He asked me a bunch of questions to understand both the scenario and what I was thinking/what I wanted.  He also asked some higher level questions.  This was the most valueable thing for me.  If I had talked to someone I work with, this question would have been unlikely to come up because everyone would be thinking within the job and taking certain things for granted.  Now this is the only time I asked this particular person for advice (that I can recall.)  But I’ve absorbed so much from him over the years.  I think this shows that there is informal mentoring (“can I talk to you about this one thing” vs just learning from watching/listening to someone who doesn’t even realize they are mentoring.)

Denormalized Databases: A better example

There were a number of comments about my recent article on the negative effects of too much database normalization so allow me to expand the topic a little more. The most consistent comment I saw was that while many of you agreed with me in principle that too much normalization can lead to poor performance, the country name example was a bad choice. As a former teacher, I tend to choose illustrative examples that are easy to understand and explain. As a blog writer, I also tend to forget the web is full of nitpickers that will argue with you unless presented with a concrete example from the real world.

My favorite comment was about how in Europe a poster’s country name has changed 3-4 times in the last few years. I could argue most Americans would be shocked to see their country name or state name change, but I have to think… how hard is it to update the name of a country in a database even if it does change once a year? The trick with database denormalization is you have to write code that updates two separate sets of items, and in a lot of cases this is less difficult than many of you imagine. If updates are uncommon (static) as I mentioned, the performance gain from reading can far outweigh the rare cost of performing an update.

Perhaps its better to move on to a better example of where denormalization of data can play an important part: managing user permissions. And no, this is not to be confused with database security (which is completely useless for user/application-level permission management). Let’s say you have a tree-based system of widgets. Widgets can have sub-widgets and so on such that each widget has only one parent but can have many children. Now let’s say users within the application (again not to be confused with database users) are assigned read/write roles on individual widgets as well as to entire subtrees of widgets. For example, Bob may be able to read the entire tree, but he can only write to select widgets A, B, and C or a select sub-tree of widgets D which contains X, Y and Z. Now, how would you design a database system that allowed for quick determination of a user’s permissions on a node, considering the user may be accessing dozens or hundreds of nodes at a time, such as in a tree viewer?

Since the height of the tree is unbounded, we would need a database schema that allowed for arbitrary height. A common solution is to have a single table, let’s call it WidgetTable, with a field for the parent reference, let’s call it ParentId. Obviously, the root node would have a null ParentId. Given a node X, how do I quickly determine if X is writable? In this case, the user may have write access to X directly or through a parent node somewhere up the tree.

The most common answer, since SQL doesn’t support unlimited-recursive queries of this nature, is to query the parent and check if its writable, then query the parent’s parent and check if that’s writable, and so on until you find a writable permission for the group or you hit the root. Well, let’s do worst case asymptotic analysis on this! The worst case would be if you had one really long chain of single nodes with X being the leaf and the writable flag being on the root. In this case you need to perform O(n) number of queries where n is the number of nodes in the database. The performance of this solution in worst case could be awful.

Amortized (average case) analysis would find better bounds, but remember the earlier stipulation that you may be viewing dozens or hundreds of widgets at once? In worst case, that would be O(n*m) where n is the number of nodes in the table, and m is the number of nodes you are looking up. One of the best solutions in a situation like this is to maintain a denormalized lookup table, let’s call it UserToWidget that maps users to nodes they currently have permissions on, taking all parent relationships into account. With such a table in place (and hopefully good indexes on that table), determining a user’s permissions on a large set of nodes can be done in O(m) time, or near constant depending on the number of nodes you are looking up.

What’s the cost here? Maintaining the UserToWidget table of course! In Oracle, there are options such as materialized views which can help. You could also use database triggers to maintain the relationships anytime the higher-level permissions change. But let’s say you want a solution that isn’t database specific, which most of us do, then you could write application code that acts anytime a user’s permissions are updated, to seek out and update changes to affected nodes below the node you updated. If database reads are more common than database writes (which I suspect they are if you’re viewing hundreds of nodes at a time), the cost of performing the complex update will be far less than the cost of quickly being able to read a widget and determine its permission for a given user.

I hope this example helps to illustrate cases where pure normalization can be too costly for practical use. If not, try reading it again 😉