I saw a post the other day about the rules of standup. It was a nice basic introduction, but I find that I have something to add (what, me have an opinion on stuff, you don’t say :)). It is true, standup is one of those agile practices that has become pretty much universally adopted, even by non-agile teams (even by non-software teams). It has a lot of appeal, forcing people into a little bit of discomfort to keep a status meeting short and to the point. But, aside from the danger of standup becoming routine, there is also another thing to watch out for, especially for large teams.

Whenever a team gets past a certain size, no matter how little each person says, the whole standup can take a while. And yeah I am aware of the fact that ‘agile teams should be around 7 people’, but lets face it, in the real world agile teams can be much smaller or much bigger than that. The reason that a standup takes so long for a large team is because everyone has to talk. But of course everyone has to talk, it’s one of the rules, we all need to say:

• what we did yesterday
• what we’re going to do today
• and what is impeding our progress

it’s what all good agile teams do. The thing is, everyone doesn’t need to talk. What if you’re pairing, do both halves of the pair need to say the exact same thing? What if you’re working on a really long task (longer than 2 days), do you really need to keep repeating yourself day in, day out? What if you’ve been asked to work on something unrelated to everyone else for a little while, do they need to know?

The answer to all of those is no. The problem is, if you say nothing for several days in a row people are going to think you’re doing nothing.

Right?

Wrong!!!

One of the key tenets of agile is trust. Your manager has to trust the team to do the right thing, and the team members trust each other as well. Don’t turn your standup into a forum for everyone to try and prove how important they are to the team.

One of the standup rules that we have adopted where I work is this:

You don’t need to justify your own existence!

You only talk at the standup if you have something relevant to say, otherwise just keep it moving. If you’re doing the same thing as yesterday, say so and keep it moving. If you’re on something unrelated for a while just say that and keep it moving. If your pair has already spoken – you guessed it, just keep it moving.

If your people all need to talk at standup to prove how busy they are, then you have big issues. Develop some trust within your team, don’t use standup to justify your own existence.

Image by Donnie Brasco

Every expression and every object in Ruby has a boolean value, which means that every object and every expression must either evaluate to true or to false. This makes true and false rather special values. But, they are not just empty value or simple keywords, just like with everything else, both true and false are Ruby objects.

The True And False Objects

You’re probably aware that true and false are reserved words in Ruby which means you can’t use them as a variable or method name. But both true and false are also fully fledged objects. Ruby has two special classes called:

TrueClass

and

FalseClass

and the objects true and false are the only instances of these classes. Infact Ruby won’t let you create any more instances of these classes, you can go ahead and try e.g.:

irb(main):001:0> true.class
=> TrueClass
irb(main):002:0> false.class
=> FalseClass
irb(main):003:0> p = TrueClass.new
NoMethodError: undefined method `new' for TrueClass:Class
        from (irb):3
irb(main):004:0> q = FalseClass.new
NoMethodError: undefined method `new' for FalseClass:Class
        from (irb):4
irb(main):005:0>

But what about every Ruby expression evaluating to either true or false? Well, every Ruby expression evaluates to an object and every Ruby object in turn can be used in a conditional statement which means every object ultimately must evaluate to a boolean value. You can test this out on your own:

irb(main):001:0> if :hello
irb(main):002:1>   puts 'the boolean value of a string or symbol object is true'
irb(main):003:1> end
the boolean value of a string or symbol object is true
irb(main):004:0>
irb(main):005:0* if 5
irb(main):006:1>   puts 'the boolean value of an integer object is true'
irb(main):007:1> end
the boolean value of an integer object is true
irb(main):008:0>
irb(main):009:0* if !false
irb(main):010:1>   puts 'the boolean value of false would have been false'
irb(main):011:1> end
the boolean value of false would have been false
irb(main):012:0>
irb(main):013:0* if nil
irb(main):014:1>   puts 'nil can\'t be true'
irb(main):015:1> else
irb(main):016:1*   puts 'the boolean value of nil is false'
irb(main):017:1> end
the boolean value of nil is false
irb(main):018:0>
irb(main):019:0* if def method; end
irb(main):020:1>   puts 'can\'t end up here'
irb(main):021:1> else
irb(main):022:1*   puts 'a method definition evaluates to false'
irb(main):023:1> end
a method definition evaluates to false
irb(main):024:0>

