How to: Code Reviews

I did a presentation on Code Reviews to the rest of our development team this morning, so I reckoned I might as well share the contents here :)

So, what's a code review?

Here's wikipedia's definition:

A code review is systematic examination (often as peer review) of computer
source code intended to find and fix mistakes overlooked in the initial
development phase, improving overall quality of software and can also be used as
a tool to better develop skills at the same time.

I actually think that's an awesome definition, but rather long winded. Here's the 'Jo Translation':

Somebody looking at your code and finding your stuff-ups – you might even learn
something!

There's a few other things that stand out in my mind as defining code reviews:

• They serve as a 'consistency check' over a project - making sure we're all doing things the same way, and following what a colleague of mine likes to call the 'design vision'.


• They're one way to make sure that someone else has a vague idea of how your code works - making sure that the project will go on even you get hit by a bus tomorrow morning.


• They're a chance to raise any issues or concerns you have - one-on-one time with your team lead, make the most of it! "I'm not quite sure how to approach this...", "Is there a better way to do this..." or even "I'm feeling really stressed right now"


• They're a learning opportunity, not just for the reviewee, but the reviewer as well. There have been a number of occasions when I've been reviewing someone else's code and have really liked the approach they've taken to accomplish something complex.

How do you do a code review?

If you can't review everything, start by figuring out what is most important to review - functionality which is critical to the system or code which is particularly complex. Once you've figured that out, sit down with the reviewee and get them to walk you through (and talk through) the code in question.

I think the easiest way to do this is: get them to close all open files in the IDE, collapse all projects in the solution view and then go through things one at a time. I know it seems petty, but it keeps things really clear and forces you to go through things sequentially and not jump around. Sometimes the very act of creating a 'blank canvas' like that puts the person into 'review mode' and can help prevent things degenerating into a simple chat about where things are at.

I'll usually try to track through a particular piece of functionality, which means that reviews tend to start at the UI and track back through the layers. "The user clicks this button, which fires this event, which is handled by this, which calls this, which goes to this web service..."

I can't over-emphasise the importance of talking through code at this level. Have you heard of the 'Teddy Bear effect'? Apparently the name comes from a university who once put a teddy bear near the help desk in the computer science labs. Students had to explain their problem to the teddy before they could ask the tutors about it. Why? Because the teddy often solved their problem.

I remember one particular student from my time as a lab tutor who would frequently come up and tell me at length about some issue he was having, only to finish with "Oh, yeah. That'll work. Thanks!" All without me saying a word...

There's something about putting the inner workings of code into words that forces us to really think through what it's actually doing, as opposed to what we think it's doing.

Anyway, back from the tangent. When reviewing code, start at a high(ish) level of design (i.e. method level) and look for things like:

• Any un-necessary duplicated code, indicating something that could be abstracted out


• Error handling


• Glaring security holes


• Unit tests - not just that they exist but that they actually cover something of value

Ask questions: Can that ever be null? What if the web service is down? Does it handle leap years? What if...

Then check for lower level bits and pieces:

• Adherence to coding standards


• Readability


• Consistency


• Commenting


