This is the third 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_**

**__

1. The Secret Of Being A Great Apprentice _(this post)___

2. Become A Better Developer By Indexing Your Brain

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

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

Being a great apprentice is easy. It is especially easy in software development. If you use a little bit of common sense coupled with your natural software developer curiosity, you won’t go too far wrong. It doesn’t matter if your mentoring relationship is formal or informal (see the previous post in the series), you need to do the exact same thing either way to be a successful apprentice and to get the most out of your mentoring relationship. Don’t worry though, I am not going to ‘leave you hanging’ with some amorphous advice about curiosity and common sense, we’re going to examine precisely the qualities that make a great apprentice.

Being A Great Apprentice

As a mentor you have much to consider. You are responsible for another person’s development and for charting the course of their future career. There are many things you can do well and just as many (or more) that you can do badly. As an apprentice, on the other hand, all you’re really responsible for is absorbing as much information and experience as you can. In essence, all you need to do is learn. Simple, right? Well, not really, you can stuff up learning just as easily as you can stuff up any other task. So, here are a few guidelines to make sure you don’t.

• Be genuinely interested in what you’re being taught – this is probably the most important point. There is nothing more pleasing to a mentor than seeing their apprentice get a real kick out of what they are learning. What this means is that if you’re not truly passionate about software development then perhaps a mentoring relationship is not the way to go for you. It is really tough to fake genuine interest. So, how do you show it? Listen closely when someone is trying to explain something, observe when others do the activities that you’re trying to learn. Ask questions, and I’ll say this again, ask questions, nothing will indicate your curiosity and interest more than asking your mentor to elaborate or explore a topic more deeply.
• Forge your own path – your mentor is not the only source of information out there. This point ties in very closely to the previous one. Another great way to show genuine interest in what you’re learning is to constantly be learning under your own steam. Dig deeper into the subjects you’ve been discussing, find your own information. Once you think you’ve dug enough, go back and discuss it all with your mentor. Not only will this help you crystallize the new information in your own mind, but you might also learn some helpful hints and tips from your mentor. Of course another upside of digging up stuff on your own is the fact that it is likely to generate an endless stream of questions on your part which will encourage your mentor and give them energy to keep imparting their hard-earned experience onto you.
• Respect and appreciate your mentor – this is paramount in any apprentice/master relationship. I’ve written about the value of respect before. Showing a genuine interest in what you’re being taught is one of the signs of respect, but we already have this one down. So, what are some of the others? One is being willing to follow directions without argument and experimentation. There is certainly a place for questions and experimentation in a mentor/apprentice relationship, but sometimes it is better to just do what you’re told and see what happens. People who are really great at what they do will often find it hard to explain why you need to do something a certain way because for them it is almost instinctive. But, they can show you and if you’re willing to follow directions you will usually be able to see the benefit of doing things their way. Another way is to show your appreciation for your mentor by voluntarily taking on some minor annoying and time consuming tasks that are normally the mentor’s responsibility (i.e. perhaps they need to generate a minor weekly status report, or maybe they are responsible for producing a chart of some sort etc.). As the saying goes, “Shine your master’s shoes”. We don’t have to be quite that literal is software development :), but if you can easily find a way to make your mentor’s life easier, it will go a long way towards showing your appreciation.
• Don’t allow yourself to be ignored – life often gets very busy in software development. Your mentor may have a lot of responsibilities besides yourself and sometimes, in all the rush, you may be forgotten. Don’t allow this to happen. Your mentor is not doing it on purpose, multitasking at any but the most basic level is tough for everyone. Sometimes it will be up to you to remind your mentor that you exist. Perhaps you might set up the next meeting or give them a friendly reminder as you walk by. Don’t expect your mentor to always initiate contact. And don’t be afraid of ‘interrupting something important’. When you have a great relationship with your mentor they will likely be glad to have a break and spend a few minutes with you.
• Don’t be afraid of looking stupid – this is one of the few times in your life when looking stupid will cost you nothing and is infact almost expected from you :). Too often people are concerned with maintaining appearances. It is very hard to learn without making mistakes and believe you me, it is much better for you to ask silly questions and look stupid now, then to not ask and look like a complete fool when you make rookie mistakes ‘in the wild’.
• Experiment on your own – there are times when you need to follow directions and not ask too many questions and then there are times when you don’t ask any questions and just give it a go. Your mentor can’t spoon feed you everything and just because you’re in a mentor/apprentice relationship doesn’t mean you suddenly have no will (or brain) of your own. Try things out, experiment with what you’re learning, your mentor may despair at the mistakes you might make, but they will respect your enthusiasm and desire to learn which will only strengthen your relationship further.