You can keep trying this with any Ruby expression or object and you will always be able to use it in an if statement. You can also prove that the true and false values you get are always the same object (i.e. the same instance of TrueClass or FalseClass), just ask the objects for their id, you will find that the id will always be the same. More than that the object id of false is always 0 and the object id of true will always be 2:

irb(main):001:0> true.object_id
=> 2
irb(main):002:0> false.object_id
=> 0
irb(main):003:0>

So, the lessons we learn from this are as follows. Every expression in Ruby evaluates to an object and every object has a boolean value. The boolean values are always the same instance of the TrueClass and FalseClass classes and will therefore always have the same id. Most objects in Ruby will have a boolean value of true. Only two objects have a boolean value of false, these are the false object itself and the nil object.

The Nil Object

The nil object is another special one in Ruby. That’s right, this one is also an object and not just a keyword. You can probably guess this after the previous section, but the nil object is the only instance of a special Ruby class – the NilClass. I’ve already mentioned that nil is one of the two objects (many expressions can have a false value, but the only two object to have a boolean value of false are nil and false) that have a boolean value of false in Ruby.

Just like with true and false, every nil you use in your Ruby application will be the same instance as you will find out if you query it’s id. The id of the nil object is always 4 (don’t ask me why, I have no idea :)):

irb(main):001:0> nil.class
=> NilClass
irb(main):002:0> nil.object_id
=> 4
irb(main):003:0>

The really interesting thing about the nil object in Ruby is the fact that it can act like a bit of a Null Object (as in the pattern) out of the box. The nil object already comes equipped with some methods for you to use so that you don’t get pesky inconvenient errors if you accidentally end up with a nil object as a result of executing some code. For example, you can try and convert your nil object to a string or to an integer and it will give sensible values:

irb(main):002:0> nil.to_s
=> ""
irb(main):003:0> nil.to_i
=> 0
irb(main):004:0>

But due to the fact that you can always add methods to object instances in Ruby and the nil object is always the same instance, you can decorate your nil object with any interesting method that your code may need, to be able to treat nil like a Null Object, e.g.:

irb(main):001:0> def nil.quack
irb(main):002:1>   puts 'Quack, quack, quack, can\'t make pate out of me, I am nil'
irb(main):003:1> end
irb(main):004:0> nil.quack
Quack, quack, quack, can't make pate out of me, I am nil
irb(main):005:0>

Now if your code is playing with objects that quack like a duck and you end up with a nil instead of a DuckLike object, your nil object will be able to quack a sensible default value (or raise an error if you prefer).

I think this is pretty powerful stuff. A basic pattern built right into the language, you just need to take advantage of it. Speaking of converting things to string or integers, I’ve been meaning to have a look at the various conversion method in Ruby which I will most likely do very soon. As well as that I’d like to take a glance at object comparison, some interesting things you can do with strings and then dig into collections and enumerables, so stay tuned, we’re going to be getting our Ruby expertise on (if rappers can turn phrase like that then so can I :)).

Image by pittaya

This is the second post in the teaching and learning series. The teaching and learning series includes the following posts:

1. All Developers Should Know How They Learn Best

2. _The Secret Of Being A Great Mentor _(this post)__

3. The Secret Of Being A Great Apprentice

4. Become A Better Developer By Indexing Your Brain

5. Learn More – Faster By Using The World-Wide Community

6. What Playing Cards Can Teach Us About Ramping-Up And Transferring Knowledge

Mentoring in software development is unlike your regular corporate mentoring program, or at least it should be. It is not about having a coffee together every 3 months or some general advice about ‘improving your career’, it is about genuinely sharing your knowledge and experience and helping a younger developer become a better craftsman. There are two types of mentoring relationships you can find yourself in:

• informal – you find yourself working with a more junior developer and ‘take them under your wing’, you did not formally discuss it with each other, but you decide to look out for them, help them our and teach them some of what you know. They may not even be aware you’re mentoring them, infact you may not even be consciously aware of it either.
• formal – this doesn’t necessarily mean company sponsored (although it can be), what it does mean is that you both sat down and discussed it and have agreed that you will become a mentor to your more junior colleague for a period of time. You will once again help, teach and look out for them, but you’re both fully aware of the fact.