• Hard coding (there shouldn't be any!)


• Sensible' code - i.e. nothing that could end up on The Daily WTF

You can also check things like logging, auditing, concurrency, performance, data sensitivity, caching, you name it. If you can think of it, and it's important to your project (or is your pet peeve) and is checkable quickly: check it. Why not?


Do code reviews early and often. They're especially important at the beginning of a project (or with someone new to the team) when you're still establishing your 'vision'/approach/whatever. Also, make sure they're done before you release anything! There are two ways to decide when to do them:

• Schedule a review regularly - this is what I do. I use weekly for most people, fortnightly later in the project and twice weekly for new grads or anyone I'm concerned about.


• Review whenever someone tells you that a task is 'done'. I haven't tried this myself yet, but an experienced colleague recommended it and I like the idea. Might try this on a future project :)

Make sure that your code review time gets included in the budget right from the start. Half an hour per person per week is probably fair - it will be more than that at the start but less at the end of the project so should average out nicely.

Why bother with code reviews?

Hopefully by now this is obvious... but just to recap:

• We're all human, we all miss things and make mistakes. A code review can pick up some of those before they hit anyone else.


• Code reviews help solve the 'our critical person got hit by a bus' problem because someone else has an idea of how your code works.


• They help ensure consistency over a project, which helps make maintenance easier, which drops the cost of maintaining software, which makes your clients happy.


• It's a great learning opportunity for both reviewer and reviewee.


• When they're done right, code reviews improve software quality enormously.


• A scheduled code review provides and opportunity to discuss any issues or concerns.

That last point has been really important to me lately - trying to lead a team of ten developers it has been hard to keep on top of where everyone is at. Scheduled weekly code reviews gave me some quasi-uninteruptible individual time with everyone to catch up and make sure everything is going smoothly and there are no road blocks I need to deal with. Since this project has been more than a little hectic it also gave me time to just sit with the team to soothe or encourage and keep things moving. Invaluable.

How do I get me one of those?

If you're a team lead and aren't doing code reviews right now - start.

If you're anybody and aren't getting your code reviewed right now - go bug someone. Your team lead is a good candidate if you have one, but if you don't, pretty much anyone will do. It doesn't have to be someone more senior than you, although more experience does help. The only real criteria for a reviewer are:

• Someone who is willing to give you advice - i.e. they're not too scared of you and aren't just going to say "That looks fine... You're so wonderful... Please promote me now..."


• Someone whose advice you will listen to - you need to respect them enough to take their advice seriously and be willing to change your code as a result.

And that's it... happy reviewing :)

Perceptions of Quality

Quite some ago Intergen's Development Steering Group (DSG, a small group of senior developers/architects) went on a 'retreat' to discuss issues affected the development team as a whole and plan some strategy. Among the items up for discussion was the issue of quality - how to achieve it, and, in order to decide that, what on earth quality actually is.

You might be thinking: "That's easy. Quality is making something good" which is all very well until you are asked to define what makes a piece of software 'good'. Is it that the code is well written, well documented, that the design is clean, tidy and understandable, that the GUI looks pretty, that the GUI is easy to use, that the system meets user requirements? All of the above?

What the DSG guys did was to take a list of eleven fairly well-accepted aspects of software quality and rank them - not at all an easy task but one that generated lots of discussion. Ranking was done by a combination of a client's view of quality and a developer's view. While the client view tended to trump all (we are a consulting organisation after all) considerations such as the ease of updates/fixes also came into the equation. Here, in alphabetical order, are the aspects they tried to rank:

• Conciseness
• Consistency
• Efficiency
  
• Maintainability
  
• Portability
• Reliability
• Security
  
• Structuredness
  
• Testability
  
• Understandability
• Usability

Before I tell you how they ranked them, let me add another interesting piece to the puzzle. After the DSG retreat, the same list was given to a group of less senior team leads (which is where I come in) and we ranked them ourselves before we saw what the DSG had decided. The resulting rankings were similar, but not entirely in agreement.

The DSG guys are more experienced, but generally far less hands-on than the Team Lead group. The Team Lead group is also generally younger and less experienced; and therefore completed their training more recently. DSGers usually work at a high level on many projects at once, providing guidance and support; while Team Leads usually work in-depth on one project at a time, dealing with the day to day issues of the team.

So... without any further suspense, here are the results:

			DSG		Team Leads
1			Security		Security
2			Reliability		Reliability
3			Usability		Usability
4			Portability		Testability
5			Understandability		Maintainability
6			Efficiency		Portability
7			Maintainability		Structuredness
8			Testability		Understandability
9			Structuredness		Consistency
10			Consistency		Conciseness
11			Conciseness		Efficiency

We obviously all agree that Security, Reliability and Usability come out on top without too much bother. In our discussion we had next to no difficulty with those three being at the top, in that order. It was a big jump down in certainty to number four - and that's where we start to see differences.

The Portability/Testability disagreement at that point is one we spent some time discussing. We thought it related mostly to a difference in perspective. The DSG see a variety of projects and are usually called in when something goes majorly wrong. Since deployment can easily go wrong, and is urgent when it does, I wouldn't be surprised if those guys see a lot of deployment issues. Also, when looking at a high level timeline of a project (or an iteration), deployment stands out as it's own phase so its importance is highlighted: Plan, Build, Deploy. Team Leads, on the other hand, tend to spend most of their time trying to get things built and resolving issues. Since Testability makes getting something built and stable enormously easier, its importance is clear.

I can't help but wonder if there's a little bit of a generational difference in there too - Test Driven Design being still a recent-ish concept, the Team Leads may have formally studied unit testing at least a little (I know it was part of my university courses, at least) while the DSG are less likely to have done so. Just guessing here.

I find the difference in where we place Efficiency interesting too: sixth for the DSG, simply last for the Team Leads. Why? I know efficiency certainly seems important when looked at on the surface, so placing it last, at first glance seems strange. However, when we (the Team Leads) were discussing our rankings, each time we compared Efficiency to one of the other aspects we came to the conclusion that Efficiency was something that could be added in later. Perhaps even added in relatively easily if everything else had been done right - reliable, testable, understandable, well structured, consistent code being easier to optimise. On the other hand, if you got the rest wrong, well, good luck getting it to be efficient! And would it still be efficient if it ran fast but it took six months to make a change? I don't know what discussions took place for the DSG, but that was our train of thought at least.

One last point I'll pull out - both groups ranked Consistency and Conciseness low (and both in that order). Obviously we all love consistent and concise code, and I hope we all strive to write it, but, at the end of the day, the other aspects did seem more important. If the code is structured well (so you can find things), and understandable, and maintainable (you can make changes in one part with breaking the others), and there are good unit tests... does it really matter if the naming or style is not entirely consistent or if some things are rather verbose? It would be annoying I'll grant you, but not critical.

To a certain extent the discussion of rankings is academic - all eleven aspects are really important and we should be trying to ensure our projects have all bases covered. However, pulling out what we believe to be most important can help us to focus and to ensure that we don't get caught up in something relatively minor and forget what really matters. I also think it's a great discussion-starter to get people talking about quality (which we all should be) and also about the different perspectives we can have that cause us to value different things for different reasons.

What do you think?

Professionalism

We've had some discussion at work lately about professionalism and a manager posted an interesting list of 'attributes of professionalism' which I thought was worth looking at (the list is taken from a book called True Professionalism by David Maister). Some attributes on the list are pretty straightforward - taking pride in your work, showing initiative and being a team player for example - but others tend to be talked about a little less and I'd like to pull out some of those here.

Do whatever it takes to get the job done: don't watch the clock
Many people are accustomed to being paid by the hour throughout university so the switch to a salaried role can be challenging. There's a shift in thinking required from "I am being paid for X hours work" to "I am being paid to get this job done". One of the realities of software development is that there will be crunch times where 40 hours a week may not be enough (although hopefully projects will be managed sufficiently carefully that this happens only occasionally). There will often be business objectives and deadlines that cannot shift to meet technical realities and, at the end of the day, it just needs to be done.

Be eager to learn the business and roles played by those you serve
This is an interesting one I hadn't thought of specifically but which I can relate to - especially in a software development environment. A developer who is willing to really get to know and understand the business and users of the application is going to do a far better job than one who works from the assumption that the world is populated entirely by developer-type-folk. In addition, clients will pick up on and respond to a genuine desire to understand where they're coming from and will appreciate working with you. This ties in very closely with the next one:

Understand and think like those you serve so you can represent them when they are not there
This is, again, especially true in a software development context. If you understand the business context well enough to be able to represent the clients needs at internal meetings (including the meetings you hold inside your own head trying to make decisions) the resulting software is going to line up much more closely to what is going to make a difference for your end users.

Accept criticism constructively: be eager to learn and develop
This is not often thought of as an attribute of professionalism but, if you think about it, it's actually rather crucial. Willingness to learn comes with a desire to be the best you can be and to do your job as well as you can - which pretty much sums up the entire list! Accepting criticism is always hard - I certainly struggle with it! - but it's usually the best way to improve what you do. Look on it as an opportunity :)