Is It Even Possible To Fail

It is even easier to fail at being an apprentice than it is at being a mentor. As a mentor, when you make a mistake your apprentice potentially doesn’t even know that you have stuffed up (that’s why they’re the apprentice after all), so you may get away with it once or twice. As an apprentice, when you’re stuffing up you still may not realize, but your mentor certainly will (that’s why they are the mentor :)). The danger is that you won’t know for a while that your mentor has stopped engaging with you especially if the mentoring relationship was informal. Fortunately, stuffing up is what apprentices are meant to do so you don’t need to worry about being perfect. Make as many mistakes as you like as long as you always retain two qualities:

• Curiosity
• Respect

We have discussed both of these above, so we don’t need to go over it again. Just remember, as long as you respect and appreciate your mentor and show genuine interest in what you’re being taught you will almost always be a great apprentice.

I hope that you have found this post helpful. If you have any other tips on being a great apprentice, then please share them with everyone by leaving a comment. This is the third post in the teaching and learning series, stay tuned for the next one which is titled – Become A Better Developer By Indexing Your Brain.

Image by johnnycorduroy

Have you ever worked on a really successful project, one of the rare on time and on budget ones? Did you get a reward and a lot of praise in the end? Yeah I didn’t think so. Now think back to a project where everything went wrong but through super-human efforts you were still able to get the beast into production. Any accolades for this one? My guess is you probably got a few and if not you personally, than someone on or around your team did. This seems to be a really common scenario with software projects; people who are associated with highly successful projects are forgotten while people on “death marches” (that are too expensive to cancel) are praised and hailed as heroes.

The Well-Run Project

Really successful projects are few and far between but when they do happen they are a joy to work on. Not only that, but the software delivered is higher quality and meets expectations. Budgets and deadlines are adhered to and everyone associated with the project is happy (more or less :)). Most of us dream of working on such a project. So when a project like that finishes, how does the business show it’s appreciation and express it’s desire to see more projects of the same caliber (i.e. what kind of positive reinforcement is used)? Well, everyone gets a pat on the back and then moves on to the next thing. A little anti-climactic wouldn’t you agree? You see, everyone expected the project to go well and when it did, noone was surprised, everything went according to plan, why would anyone reward or even acknowledge it when things go according to plan. That my friends is what I call negative reinforcement.

The Crappy Project

Crappy, death-march projects are routine in software development. Projects begin with unrealistic expectations, concrete commitments are made based on estimates and information that is far from concrete. And when things inevitably go pear-shaped developers cop the brunt of the fallout. We are forced to shortcut our process and compromise on quality and when that is not enough, well we just work longer and longer to make up the shortfall. At the end everybody is stressed and tired, but sometimes the gargantuan efforts are enough to get the project (or what’s left of it) into production. When that happens, we crack open the champagne and hail the project as a miracle of modern software development. Everyone shakes their heads and marvels at how the team was able to do the impossible. Awards and praises are handed out and everyone is too happy to notice that the project was actually a year late and millions of dollars over budget. I lie, everybody is well aware of the fact that the project was a complete debacle, but with so many people patting each other on the back, it just doesn’t seem politic to say anything. You would agree that this is the ultimate in positive reinforcement.

It Is A Bizarro Universe

The above scenarios strike me as being completely cuckoo. We acknowledge and praise people who try (and sometimes succeed) to pull projects out of the jaws of failure but don’t do the same for people who push project into the ‘jaws of success’.

Have you ever tried to train a dog? Next time you do, try the following. Every time a dog does something you like (such as fetching a stick or rolling over), a positive behavior – just ignore it. But every time the dog does something ‘bad’ (like peeing on the carpet), a negative behavior – give it a treat. My guess is you will quickly end up with one confused and badly behaved dog, and yet we do this on an industry-wide level. It is truly bizarre.

This Culture Needs To Change

In an industry where project going pear-shaped is the norm, it really behooves us to look more closely at the ones that don’t. I for one would love to see a little bit more appreciation from everyone for projects where things go according to plan and especially for the people on those projects. It might sound crazy but I do believe that delivering a year-long project on time while having all developers work at a sustainable pace (oh I dunno, let’s say 40 hours a week :)) deserves at least an honorable mention for the people involved.

The other side of the coin is rather than celebrating the belated delivery of the latest death-march, how about digging into it and trying to figure out why it was 6 months late and why people had to work 80 hour weeks to keep it from complete disaster. And when we do figure out what the problems were it may be worth it actually learning something and trying not to repeat the same mistakes rather than just writing it all up in a report and putting it on the wiki or in the document repository. Because wikis and repositories are just some of the places where lessons go to die.