Regardless of whether your mentoring is formal or not you want to make sure your mentee (or apprentice if you prefer) gets the most benefit from the relationship. There is no one thing you can do to be a great mentor, rather it is a matter of doing a lot of little things and doing them consistently and well.

Being A Great Mentor

The first thing to remember when it comes to being a mentor is the fact that you’re in it for the long haul. In software development (like most other professions I would imagine), it takes time for knowledge, skills and experience to stick. So, it would be tough for you to be a great mentor if you only decide to do it for a couple of weeks. You would be better of erring on the side of ‘too long’ rather than ‘too short’, as a guideline, especially in a formal mentoring relationship, you want to commit for at least a few months (12 or more if possible), the longer the better for you mentee. At this point it becomes a matter of following a set of guidelines (mentoring patterns if you like), to make sure your mentee gets maximum benefit from your relationship (making you a great mentor in the process :)).

• Reduce the feedback cycle – just like in projects, it is important to take stock of where your mentee is as often as you can, so that you can adjust the course if necessary, this is why it is important to meet and discuss you mentee’s progress as often as possible. You don’t steer a ship by setting course and going to sleep, you watch where you’re heading and make small adjustments as you go.
• Set expectations early – make sure you set the expectations for the relationship early, obviously this only applies in the formal case. Your mentee might only want help with their technical skills, or they might want help with everything in general. Talk it over and stick to the expectations once you’ve agreed on them, you don’t want to steer your mentee somewhere they don’t want to go.
• Don’t assume knowledge – more experienced people often make this mistake, they assume a lot more knowledge than the mentee actually has. This often comes from an attempt not to condescend, which is admirable, but if you end up talking right over the head of your mentee it leads nowhere. The simplest thing to do is to ask if the mentee has some familiarity when you’re exploring a new area. After the first couple of times you do this, it will become a natural part of the relationship and neither of you will notice this any more. The benefit is that your mentee will not end up with major glaring holes in their knowledge that could have  been easily corrected.
• Don’t lord your knowledge and experience over your mentee – the other side of assuming knowledge is lording your skills over your mentee. You may be understandably proud of your knowledge and experience, but don’t throw it in the face of your mentee. Treat your knowledge as a natural extension of you, it is just there, no need to get into it too much. If your mentee is impressed with your experience that’s fine, take the compliment and move on with what you were doing.
• Share freely – this one is the third side (i love 3 sided coins :)). Don’t hoard your knowledge or make it needlessly complicated for your mentee to understand it. Share and explain as simply as you’re able, few people are able and fewer are willing to do this, your mentee will appreciate it.
• Listen, explain and guide, don’t direct – you’re a mentor, not a drill sergeant. Don’t tell you mentee to do things, your job is to explain, help and guide, let your mentee make their own choices and use the knowledge and skills that they gain in whatever way they see fit.
• Set goals and lay a path to achieving them – this is related to setting expectations, which is the long term goal of the relationship. You will also need to set some milestones on the way to achieving the expectations. These will be shorter term goals for you and your mentee to work on. This will keep the mentoring relationship from just drifting and marking time.
• Be proactive – your mentee doesn’t necessarily know where they need to go next (they may be too junior, and anyway this is why you’re there in the first place). Don’t wait for your mentee to tell you what they want to learn next, be proactive in suggesting where they may wish to go. Once again don’t force them down a particular road, but do give a list of options.
• Don’t seek direct benefit – mentoring a more junior colleague is your way of giving something back to the software development industry and doing something for the community. Don’t seek to gain direct benefit from the relationship. You will gain plenty of indirect benefits such as not having to work with half trained people, improving your teaching and interpersonal skills as well as making a significant positive impact on someone’s life, that should be more than enough.
• Make yourself available – even when you’re not directly engaging with your mentee, make sure you’re available for questions when needed.
• Give the benefit of your experience – sometimes it is not just about gaining new skills or learning new technologies, war stories can be really helpful. Remember that you’ve been there and done that while your mentee has not, share some of these stories (situations and how you dealt with them and how you could have dealt with them better, when it is appropriate to use certain technologies and when it is not etc.).
• Keep pointing them in the right direction – you will not always be there to guide and teach, your mentee will want to (and will need to) learn on their own. It is your job to point them in the direction of what they should be learning so that they don’t waste their time. Once again remember to guide rather than direct.
• Allow them to borrow your authority and trust if necessary – you probably have a large network and some good relationships while your mentee does not, help them remedy that. Share some of your network and your relationships with them. Introduce them to some people you know, help them to build up their own network. You mentee will probably appreciate this above anything else you can do for them and if you truly think well of your mentee (why would you be mentoring them otherwise) you should be happy to connect them with other people you like.
• Push them forward if you can – it is not about fast tracking your mentee’s career (to CEO and beyond) this is not the kind of mentoring we are talking about. But if both of you want to do that and you’re in a position to facilitate then by all means try and push your mentee’s career forward.
• Confidentiality is the order of the day – always treat what your mentee tells you in strictest confidence (this should go without saying).
• It is not just about technology – there is more to mentoring than just technology (unless you agreed to keep it strictly in technology land). You can also mentor them in people skills, interpersonal skills, conflict resolution, professional morals/ethics etc. Chance are, if the mentoring relationship is truly successful you will come to share a common ethical/moral framework when it comes to your profession.
• It is not strictly about teaching and learning – having a few beers and just shooting the breeze once in a while is never a bad idea. Ideally your relationship might grow from mentor/mentee to trusted friends over time.
• Give them the benefit of working with you directly – this is easy if you’re already working together but even if you’re not there are ways to make this happen. Perhaps you might try to collaborate on an open source project or simply get together for a coding session once in a while. The best way for them to learn is to see you do your stuff and have you there while they try to do theirs.
• Be a great listener – sometimes all you mentee will want is someone to vent to, since they know you will treat what they say as confidential.
• Provide positive reinforcement – so many people forget to do this. It is really tough to gauge your own progress and your mentee may get discouraged once in a while (we all do), you can really help by providing some positive reinforcement and really putting their progress in perspective for them.
• Don’t commit to mentoring more than 1-2 people at the same time – it is basically impossible to keep this up and still provide the level of quality support that a mentoring relationship should have.
• Get them to the point where you no longer need to push knowledge – once you find you no longer need to point your mentee in the right direction and they tend to pull knowledge from you rather than you having to push knowledge to them, you know you mentee is at a point where they have gained pretty much all they can from a direct mentoring relationship.