Get involved and don't just stick to your assigned role
Not just valuable to the client/project but also a great way for you to expand your knowledge. The broader your knowledge base the more helpful you will be able to be and the quicker things will be able to get done (since there's no need to wait for the one person who knows about whatever it is). You do need to be careful though as some people will see your 'getting involved' as 'stepping on their toes' or 'trying to take over'. Try to hit a balance and ensure every member of the team is still clearly valued.

Be observant, honest and loyal
Lots of things to talk about in there... but mostly pretty obvious. Being observant relates closely to taking initiative - see what needs to be done and go do it. Honesty is critical to earning respect and trust - especially from clients. Remember that sometimes honesty means being willing to tell them the bad news and not trying to hide or gloss over it. Loyalty could be interpreted many ways... not having read the book I'll interpret it as not going behind anyone's back, protecting and supporting the members of your team and backing up your management in public even if you disagree in private.

Finally, the last point in the list really sums up the entire thing:

CARE

In need of people

Intergen now has its own blog (with a post from me, which is a little scary!). I'm thinking it will be an interesting one to watch - should have posts from a variety of people on a variety of topics but generally covering the organisation/industry wide type issues that I find interesting.

That's my plug for the day :)

We've had some interesting discussions around work lately around the male:female ratio in IT and whether it needs changing; following on from my previous blog posts, the post from me on the company blog and our recently acquired membership to Women in Technology (WIT). One conversation (which went on for an hour!) with a couple of other women was particularly interesting. I was asked: "So why do we need women? Do we actually have anything in particular to offer other than numbers?" and it was also pointed out that "The IT industry just needs people". True. And, I think, exactly what I've been trying to say.

I'm aware that there's a fine line between helping things shift equality-wise when they need to, and making too large a fuss that only creates new problems and I want to make very sure I'm clearly on the right side of the line. So, in the interests of clarity and not being lynched, here's a quick summary of where I stand:

The IT industry needs people to work in it but, for some reason, half the population are far less likely to than the other half. There's no particularly good reason why this difference should exist to this degree so, as far I'm concerned, it shouldn't. But, it does, and there are some bright young women out there who would probably really enjoy an IT career but don't think of it as an option. That's not cool. I'm not a crazy women's-rights activist, but I am passionate about young people getting all the opportunities they can to excel. If I can do something to ensure that girls are leaving school with a good grasp of the choices they have of where to head next then I'm all for it!

We need to promote IT as a career to people. Not women. Not men. Just anyone and everyone who has the aptitude and might enjoy it. However, whatever we're doing at the moment seems to only be reaching the men... and that's what I think needs to change.

(Incidentally, the other thing I think may need to change at the moment is for me to stop being the 'womens advocate person' and go back to just being a developer...)

Head re-attached

It would appear that busy-ness combined with flu has a negative impact on blogging frequency... Not that surprising really.

Anyway.

I thought it was worth following up on my previous post on my adjustment, or lack of it, to a team leadership role. Things have definitely settled down since then although I get the feeling that has more to do with the project itself moving on from start-up panic to settled development rather than anything I have done. I have made one change to how I work though which I feel makes a big difference:

I no longer make paper to-do lists.

Sounds simple but, to be honest, not something I thought I'd ever do. I really like to-do lists I can scrawl on and cross off and put big circles around. I like having something that's not on my screen and is always visible no matter what programs I have open. Something I can pick up and take to meetings, or take satisfaction from screwing up and throwing away. Despite this, I don't have any now and it's great.

I've been using the Tasks feature in Outlook as a replacement. I use the to-do bar which happily displays my currently incomplete tasks and my upcoming meetings next to my emails. Like the rest of the world it seems, I always have Outlook open somewhere and it's visible about 90% of the day (If anyone is wondering how on earth I manage to get anything else done, think 'two monitors' and all should become clear...) so my to-do list is still pretty much permanently and instantly accessible. Here's what I've found really useful about this:

• I never have to rewrite my list. Being digital, items get added and removed and the list quite happily cycles over time. Big advantage: nothing gets lost in the process of moving to a new piece of paper.
• Categories. I now have, effectively, two lists at once - one for things I need to do and one for things I am waiting for the client to get back to me about. One click moves items from one list to the other as necessary and I no longer forget which questions I asked in that email to so-and-so last week.
• 'What did I do yesterday?' is easier to answer. Tasks completed on a particular day show up on that day in my Outlook calendar so I end up with all meetings and tasks in one place to refer to when I need to fill in a time sheet.
  

Although things do still slip through and get missed that's now usually a result of me not wanting to do them and coming up with some semi-plausible excuse to leave them 'for now' rather than me genuinely forgetting/losing that one critical thing. So I can happily blame it on my own stupidity :)

Otherwise I haven't made many changes. I still check emails as soon as they arrive, mostly because clients frequently send me meeting requests at short notice or urgent requests for something-or-other that need dealing with straight away. I think this is ok... since I don't have a audible alert for emails I do need to glance at Outlook to notice their arrival and if I'm doing something where a context switch would be harmful I'm generally engrossed enough not to look up.

So, there you are. Tip of the day: throw away your paper to-do lists and use something digital instead. It definitely doesn't have to be Outlook, it just needs to be something that lets you add and remove items with next to no effort and will be constantly visible.

In other news - I'm going to TechEd this year! Intergen sends a group every year as we help to run the Hands on Labs. Very excited and pleased to be one of those able to go. I wanted to go last year but felt too small and inexperienced to apply. Decided to apply this year despite being fairly sure of not being able to go due to project commitments so it was a very pleasant surprise :) So, if you're going to be at TechEd in Auckland come say hi - I'll be the girl in bright yellow camo pants...

Headless Chicken

I've been officially a Team Lead for a while now but this week it's really started to feel like it. Design was interesting, new to me and provided lots of scary opportunities to stand in front of clients and try to explain myself but it was nothing like this week. Firstly, I was then leading a team of... uh... me. Not so much leadership required, although more than you'd think! Secondly, because I hadn't managed to be involved in that stage of a project before, I was still learning lots and it felt more like a move sideways rather than up. Last week, however, (drum roll please) we started development.

I was really looking forward to this. This was the part of the project where I felt I best understood the team lead role and what I would be expected to do. This is the bit I love - looking at a blank screen and starting to throw stuff onto it, then watching things take shape. And, this time, I'd be running it. I'd get to play with the hard/funky bits, pass on to someone else what I hope I've learnt of how to code well and support them so they could code freely without being caught up with frustrations...

Summary of how it's gone: I'm exhausted.

Admittedly this is partly because there's been other stuff going on this past week which has resulted in some late nights... But I'm still surprised at just how tiring it's been, and how little I've actually got done. Somehow, I'm sure I'm busy all day but I get to the end and my to-do list is longer than when I started! Plus, I only spend about one hour per day working on a use case - if I'm lucky. It's a big shift in thinking and ways of looking at things - I'm finding it hard to plan or estimate anything with the constant interruptions / context shifts (emails, questions, meetings, phone calls...) proving a bit of a challenge. I miss being able to sit down for a couple of hours, fully focus on something and see it done.

Sorry, I didn't mean to complain. It's been fun too - I have got to do some of the background helper-type code I was looking forward to and it's been nice discovering I have some useful knowledge to pass on. I am hoping things will settle down a bit as the project settles in a bit more and there's not so much running around to do. I'm also understanding more and more why the team lead on my previous project starts work really early in the morning!

Anyway, what I've been musing about today is whether there's a better way I could be doing this so I look a little less like a headless chicken. I seem to spend a lot of time trying to figure out what I should currently be doing, or what I was doing before I was interrupted, or what someone else needs to do. I have to-do lists (usually more than one, perhaps that's the issue) and post-it notes and a project plan but things still keep slipping through. Then I end up merely reacting to things rather than being in control and that doesn't work. So... ideas anyone?

A manager mentioned last week that it's far more efficient to only check your email a few times a day rather than jumping on messages the moment they arrive. I'd heard the theory before, and it does make sense since you context-switch less often, but so many people send emails expecting instant answers that it's difficult to put into practice. Worth a try? Not sure. I'm certainly considering it as an option - would make for one less type of interruption at least.

I'm also wondering whether I'm trying to cover too much. Letting go of things a bit and delegating more is definitely on the cards for the weeks to come. I don't have a particularly good track record of letting go of anything but we'll see how we go. Just another needful skill to learn. I find it ironic that not so long ago I was bugging my team lead that he needed to learn to delegate...

Beyond that, I'm banking on my brain adjusting to keeping track of many more things at once!

Big Girl

Well, it's amazing how many things can come out of one little trip...

An item about my trip to Girls' High appeared on our company intranet earlier this week with a link to my blog post about it. This resulted in the page views on my blog quadrupling for a couple of days and a variety of senior staff members pulling me aside to tell me they thought my blog was great and comment on a variety of things. The positive feedback has been really encouraging and people have been very supportive of some of the ideas I've been writing about and providing more ideas and resources to help me achieve what I want to. Good times!

I also had a female colleague get really enthusiastic about doing more school visits with me to keep promoting IT to the next generation of girls. There's a few people who've expressed interest now and we're all meeting up next week to "come up with girl power strategies". It's a really neat feeling when other people start jumping on your bandwagon. :) So we're now looking at publishing an article, offering to speak at some Wellington High Schools, perhaps visiting the Universities too, hosting a work visit for keen students and a Bring Your Daughter To Work Day! Exciting times, especially when some company directors are included in the group of interested supportive people.

This morning I received a really sweet card signed by the girls I spoke to last week and a letter from their teacher as well to say thanks. It was a very warm fuzzy moment reading all their comments - I was amazed at how many of them said they were considering IT as a career now! It turns out the class teacher also sent a thank you letter to my boss... which resulted in him nominating me (at some length) for our weekly award this week.

Overall, it's been a very warm fuzzy day/week on all counts!

Some of the warm fuzzies have been pretty scary too. Mostly as a result of me taking on a Team Lead role now but partly, I think, from the sheer amount of publicity I've gotten lately I'm doing / being asked to do lots of things I would never have imagined doing at this point in time. Notably:

• Needing to get a 'Sales' code for my time sheet
  
• Organising and running meetings with clients
• Not having enough time to do what I had planned because of meetings, things to follow up, queries from people etc
• Doing time and cost estimates for whole pieces of work
• Spending an evening mingling with and amusing clients for a client function
• Being asked to help interview someone (next week)

I was complaining to my project manager about this this afternoon - "Lots of scary things are happening this week!" - her response was: "Yes, you're a big girl now!". Don't get me wrong, it's great, exciting and a privilege; I just can't help but find it all a little scary sometimes when I start to wonder if I'm really worthy of the confidence people are placing in me. All I can do is try to be as worthy as I can I guess! And cover my monitors with post-it notes to avoid forgetting things.

I've been musing that this is something else to talk to any future groups of high school students about - as being somewhat unique to the IT industry I think. This is an industry where companies are growing fast and people have an opportunity to grow incredibly fast if they want to. It's not that long ago that I was a lowly new graduate who had to ask her mentor what a stored procedure was...

Fish! Being Present

(see my previous post on the Fish! book if you don't know what I'm taking about)

Our fictional manager noticed something rather special about the fish market: even though there's tremendous amounts of noise the fishmongers always seem to hear her replies to their questions, they're always waiting for those replies, never distracted by other goings-on and even when they don't have a customer right then they're scanning the crowd, focused, looking for the next opportunity. They are completely present.

Have you ever tried to have a conversation with someone who is obviously thinking about something else? How did you feel? Like they didn't care two hoots about what you were saying? Like you weren't important to them? Like you didn't want to talk to them anymore? Have you ever carried on a conversation with someone when you were thinking about something else? Do you think they felt like that? Do you want your clients to feel like that?

Being 'present' is, I think, pretty crucial to any kind of relationship whether it's with a client, co-worker, friend or family member. All of those people need to feel that you're genuinely interested in them and that they matter to you. It's primarily about listening well but also about setting your priorities carefully, making this person your priority and not letting anything else interfere. When you're fully present it draws people in; they want to talk to you. Clients, especially, need to be sure that when they're paying for your time they have your complete attention.

Before I go any further, I'm very aware that I'm shockingly bad at this. Every now and then I get it right but as a general rule I'm chronically distractable, so this post is aimed very much at myself. If it happens to apply to you as well then that's all good :)