__

For more tips and opinions on software development, teams, process and people subscribe to skorks.com today.

__Image by salimfadhley

I was reading a post today on Glen Alleman’s Herding Cats where he talked about velocity as a vector and posed a question :

What is the purpose of a velocity, if you do not know the distance to the end?

I thought I’d give a quick answer and ramble on about other related thoughts along the way :).

I agree with Glen, measuring velocity does not replace planning and scheduling on agile project, rather, having a measure of velocity can facilitate those activities. However it all depends on how much planning (if any) you actually need and there is certainly a purpose to velocity besides knowing the distance to the end.

There are basically two types of agile projects you can be involved in.

1. Deadline constrained – where you must deliver on a certain date and will include as many features as will fit.
2. Feature constrained – where you must deliver a set of features and will keep going until all of them are built.

The first kind is a lot more common then the second and even in feature constrained project people often try to impose arbitrary deadline constraints (which may or may not be a good thing depending on the environment). Let us have a look at both types of projects and what role velocity can play.

Deadline Constrained

Having to deliver on a certain date can be highly stressful. You don’t know precisely what features are going to make it into the final release and you can’t really go live without a certain feature set. Some kind of measure of approximately how long the whole thing is likely to take and what features are likely to make it would be really handy. But, at the start of the project, velocity is not that measure, infact a good measure for this does not exist. People keep trying to find one but all likely candidates are wildly inaccurate (I present to you function point counting :)) and based on assumptions that will not hold throughout the lifetime of the project. However as you keep working on the project iteration by iteration, the team will estimate the stories and as the iterations are completed you will start to get a sense for the kind of velocity that the team can sustain. The velocity and estimation process will feed off each other to allow the team to estimate stories more accurately the further along the project gets; this in turn will allow you to set some expectations as to the velocity you’re likely to get in the next iteration and even roughly pen in the velocity for a subsequent iteration or two. Although it would be folly to try to extrapolate this toward the end of the project as you will have to assume that conditions will not change (i.e. team will always remain the same, noone gets sick, features won’t turn out to be more complex etc.) and this will never be the case.

So, we are not using the velocity to plan the lifetime of the project or the amount of features we are likely to deliver. Instead the team uses the velocity to get better at estimating the features and due to this you get more and more certainty as you go along regarding the likelihood of the team delivering what they say they will (you gain more confidence in your team). This type of project requires a lot of planning. You need to make sure you’re working to a realistic schedule, you need to build in slack based on inaccurate estimates, you will need to take into account risks and having done all this you will need to adjust all this stuff constantly as the estimates improve, team conditions change etc. Doing all of this can give you some indication regarding what is and will be happening with the project and this indication will be more and more accurate the further along the project gets. As you can tell velocity is part of all this and is a very useful tool/measure, but in this case you know the distance to the end (you will finish on a certain date), what if this was not the case.

Feature Constrained

Despite what you might believe some projects don’t really have a deadline. Ongoing products that are actively developed are all about features. Sure we try to deadline constrain these as well. But when the deadline is reached, we just go on building features trying to reach the next ‘arbitrary’ deadline. These kinds of projects potentially require a lot less planning. You don’t know the distance to the end, you just keep building features while there are features to be built. The only planning you really need to do for this one, you bring upon yourself by creating the ‘arbitrary’ deadlines in the first place. Why are they ‘arbitrary’? Well, presumably your team is keeping the system in a releasable state at the end of every iteration so, you could go live any time you want if you’re happy with the feature set, so any go-live deadlines must be arbitrary :).

We don’t know the distance to the end, does that mean velocity has no value in this case? Possibly in an ideal world of some sort that might be the case, but we live in the real world. I am going to contradict myself and say that the ‘arbitrary’ deadlines I was talking about before are not really arbitrary at all. As far as the team and the system is concerned they are not necessary but the business/customer is relying on the system and they need to do their own planning based on the kind of features and functionality they are likely to expect. Therefore they need to know what features will be available and when they will be available. This is why feature constrained projects end up with release deadlines of their own, and for this same reason velocity has just as much value for these projects. It helps the team improve their estimation and zero in more or less precisely on what sort of functionality (and how much) it can deliver in an iteration (or a set of iterations). And so velocity remains a valuable tool regardless of whether you know the distance to the end or not.

Of course if your team is not using a proper estimation process, if you don’t adjust estimates as you go, if you keep taking out and putting in people, if the team doesn’t commit to their estimates – velocity becomes a meaningless number. In this case, all it is good for is looking good on a BVC (big visible chart) or BAC (big-ass chart) as I like to call them :).

Images by lrargerich and psd