Surefire Ways To Fail

Just like there are patterns that can help you be a great mentor, there are also mentoring anti-patterns that can help ensure you’re a great failure as a mentor. There aren’t many of these, but unlike the mentoring patterns where following even some can make you a really good mentor, any one of the anti-patterns can destroy a mentoring relationship.

• Neglect the relationship – if you don’t keep in contact with your mentee regularly and help them adjust their course, then you’re not really being a mentor and they will not think of you as such. You mentee will try to forge their own path and you will only be a mentor ‘on paper’.
• Not keeping confidence – as you would expect this is the fastest way to stop a mentoring relationship in it’s tracks. If you don’t keep confidence, your mentee will not be able to trust you and therefore everything you say is suspect (as far as they are concerned), there is nowhere for a mentoring relationship to go from there.
• Not sharing common moral/ethical grounding – it is really tough to mentor someone when they think completely differently from you regarding issues you consider important. For example if they feel it is ok to step on people on your way to the top while you consider that reprehensible. If you find that you and your mentee are fundamentally different in that regard (morals/ethics) it is best to terminate the mentoring relationship.
• Being too overwhelming and controlling – don’t try to impose your will on your mentee. You’re not trying to build a carbon copy of yourself nor should you try to live vicariously through your mentee. Always remember your job is to help and guide not direct and control.

I hope that this post has helped you gain more of an appreciation for what a mentoring relationship should be like. If you have any other patterns for being a great mentor, do share them with everyone. In the meantime I wish you luck in your own mentoring endeavors. The next post in the teaching and learning series will be – The Secret Of Being A Great Apprentice, be sure to subscribe to my feed if you don’t want to miss it.

Image by chasing butterflies