Signs you're not fully 'present':

• Eavesdropping on other nearby conversations
• Looking at something else that's going on
• Needing to ask a person to repeat what they said
• Doing something else while talking to someone

Multi-tasking is a useful skill, just try to avoid applying it when one of the tasks is talking to someone. Before you all lynch me - there are some obvious exceptions to this e.g. fixing a problem while someone talks you through it, looking up a relevant piece of information for someone etc. The important thing is that it must be clear that the person you are talking to is your priority. Don't feel that you need to instantly drop everything for people either, it's often not the best plan. If someone comes to your desk and asks you for help it may be better to ask them to wait two minutes while you (finish/save/comment to come back to) what you were doing so you can turn away from your screen and give them your complete attention without needing to hold the previous task in your mind. Most people will really appreciate that as they'll be able to see you making an effort to clear the way for them to be your focus. Some of the guys at work do this consistently and I really appreciate it every time.

Also on the evils of multi-tasking... When talking on the phone it's very easy to fall into the trap of 'I'll just quickly check this email during this call, it'll save me time". Just because the person on the other end of the line can't physically see you doesn't mean your shift in focus will go unnoticed. Phone calls should really command even more of our attention than face-to-face meetings as we lack, and need to infer, all the non-verbal clues as to what's really being said.

When you give your full attention to someone without allowing distractions you will understand more, be more able to ask sensible clarifying questions and appear more interested/personable/intelligent/you-name-it. You may also be suprised how much extra information people will give you when you make them your priority.

Fish! Play

(see my previous post on the Fish! book if you don't know what I'm taking about)

One fine day in Seattle, our fictional manager takes her children to the fish market where her favourite fishmonger proceeds to illustrate his second major principle... Play. This is pretty self-explanatory really: don't be afraid to goof around a bit, enjoy yourself, don't take yourself too seriously. Make your workplace a really fun place to be, where people want to spend their time.

Playing is something we at work (the development team at least) do really well. In our area of desks we have an airzooka, which gets a lot of use, along with a variety of small balls and one great big ball that someone used to use as a chair. The principle 'if someone looks like they're having a bad day you should throw something at them' seems to be widely believed, and also seems to work pretty well. :) Especially when the 'something' in question happens to be a screaming toy monkey.

We also used to have a cricket bat and I remember one particular afternoon when a couple of the guys had a fantastic game using the walkway between the desks and a lemon. The lemon started to get rather squishy after a while but went flying out the window before we could repaint the walls with lemon juice! I am at a loss to understand how the guys manage to so confidently throw/hit objects around in an office full of computer equipment but I've never seen them hit anything other than the walls, roof and each other.

On a slightly more organised level the office is equipped with some couches around an X-Box and an old arcade game in our 'Chill Out Zone' which also gets plenty of use. It's amusing to watch a particular group of frequent X-Box players frantically signalling each other across the office that another game is about to start.

Please don't get the impression that we spend all day playing silly games and never do anything else. In fact, I've noticed that the people who play the most tend to be the ones who get a lot of work done. When you're doing something, like programming, which requires intense focus you really need to be able to break out and 'change mode' completely for a while. We have an environment where we can work hard but also enjoy ourselves, which I think is great. Not too much to work on there...

Fish!

We have a new director who's just joined where I work. He's... searching for best description... 'energetically enthusiastic'. Anyway, his current initiative to improve the 'vibe' around the office is to get us all reading a book called "Fish!". He bought 12 copies, stuck a list of names in the front of each and passed them around the office. It got passed to me today.

Let's just say I have already read it twice through and summarised it in a mind map... Ok, ok, I'm an unbelievable nerd! But it has really made me think.

The book is about having fun at work and using that to both "boost morale and improve results" based on the example of the Seattle Pike Place Fish Market. I'd heard about it before and added it to my list of 'stuff that could be interesting to read sometime' but never got around to it. It's a story of a (fictional) manager who gets put in charge of turning around an incredibly unmotivated poor-performing team with a really bad reputation throughout her organisation. She walks past the fish market one lunch time and gets talking to one the fishmongers who helps her out with advice... and then, of course, uses that advice to achieve fantastic results with her team and improve her personal life significantly as well.

I've been watching the books go around the office, waiting for my turn and noting how people are reacting to them. The unfortunate thing is that few people are as enthusiastic as I am. That's probably my one complaint about the book; the team in the story are immediately keen to change and to put effort in to bring it about, there's no mention of how to generate that desire in the first place. What if people (like some of my workmates) aren't all that keen on changing? Admittedly the team in the book is in a pretty extreme situation and we, in general, do rather well on the 'having fun at work' front so there's no huge shift required. On the other hand, I certainly found things in the book that I can apply to better serve both my clients and my workmates. Not only that, but to make me a little happier too :)

More fuss to happen at work I think once all of us have read the book. Another problem I can see is that it would be difficult for a manager to present most of these ideas without sounding cliched or silly. Hard to find a way around that one, except by getting the staff to read the book so they mock the book rather than you! *joking..* I'll just have to wait and see what happens I guess. I have to admit I'm looking forward to seeing where we go from here and keen to be involved.

Perhaps this is another example of me being young, naive and idealistic... I had a contractor say to me once "Oh, you're a new grad! I thought you were too enthusiastic". I thought it was pretty sad that people assume it's normal to lose your enthusiasm after you've been working for a while. I'd much rather be young and naive than old and bitter! Incidentally that's something else mentioned in the book - make sure you never stop learning and growing.

Apologies for the lack of detail in this post - I'm planning to go through each major point the book raises (there are four) in a seperate post, so watch this space!

Coffee

I had to take a workmate out for coffee on friday. While other workmates have previously taken me out for coffee when I needed it, this is the first time I've done it for someone else and it's made me rather sad.

To give you some perspective: the workmate in question is the team lead on the other half of a large project I'm working on. We don't work directly together but closely enough that I know what's going on. I've been making a point of keeping an eye on things for a while, going over to chat, asking him how things are coming along etc. On friday afternoon we had a team meeting in which we had, once again, gone over the various things that are making a particular section of the work less-than-fun. There had been some infrastructure issues between our site and the client site so progress had been slow and frustration levels were pretty high. Add to that another team member who was struggling and needed help, the senior team member busy with other projects and not able to give much time and a go-live date approaching fast... Result: one stressed and unhappy team lead (surprise surprise).

After the project manager had closed the meeting and left, a few of us just sat and looked at each other for a while until I informed my workmate that we should go get some coffee. We had coffee, and cakes, and I let him talk for a while about how upset he was. Then we talked about the shed he was going to be building over the weekend and his little son... and then went back to work. All well and good, and I was glad to be able to be there for him, but not how things should have been.

Now, some of the factors stressing him out could perhaps have been avoided, but I don't want to go into that here and I think most things are out of our direct control. Cause is beside the point, what I do think is a problem is that we had an upset staff member and it was left to me to do the coffee thing. It shouldn't have been me. I didn't have the authority to say what needed to be said (that he was doing a great job) or to offer help because I'm not involved enough or senior enough for it to mean anything.

Our project manager did, in fact, shout us all coffee on thursday. That was great and we all enjoyed a break and a chance to chat to everyone but there is a difference between shouting the team coffee and taking a particular staff member out to provide some one-on-one support/appreciation. Individual attention is incredibly important, especially when things aren't going so well. When managing a difficult project, I think it's crucial to ensure that each individual member of the team believes that you know and care how things are going for them. If you're pushed for time, at least make sure you have that kind of a relationship with the team lead and encourage them to do the same for the rest of the team. You don't need to take them out for coffee every time; just pull up a chair next to their desk and have a chat, then remember what issues they mentioned and ask them later how they're progressing.

I know I'm sounding very idealistic and that it's difficult to keep track of things to that degree but it is possible and I believe it's worth it. Go on, take someone who needs it out for coffee tomorrow :)

Tick

Had a conversation with a project manager recently in which she said that she tries to figure out what motivates each person on her teams and what relieves their stress. In short, what makes them tick. She says I was easy - it's all about the chocolate!

Admittedly, I do love my chocolate and I have been known to accept undesirable tasks on the condition someone buys me chocolate. But I think she's missed a couple of things which are pretty major. I function not solely on chocolate but also on feeling like I've accomplished something useful. This made up of 2 things:

1. Accomplishing something, anything! This means seeing progress, being able to cross something off the list, having some sense of achievement. We all need this, projects where progress seems to go backwards have been described by workmates as 'soul destroying'.
2. Other people (colleagues or clients) appreciating what I've done. Recognition matters lots to me: a piece of paper with 'well done' on it will often stay on my desk for weeks! This is the bit that transforms "I've done something" into "I've done something useful".

No amount of chocolate will turn around a project where developers' work seems to be leading nowhere and no-one is acknowledging the effort they put in. I was involved in a project that ended up like that last year and the turnover rate was unbelievably high. Chocolate does contribute towards the second one though: "Someone bought me chocolate therefore they must appreciate me somewhat".

The other thing that I've noticed about myself is that I'm an information junkie. I'll put up with pretty much anything (including a lack of chocolate!) if I have all the information around what, who, when and why. Especially why. On the other hand, if I know something's going on but I don't have the details I get very frustrated very fast. One of my workmates in particular tends to try and 'protect' me from some of the larger client issues we come up against, I don't think he realises I'd be less stressed being involved than wondering what everyone else is trying so hard to fix. If I have a reason for what I'm working towards I'm very happy giving it everything I've got.

I wonder how many other people 'tick' this way. I wouldn't be surprised if both feelings of useful accomplishment and needing information are pretty common drivers for people. Maybe this is something to keep in mind when leading teams - ensure there is a sense of progress, provide recognition and give the team all the information you can about the bigger picture.

Buying people chocolate doesn't hurt either :)

A work rant

It's been a crazy busy couple of days with lots of conflicting demands on my time. I'm enjoying the feeling of being in demand and wanted although it reached the point today where I can no longer satisfy everyone which is far less fun. Still trying though, and hoping to swing some things and make it work.

I've spent quite a bit of time this week pulling people into little rooms with closed doors and talking about the decision I needed to make (see my earlier post) and I have been impressed at how willing people have been to listen and how much caring they've all shown. There's something really special about a workplace where it's perfectly ok for me to grab a senior staff member and agonise at him for an hour. There's something even more special about a workplace where the senior staff member being agonised at is happy to advise a course of action contrary to what his manager had recommended because he believes it would be more to my advantage.

I also had a neat discussion with my project manager this morning around why we all do what we do and what makes it fun. Both of us enjoy the challenge of direct client-facing work and love being busy doing multiple things at once. I really enjoy the ability to craft something to suit a client's requirements, tweaking it so it's exactly what they need and helps them do their job somehow. She gets excited about really difficult clients or large disasters that need sorting out, smoothing over or rebuilding.

Overall, the people I work with are incredibly consistently cool. They're supportive, encouraging, caring, enthusiastic, dedicated, patient and great fun to be with! We're all very different but that 'coolness factor' is so consistent it's always surprising me and I tend to rant on about it at length fairly frequently. Seriously though, I think you'd be pretty hard pushed to find a more supportive, fun and exciting place to work. Yes, there are lots of challenges and we sometimes work long hours to get something done. Sometimes clients throw curve balls at you and you don't duck fast enough, some people are less-than-fun to be around, some projects drag on and on and on... but there are always moments when something works and your workmates join you in shouting how pleased you are, or a client finally recognises what you've done and thanks you, or a team pulls together and produces something none of them could have on their own. I love my job :)

p.s. By the way, now that I've had my rant - we're hiring! Come work for us :)

Decisions... and golf

Sometimes, when I take a metaphorical step back and look at my own actions from another perspective they look extremely odd. Here's the example I'm currently thinking of:

I have a decision to make at the moment - can't say too much (for hopefully obvious reasons!) but basically it's an offer of a role I need to accept or decline. My decision making (or rather, not-making) process seems perfectly logical inside my own head but from any other point of view... well... a little less logical. I had a brief chat to my 'counsellor' about the role (where I work we all have a senior staff member assigned as a 'counsellor' with whom we meet up once a month and discuss career goals, it's great) and he was fairly adamant I should turn it down. His reasons all make sense and, in terms of my career as a whole, taking the new role is probably a fairly silly idea.

However, I really don't want to say no. I realised this while I was seriously considering finding another staff member who would want me to accept, explaining the reasons I shouldn't and waiting for them to convince me otherwise. Talk about taking the easy way out! So I made a list (This is typical behaviour for me: if in doubt, make a list. If still in doubt, make another list.) of why it was I felt I didn't want to say no. Basically, it came down to four things:

1. I don't like to say no to anything, ever.
   
2. I'm very fond of the project manager who's asking me to take on the role and I don't want to disappoint them.
3. I want the title so I can feel important and useful.
4. I think the role is important, and I want to see it done properly. (If you want something done properly do it yourself!)
   

Logically, as far as I can see, the only one of those things which should be taken into any consideration is the last. So the real question becomes: "Should I be putting my own career goals to the side for the sake of getting a particular job done well?"

That's interesting, because now I put it in those terms the answer, to me at least, seems extremely obvious - yes. If I believe something should be done well and that I am the best person to do it then I should do it without any consideration of whether it may be to my advantage. I'm now cringing at the thought of explaining that logic to either my counsellor or my mother, both of whom will probably berate me for being too much of a sentimentalist.

Or, am I just convincing myself that this is good logic so I can take my preferred way out and not have to say no? When I've finished second-third-and-fourth-guessing myself I'll let you know! I'm also going to need to decide if I really do think I'm the best person to do it...

Anyway, enough said about that before I say more than I should! We are having a team golf day this afternoon which will, I think, be something of an exercise in humility. Any kind of physical co-ordination has never been my strong point and I haven't played golf before... Should be good fun though :)

Shouting at problems

I was sitting next to one of our technical services guys (lets call him Dave) releasing a website this morning when a senior manager (lets call him Warrick) came up and proceeded to suggest, in fairly strong terms, that a problem with another client's site needed solving. The suggesting then turned to ordering, blaming, complaining and swearing fairly quickly and with a lot of repetition along the way. Dave handled this well, attempting to explain what had happened while being talked over, nodding and agreeing, not raising his voice at all until Warrick at last went away promising to return "when you've finished helping Jo". I then had the fun of finishing a release with a fairly angry techie who informed his team members that "it might be a good idea to look at such-and-such, at some point today".

Before I go any further: this is a very unusual event where I work. As a general rule I am witness to some fantastic examples of leadership and professionalism from some truly awesome people who care deeply about not only what they do but also the people they do it with. Got that? Good, moving on.

The results of this morning's exhibition were, as far as I could see, two angry staff members (Dave and Warrick), one surprised and disappointed staff member (me) and a decreased motivation and likelihood of the job being done quickly. The latter is most notable since I'm sure this is precisely the opposite of what Warrick intended. In Warrick's defence he was obviously under a lot of pressure from a client who were understandably upset that something wasn't working, and it's always difficult to keep your cool when you're being yelled at and are dependent on someone else to solve the problem. But what a difference it could have made if he had. Perhaps, if the issue and its impact had been calmly and briefly explained Dave would have gone back to him for more detail and to resolve it immediately after finishing his current task... Perhaps he would have explained the problem to others whose co-operation he needed in the same calm clear way and they would also have responded... Perhaps no-one would have needed to raise their voice at all...

Key points I see here:

• explain problems calmly no matter how much they are stressing you out - people will be more willing to help you if you keep them feeling positive about the work
  
• explain the impact of the problem, not "the client is yelling at me" but "this is a big problem for this client because they need the system to order their morning coffee" - people, again, will be more willing to help if they understand why it's important
• be aware of what else the person is doing at the time - you will later reap the benefits of the brownie points you earn for keeping your description brief and thus minimising your interruption of their current task. Not to mention that the less time you spend interrupting their current task is less time it will take to complete and they'll be able to work on resolving your problem all the sooner

Perhaps all of that is pretty obvious, but the next step in the morning's drama was also interesting: one of the first comments from Dave after Warrick left was "This has been managed so badly, Warrick just left things with people without telling anyone else about it." Two things stand out to me in that one sentence: problems can be avoided with careful management and communication is critical. Careful management is all about planning ahead and making sure the appropriate people have the appropriate information. How you give those people information is important too - if you spout some information at one person then walk away assuming they now know everything they need a number of things may happen:

1. they forget all about it
2. they write down most of it but miss one crucial point which results in everything going pear-shaped later
3. they have perfect auditory recall but something happens to them and someone else who knows nothing has to pick up the job
4. they have perfect auditory recall and manage to complete the job

Hopefully you noticed that only one of those options actually involved the problem being solved. Putting things in writing is great. The process of writing something down clarifies your thinking and may help you see something important you had missed. Written material can be picked up and read by someone else, ensuring that when Bob gets run over by a bus all your information is not dragged under the tyres with him. Writing also provides a basis for clarification, where both parties know what is being discussed, and it can be easily added to or corrected when something else comes up.

Incidentally, Dave said much of this to Warrick this morning but Warrick responded by emphasising again how important it was that Dave ring his colleague (whose first child recently arrived) to get the information about the issue. Sigh...