Note That

Meme-ishness

noreply@blogger.com (Jo) — Tue, 15 Jul 2008 05:01:00 +0000

I have apparently been memed.

How old were you when you started programming?
18 - first year of university.

How did you get started in programming?
I was studying business analysis and decided I should do Programming 101 so that "when I had to work with programmers I would have some idea what they were talking about."
Turned out that programming is a lot more fun that business analysis, so I ended up changing majors.

What was your first language?
Object Pascal, using Delphi.

What was the first real program you wrote?
I can clearly remember our very first programming lab, after only one lecture. We built a little winforms app - just a window with one button in the middle, but it minimised, and maximised, and, when you clicked the button, the background changed colour!
I was so exicited...

What languages have you used since you started programming?
Object Pascal, Java, Haskell, Prolog, C#, various escapades into scripting and general madness in Access. (Ooops, forget I admitted that... I know nothing about Access...)

What was your first professional programming gig?
Intergen! Wait, I'm still here...

If you knew then what you know now, would you have started programming?
Definitely -and sooner!

If there is one thing you learned along the way that you would tell new developers, what would it be?
Keep asking questions. Especially ones that start with "Why..." That way you get to understand why things are done, rather than just how, and you're in a better position to suggest new ideas or to implement existing ones properly and to your benefit.

What’s the most fun you’ve ever had… programming?
Playing with low-level graphics is probably both the most frustrating and the most fun thing I've done. Notably one I've done lately which takes a set of locations and routes between them for a text-based adventure game, then draws a map of the environment. (Yeah, I know, I'm a geek)

I'll tag:
JD (who's already been tagged, but hasn't done a post yet)
Duncan
Nate

How to: Code Reviews

noreply@blogger.com (Jo) — Mon, 07 Apr 2008 21:40:00 +0000

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

noreply@blogger.com (Jo) — Wed, 30 Jan 2008 06:32:00 +0000

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?

On the shoulders of rather short people

noreply@blogger.com (Jo) — Sat, 26 Jan 2008 23:52:00 +0000

Since my last post I have done a variety of weird and wonderful things, which resulted in me being sufficiently distracted/busy/miles from a computer to forget to post anything about them! Very quickly, I have:

Written a 50,065 word novel in 30 days as part of the general insanity that is NaNoWriMo
Flown a glider
Flown a small aeroplane
Gone snorkeling at the Poor Knights (and managed not to drown!)
Spent 10 days in an old canvas tent in Christchurch with around 3,500 other girls/women (Girl Guide Jamboree 2008)

Onward to the actual purpose of this post, which I hope may be more interesting!

Scott Hanselman recently published a post entitled "Standing on their shoulders and paying it forward" which contained the following paragraph:

If you have a blog, Dear Reader, why not take a moment at the beginning of this new year to write a post about the people that helped you get where you are? Parents? Teachers? First bosses? Friend? Spouse? Whose shoulders are you standing on?

The idea struck me as a laudable and sensible way to start blogging again in a new year after a long break. A list of all the people upon whose shoulders I stand would be more than long enough to cure a severe case of insomnia, so I won't inflict that on any of us. The crowd of people who have supported, encouraged and generally kept me sane over the years is huge and I am tremendously grateful to each of them. There are, however, a couple of people who stand out and have provided advice which I still quote and is helpful to more than just me.

Without further ado, may I present two women whose determination, frustration with me and patience despite it have left me with fond memories, pithy phrases and no few blushes of shame at how much I took them for granted.

#1 - a high school science teacher who placed her students far above herself - Ms Bailey

"Don't let your schooling get in the way of your education!" a hand-made poster on my bedroom wall once proclaimed. A unorthodox sentiment to have come from a high school teacher but one which proved a true and often useful guide. I had the privilege of being in Ms Bailey's classes twice - once as a 13-14 year old sitting compulsory 4th form/year 10 science, then again as a 15-16 year old in an accelerated class covering the critical sections of the 6th form / year 12 chemistry, physics and biology curriculums. In both cases some characteristics stood out: flexibility, humility and a strong focus on putting students first.

To a class of grumpy 13 year olds who didn't want to be in a compulsory science class, she posed a question: "What would you like to do in science?" To the unanimous response of "Blow things up!", she acquiesced, and found a way. A university project of mine years later began from the memory of learning to manufacture pure oxygen and hydrogen gases, measuring them carefully then taking a bottle filled with precise proportions into the middle of the tennis courts before lighting a match and watching it fly. And this despite a fear of explosions, which we only learnt about later!

To a young girl frustrated by an astronomy curriculum covering things she already knew, she granted permission to leave classes to pursue a personal project. The result sparked an interest in black holes that lasted years and left me dreaming of pursuing a career as a cosmologist and drawing singularities on paper for my friends during economics class.

Faced with a young idealist on a crusade against evolution, she again granted the permission for the project and weathered the ongoing discussion throughout the year with patience and politeness. Listening, questioning, proposing alternatives, but never ridiculing, she made the lunchtime discussions a time I looked forward to eagerly and left me feeling respected and capable. She also had the insight to use the opportunity as one of the few means anyone ever found to get me to work: if my grades dropped she quietly and simply became unavailable until they rose again.

A Biology expert struggling with the more complex Physics of the sixth form curriculum, she had the humility and grace to accept correction from a student - stunning an adolescent psyche wired to run on selfishness. Presented with my apology, her quiet insistence that she would much rather be embarrassed than allow the other students to learn something incorrectly left me more than impressed.

Having become a person in whose office I felt comfortable discussing my ideas, hopes and dreams, she shot down my thoughts of becoming a high school physics teacher with the simple statement "Don't you dare!" Again, more than a little unorthodox and certainly a surprise, but, yes, me as a physics teacher would not have worked well! In the same conversation she encouraged me to remember that there are far more areas of study in existence than those we cover in school, to try different things I hadn't thought of and thus to discover what it was I enjoyed. That approach resulted in the Computer Science and Psychology studies I enjoyed so much, and is one I advocated to a friend only last week.

For keeping me interested, pushing me to do more than the minimum, inspiring me with possibilities, pulling me up short when I needed it - thanks, Ms Bailey!

#2 - as cliched as it is, true nonetheless - MUM

All mothers, by definition, are important to their children. They all seem to accomplish miracles on a regular basis; resulting in most of them having in their possession some article or other with the legend "Best Mum in the World". Despite the stereotypicality of it, I insist on acknowledging how important my mum has been. :)

There are too many stories to tell here, but the traits I'd highlight if I could would be:

her constant pushing for the best - for me and of me
her stubborn independence
her focus on the practical - making it happen no matter what crazy dream I came up with
unconditional love - not only for me but for any of the wide selection of people she 'adopted'; demonstrating more than anyone else I know the ability to be there and to care no matter what a person may have done
keeping options open - the one technique for any and every situation!

You want to be a nurse? That's nice, dear. Why not a doctor?

You want to be a Cosmologist? That's cool. How about we go look at how you can get qualifications for that and where you can study.

You want to be a Physics teacher? Ok... let's look at how you can do that. Just make sure you keep your options open!

You want to be an Interaction Designer? That's cool. Let's look up some universities that specialise in that. Look, there's one in London...

You want to write a novel in 30 days? I think you're mad... but, here, have some chocolate, it may help!

You want to learn to fly something? Ok, I'll give you a couple of trial flights for your Christmas present - make sure you check out all the options!

Mum has slowly become the person I go to with crazy ideas, disappointments, successes, confusion. No matter what the problem may be, she'll always be able to come up with a list of options - to check out and keep open!

Reporting Services Tips, Tricks and Funkiness

noreply@blogger.com (Jo) — Sun, 28 Oct 2007 21:36:00 +0000

I've noticed over the last few months that people have been coming to me with questions about Sql Server Reporting Services... and I've been able to answer them. I had an issue with a Report Server myself a while ago and, when I asked who the Reporting Services guru was so I could get some help, was told "You are."

Anyway, the upshot of this is that I've realised that, even though I don't feel like it, I've picked up a fair amount of knowledge on the ins and outs of SSRS. Since I frequently try to Google reporting services issues I'm having and am unable to find answers easily I figured that putting some of the bits and pieces I've figured out into a blog post might help somebody :)

Here's a list of ideas that came to mind - I've either been asked how to do it by a colleague or I've had a client who required it and found it difficult to find a solution.

1 - Date formatting
If you have a string parameter coming in to your report (from a stored procedure for example) and need it displayed nicely, try using the expression:
=CDate(Fields!MeetingDate.Value).ToString("dd/MM/yyyy")

You will get minimum date values being displayed if the date is null for particular search criteria. If this is a problem for you, try using:
=IIF(IsDate(Fields!MeetingDate.Value),CDate(Fields!MeetingDate.Value).ToString("dd/MM/yyyy"),"")

Obviously in both these cases you can insert whatever format you'd like in place of "dd/MM/yyyy" :)

2 - IIF statement gotcha
Beware of using the IIF statement above - it works beautifully if the string is either null or a valid date but if the string is something like "tomorrow" (or even an empty string) then you will see "#Error" in your report. This is because IIF statements execute both paths when evaluating (they're not lazy enough!) so Reporting Services tries quite hard to convert "tomorrow" to a date and falls over when it can't. If you need to get around this try writing your own function (Report/Report Properties/Code) using more standard .NET IF statements and call it from your expression. Otherwise, just be aware and be careful when using IIF.

3 - Newlines in text boxes
If you're using an expression to build up a paragraph or two of text in a text box and need a new line, use this:
VBCRLF (Visual Basic Carriage Return Line Feed for those who're interested!)

E.g. ="This is line 1" + VBCRLF + "This isn't" will produce:
This is line 1
This isn't

Gotcha: If VBCRLF is the first or last thing in your text box, Reporting Services will ignore it (I have no idea why!). Make sure you put in one extra VBCRLF at the beginning or end if you're using them there.

4 - Checkboxes
I would have thought it would be fairly common to want to display a check box on a report which is checked based on a value in the dataset but it would appear that it's not so common as there is no control provided to handle this. If your client, like mine, really wants a checkbox displayed on a report, you'll need to use wingdings. Yes, you heard right, add a small text box to your report, set the font to wingdings and use something like the following expression:
=iif(Fields!BookingMade.Value = "1",chr(0254),"o")

Feel free to play around with different wingdings characters, but I found these two gave me a nice looking checkbox that stayed the same size whether it was checked or not!

5 - Alternating row colours
Large tables look better and are easier to read if you shade alternate rows. This is easily accomplished by adding the following to the BackgroundColour expression of your detail row (substituting your desired colours of course):
=iif(RowNumber(Nothing) Mod 2, "#eefafd", "White")

I had a situation recently where my client needed alternating row colours but, for a variety of reasons, the rows displayed on the report were all group header rows. Since the RowNumber resets at every group all my rows stayed white. Using the following expression gave me header rows with alternating colours (the IDNumber is what I was grouping on):
=iif(RunningValue(Fields!IDNumber.Value, CountDistinct, nothing) mod 2,"#eefafd","White")

Enough from me for today I think. For more on Reporting Services check out these websites that I've found helpful:
Rules to better SQL Reporting Services
Chris Hays' Reporting Services Sleazy Hacks

Are there any more useful tips and tricks out there? Or improvements to mine? Drop a comment :)

Professionalism

noreply@blogger.com (Jo) — Thu, 13 Sep 2007 05:09:00 +0000

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

Decide to act

noreply@blogger.com (Jo) — Sat, 01 Sep 2007 22:02:00 +0000

I've spent the last couple of days at a first aid course (which I recommend by the way, everyone should know that stuff) and one of the things they emphasised was that the first thing that needs to happen in any emergency situation is for someone to recognise an emergency exists and then decide to act.

We talked a lot about this in psychology courses at university too - it's frighteningly common for someone to be in trouble and for all the people who could have helped to do nothing. We talk about 'safety in numbers' but the reality is exactly the opposite - the more bystanders there are, the less likely anyone is to do anything. After all, "someone else probably already has"...

Side note: If you're ever in a situation where you need help and everyone is standing around staring blankly, single someone out of the crowd: "You, in the blue jacket, go call an ambulance." Once they're singled out they're usually happy to help.

People also seem to have an incredible hang-up about 'interfering', especially if we have some impression that the problem is within someone else's family. The family violence issue we're talking a lot about in New Zealand at the moment is a good example of this.

But I'm not planning on writing a post about first aid or group behaviour, as interesting as they are. I've been thinking that the same type of behaviour seems to appear in other situations too - including at work. Sometimes it's all too easy to identify a problem, think to yourself "someone should do something about that" and then go get a coffee. It's easy to assume that, since the first requirement for a management position is mind-reading abilities, all managers will know immediately if something isn't happening as it should.

But maybe, just maybe, you are the someone who should do something. And maybe, just maybe, your manager can't read your mind and, because no-one else has talked to them either, doesn't know there's a problem. Is it possible?

Many people are, quite rightly, concerned about becoming the person who always whines about everything. Be assured that I'm not advocating that at all! People who complain about every little thing that it's possible to complain about drive me just as mad as I'm sure they drive you. Please don't do that :) What I am suggesting though is that, sometimes, there are genuine issues which need to be sorted out so that everyone can move forward and get the job done faster/better/more happily and those issues shouldn't be left for the magical 'someone' who will fix everything. You're someone aren't you? Why don't you do it?

Call me an idealist if you will, but here's how I see things: if you have a manager whose job description includes anything along the lines of 'team leadership' or 'ensuring efficiency and well-being of staff' then that person's job is to make your life easier. If you let them know what, in your work life, needs to made easier then you're helping them do their job. How nice of you :)

Again, don't bug them too much! Your manager is just as human as you are, which means they can get just as busy and stressed as you can. Don't just roll up to their desk and start your lecture - ask if you can make a time for a chat. Then you can grab a meeting room, close the door, and lecture to your heart's content for the half an hour they've set aside. It's not that difficult, and doesn't take much time, to respectfully and clearly state your concerns and finish with "I just thought you should be aware. Let me know there's anything you'd like me to do."

If you're still wondering whether to act or not, consider this: if you're having issues with something chances are that someone else is too. They're just assuming that someone else has already said something, that their manager has read their mind and that they shouldn't interfere. Do that person a favour and go sort things out for them.

Final note: remember that the step before 'decide to act' is to 'identify an emergency exists'. Make sure the issue you're having really is an issue and really is something that can be changed. Sometimes you just need to grit your teeth and get on with things, that's just life. If you're not sure which category your issue fits into, go talk to someone anyway and ask them whether they think it's worth doing something about.

Old cliched quote which is still true and rather appropriate:

God grant me the serenity to accept the things I cannot change, the courage
to change the things I can and the wisdom to know the difference.

TechEd Day 3

noreply@blogger.com (Jo) — Wed, 15 Aug 2007 08:49:00 +0000

It's amazing how fast three days can go when you've having fun and trying to learn everything there is know about everything in one hour sessions! But, the end has come, TechEd is over and, one hour later than the flight was scheduled, I have arrived back in Wellington. I will put together some 'lowlights' and some more detailed notes once I'm a little more awake but in the meantime, here's the highlights from today:

Lukas Svoboda on Development Teams was interesting for the first half when he was talking about principles of building great teams and how to recognise them, but less so when he moved on to telling us how great Team System is, at length. Shocking moment for me - he asked the audience "Who's used continuous integration builds of some kind?"; the entire Intergen contingent put their hands up... and about 2-3 other people. In a crowd of probably more than 300. I can't imagine working without my CCTray... what are people doing?
Andrew Peters on .NET Languages took us on a quick romp through static, dynamic and functional languages in the .NET platform. Andrew covered a lot of ground in a hour and kept it interesting with lots of demos. He finished with a challenge to go learn a dynamic language - that's been on the I-really-should-get-around-to-that-sometime list for quite a while, must do that. Python or Ruby anyone??

Overall, TechEd has been great. While some sessions have been decidedly uninspiring, they're in the minority and I've been able to hear a lot of good stuff on a huge variety of topics. I have been reminded again and again of two things in particular:

As I've mentioned previously, how passionate I used to be about User Experience design, and how much I should be again.
How much knowledge we have at Intergen that we take for granted but that a fair proportion of the industry doesn't seem to have picked up on yet e.g. continuous integration builds, test driven design, the MVP pattern... Our management often say we're ahead of the game, TechEd has served to prove to me that it's true.

If you get a chance to go to a TechEd anywhere - go. :)

TechEd Day 2

noreply@blogger.com (Jo) — Tue, 14 Aug 2007 20:58:00 +0000

I'm half asleep as a result of the TechFest party last night so if this doesn't make much sense I apologise...

Highlights from TechEd New Zealand day two:

Shu Scott on SQL Server 2005 optimisation was a usefully practical set of best practices to ensure queries run as efficiently as possible. Packed with content and some good explanations of why things work the way they do. I'm fascinated by the way the query optimiser chooses query plans, something to look into more.
Joel Pobar on C# 3.0 - probably the 'geekiest' session I've been to so far and was tremendous fun. Looks like there's lots of cool new features in the next version of C# to make our lives easier and coding faster. Auto-implemented properties and initialisers and type inference I'm sure I'll be using as soon as they're released. We also implemented LINQ from scratch in about 15 minutes which was a great romp through the new features. I'm particularly looking forward to playing with LINQ.
Jeremy Boyd on SQL Server 2008 - lots of new features here too, and again often around making life easier and faster. Being able to insert multiple rows from a single INSERT INTO VALUES statement will make creating test data rather less painful and the new MERGE statement will also be used a lot I'm sure.

Overall, very 'geeky' day yesterday but good fun and plenty of things to continue playing with a investigating. Downloading SQL Server 2008 CTP and having a play is definitely on my to-do list once I'm back home.

TechEd Day 1

noreply@blogger.com (Jo) — Mon, 13 Aug 2007 20:29:00 +0000

So far, so good. With one day through and a second just beginning, TechEd New Zealand is looking to be a great few days.

Highlights thus far:

Keynote from Lou Carbone on the shift from 'make and sell' to 'sense and respond', experience engineering and being 'clued in'. Lou was not just saying good stuff but saying it well, keeping to audience engaged and laughing. My favourite quote: "Businesses exist to provide value to customers. The reward is profit." The implication being that profit is merely a side effect of accomplishing the actual purpose, the focus should not be on profit but on customer value. I had a great (if brief) conversation with my manager afterwards talking about how we all need to be reminded of that sometimes.
Grant Paisley on Analysis Services was a very geeky and good fun session from a presenter who knew how to make sure people remember what he says. He had the audience with their hands in the air doing actions for each of his main points... "Attributes (wiggle fingers), attribute relationships (cross fingers), consolidate dimensions (hands together), partitioning (karate chop your neighbour)"
Darryl Chantry on UX Design served to remind me not only of how passionate I was about user experience while I was at university but also how much knowledge I picked up in the process and take for granted. A lot of the good points Darryl made (e.g. good design is invisible, users want predictability) my colleagues were commenting on as new and exciting while I'd heard them all before... Inspiring session with lots of examples of design the way it should be.
Women in Technology dinner brought 150 women from all sectors of the technology industry together for some good food and networking. It was a good night, although many of the audience didn't entirely agree with some things that were said (more on this later I'm sure!). Favourite quote was Helen Robinson's (Managing Director Microsoft NZ) comment that "The best teams are made up of the most varied people."

Overall, it's been fun and informative with lots more still to come. The yellow camo pants are actually pretty comfortable and we're certainly hard to miss - come and say hi if you're around.

In need of people

noreply@blogger.com (Jo) — Tue, 31 Jul 2007 07:14:00 +0000

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

noreply@blogger.com (Jo) — Tue, 17 Jul 2007 06:51:00 +0000

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

noreply@blogger.com (Jo) — Mon, 11 Jun 2007 06:57:00 +0000

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

noreply@blogger.com (Jo) — Fri, 01 Jun 2007 06:37:00 +0000

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...

Girls' High

noreply@blogger.com (Jo) — Tue, 22 May 2007 08:54:00 +0000

Well, after a post or two ranting about the need for more women in IT I figured if I was willing to moan about it I should be willing to do something about it as well. And so, for once, I actually did. Stunned...

I spent yesterday at Palmerston North Girls' High School talking to the students in a new Computer Science class about what it's like working as a Software Developer and how to get there. As a bonus, I was even paid to do so as my work were good enough to give me the time to go.

The class was a varied bunch of year 12 and year 13 students (i.e. 16-17 year olds) who seemed very happy to listen to me for an hour and were even good enough to laugh at my attempts at humour. The year 13s especially asked some really good thoughtful questions about what other subjects they would need to do and the relative benefits of different degrees and institutions. I gave them all a business card each and told them to feel free to email me with more questions - I'm very interested to see if any of them will do so...

I spoke a lot about it being ok to not know what you want to do and to change your mind. We also talked a bit about how the university system works and how you can do quite a wide variety of papers and try lots of different things. I spent time telling them stories of the crazy antics we get up to at work, the type of projects I work on and the way our teams are structured. I also wrote a quick EatCake(Cake c) method on the board (I need practice with whiteboard pens!) to reassure them, after they asked, that I didn't work with zeroes and ones!

Overall, I was pretty impressed - they were personable, showed interest, listened well and thought things through. There's hope for the future yet!

One of the girls stayed to talk to me afterwards. She's doing a new programme the school is running called 'Gateway' where she gets to do some work experience in the direction of her chosen career as one of her subjects at school. I think that's fantastic; it's really good to see schools recognising individual needs and offering some interesting options. The sad thing is, the company who took her on aren't helping her at all. Apparently, the office is dead silent with everyone just staring at their own screens and no-one is spending any time with her to help her learn. I could get really angry about that. It's not fair on a young girl to agree to take her on as part of a programme like that then just leave her to her own devices. If you're not willing to put in the time, just say no in the first place! It's less cruel... and less likely to put her off IT altogether. I said I'd have an ask around and see if anyone knows of another company that might be more helpful, hopefully I'll be able to track down something to help her out... Makes me sad to see keen young people who want to try things unable to because adults can't be bothered to give up a bit of time.

Palmy Girls' was where I went to high school and it was interesting going back. Nothing has really changed and I still feel like I could find my way around blindfold. I had tremendous amounts of fun sitting in the staff room during the break and watching many of the teachers do a double-take as they walked in - first seeing a strange person in a suit sitting there, and then realising it was me! Nice to catch up with people I hadn't seen in a long time and good to reassure them I had finally grown up and made something of myself... having been one of those students who drive teachers to despair by being obviously bright but not bothering to do any work.

Now they want me to go back and speak to the physics students... and the chemistry students... and the girls in the extension programme... Sounds great to me! :)

Note: I gave the girls the address of my blog so they could have a look. If you're one of them, post a comment and say hi!

Fish! Make Their Day

noreply@blogger.com (Jo) — Tue, 15 May 2007 07:22:00 +0000

Ok, last post on the Fish! book - sorry it's been so long in coming... very busy week.

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

The last point to note about the fish market was the way everything they did created special individual memories for people. The fishmongers made opportunities for people come up on the stand and try to catch a fish, or for children to visit the cold store or they simply took time to pay attention to someone and find out what was important to them. With each customer who came by they tried to Make Their Day.

Making someone's day can be one of a number of things:

Including them in the fun things you do to play at work
Creating memories
Going that little bit extra beyond what they expect
Identifying and meeting an individual need

This doesn't have to be something major, although of course it can be. Little things, like noticing when someone is not looking as cheerful as usual and taking the time / making the effort to find out what's wrong and maybe do something about it, can make a big impact. Also things like buying someone chocolate 'just because' or encouraging/congratulating someone. With clients, showing you have/want a really good understanding of their business and a real desire to make things work for them or getting changes that really matter to them out quicker than they expect or making sure their little preferences are specially catered for in your design. These are obviously just ideas off the top of my head (mostly based on things others have done for me!), feel free to be more creative.

Making their day has an obvious advantage - people like it when you do. Customers will want to come back, colleagues will want to work with you again; colleagues may even decide to do the same for you in return. But there is a hidden advantage as well - making someone else's day tends to make yours. So many times, on a not-so-good day of mine, someone else has needed help and I've pulled myself back together to give it, only to find that I suddenly felt much better too.

So, focus on Making Their Day when you can, especially for clients, and, if you're feeling down, go find someone who's day needs to be made and make it. :)

Fish! Being Present

noreply@blogger.com (Jo) — Mon, 07 May 2007 06:45:00 +0000

(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

noreply@blogger.com (Jo) — Thu, 03 May 2007 07:25:00 +0000

(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! Choose your attitude

noreply@blogger.com (Jo) — Tue, 01 May 2007 08:27:00 +0000

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

The major point throughout the book is that you can Choose Your Attitude. Basically, circumstances are beyond your control but you can choose how you react to them. Specifically, the work you do may be out of your control but you can choose whether or not to enjoy it.

This principle is certainly nothing new (my mother's been saying that to me for years!) but it's hard, so we tend to forget, and it's always good to be reminded. This particular reminder struck home on on a couple of levels.

Firstly, as a general rule I love my work so the need to decide to have a good day isn't so pressing. However, I've noticed that we all have a tendency to decide how good our day is based on what technology we happen to be working with. Even our 'energetically enthusiastic' director is guilty of this: I remember one of the first times he talked to me I admitted I was having a bad day, following which he glanced at my monitor and replied "No wonder you're having a bad day! You're working with Reporting Services!". What kind of day I have should not be affected by technology but on how I approach said technology...

Incidentally, I spend a lot of time with Reporting Services and while it does frustrate me at times I feel reporting is an important way for clients to get the information they need to make decisions and I enjoy making that easy :)

Part of choosing your attitude is choosing never to behave like a victim. Work-wise: we are not victims of specific technologies or clients or managers or team members. We are people with the ability to choose our own attitudes independently of all those things. I think most of us need to be reminded of that one! Our attitudes don't need to mirror others; if someone else is becoming uptight or aggressive there's no need to respond in kind. I remember one of our project managers being nominated for an award a few weeks ago for exactly that: responding perfectly calmly and defusing a client manager who was getting aggressive.

Choose Your Attitude also meant a lot to me on a personal level. In fact, the book came close to making me cry! You see, last year was a rough year for me personally and I became rather expert in being a victim and letting circumstances dictate how I was going to feel. I know many people told me I needed to choose to move on but I always replied "I can't do that! I haven't got closure!". It's so much easier to wallow in self-pity (you get sympathy that way) than trying to step out and find new ways of coping. It's only in the last couple of months that I've finally begun to leave things behind, mostly by a conscious decision not to care any more.

I know that Choose Your Attitude is a really easy phrase to say, but it's a much harder one to put into practice! I'm still figuring this out myself... but here are a few thoughts:

Choosing Your Attitude takes courage. It requires stepping out of your comfort zone, not looking for sympathy or the easy way out.
Because you need courage, you need to convince yourself it's worth it. Keep in mind what you have to gain (generally, enjoying life more!) and use that to motivate yourself.
I've found self-talk to be an effective tool. Literally talking to yourself and telling yourself what you're going to do. "I can choose my attitude and today I choose to be positive." It can be good to have a key phrase that reminds you of what's important to you. Make it your Windows password so you have to type it in multiple times a day!
Don't be surprised if change takes time. You'll probably need to re-Choose Your Attitude multiple times each day. Hang in there.
Little practical things can often help improve your mood. For me, wearing a new shirt tends to keep me smiling all day :) Also going for a walk, or grabbing my favourite drink/sweet or listening to particular music. Recognise when you need to take a break for a 'pick me up' and go do it.

I'll leave things there for the moment. Choose to have a great day today :)

Fish!

noreply@blogger.com (Jo) — Tue, 01 May 2007 06:45:00 +0000

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

noreply@blogger.com (Jo) — Sun, 29 Apr 2007 03:00:00 +0000

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 :)

Who am I?

noreply@blogger.com (Jo) — Thu, 26 Apr 2007 07:29:00 +0000

I figure, since people seem to be reading this and someone at least has done a search for posts labelled 'Me', that I should probably provide some kind of overview of who I am. It should also give you some idea of whether to pay any attention at all to what I say. Wait... maybe I shouldn't after all...

I work as a Software Developer for Intergen in Wellington, New Zealand. Currently doing mostly windows forms development with a fair amount of SQL Reporting Services and Oracle thrown in. I've also been playing around with SQL Integration Services lately which is good fun. Intergen took me on as part of their graduate program and have been great at providing me with opportunities and supporting me to try things and take on more responsibility.

I started work in January 2006 after finishing my degree in Computer Science and Psychology at Massey University in Palmerston North. When I started my degree I was majoring in Information Systems and wanted to be a Business Analyst but I did an introductory programming paper just to see what it was like and loved it so much I changed majors. Now, I'd like to be an architect eventually. The Psychology major was because I've always been interested in usability and, as I usually put it, "I want to understand how both computers and people work so I can get them to work together without throwing each other down stairs". Plus, it was heaps of fun :)

I was involved in leading a church high-school-age (13-18 year old) youth group for 3+ years while in Palmerston North which I loved. When I moved to Wellington I started leading Guides (9-13 year olds) which has been a new challenge and lots of fun. I love spending time with young people; I find their energy and enthusiasm for life contagious and enjoy the feeling of being able to make a difference somehow.

When I'm not at work or Guides I'm a bit of a bookworm. I found the BBC Top 100 book list last year and am currently trying to read all of them - as at 26/04/07 I've read 68. It's been a (mostly) fun exercise and I've read and enjoyed lots of books I would normally never have picked up. Good times :) Normally though, you'll find me with my nose in epic fantasy of some description - most notably Robert Jordan, David Eddings, Robin Hobb and Janny Wurts, although that list could go on and on!

The other major way I tend to occupy any time that may be left in a week is getting people together for strategy board games. (Please note, this is nothing like Monopoly or Scrabble.) My current favourite is Munchkin but we also play a lot of Settlers of Catan and Ticket to Ride Europe.

So there you are, one fairly long rant covering (hopefully) all the things you never wanted to know about me :)

Scary...

noreply@blogger.com (Jo) — Tue, 24 Apr 2007 08:15:00 +0000

Something changed over the weekend - people are reading this. Flattering, but kinda scary too and happening much sooner than I had expected!

It turns out that an ex-workmate of mine, JD, now links here from his blog and another workmate, John, quoted me on his blog. When I discovered this on Monday morning it freaked me out a bit. There's something a little unreal about reading your own words on someone else's website. I'm not even sure how either of them knew I had a blog, which makes things rather mysterious. All good though, lots of warm fuzzy feelings :)

I'm not entirely sure why I feel the need to comment on this. I started this blog with the aim of producing something people would read so I shouldn't really be surprised if people actually do. I guess I thought it would take a lot longer than it has, or I didn't really believe anyone would read it at all. For once, I am very pleased to be proven wrong.

So, I suppose this means I should be getting some more decent content up here rather than writing random posts on how pleased I am someone linked to me. Not to mention doing the work on the template which I've been putting off because 'no-one will be looking at it for a while yet'!

JD and John: thanks for the link-love guys :)

Developing Girls - 2

noreply@blogger.com (Jo) — Thu, 19 Apr 2007 06:52:00 +0000

Following my previous post, it is worth noting that we have lots of female analysts and project managers. They may even outnumber the guys in those roles and quite a number of them are ex-developers.

So it would appear that women tend to move out of development roles into more direct people-facing roles. Why? I think development is much more fun... But maybe I'm just odd. I guess it's another reflection of the same need to be 'helping people' directly that keeps girls out of engineering/software development to start with.

Thinking of possible reactions to these posts I came up with a couple worth addressing:

So? Who cares?
But girls don't have the logical brains for coding, they don't get into development because they just can't do it. Simple.

The question of who cares is easy to answer: anyone who has complained about the general shortage of developers. If we want to increase the number of capable developers out there, not cutting out half the population is probably a good starting point.

As for the second objection - rubbish! I know four women who disprove that every day. Unfortunately I can't leave it there because I am enough of a psychologist (yes, I have a psychology degree) to understand that there are differences between the way men and women think. A major one of those differences relates to aptitude for mathematics and the pure logic necessary for good programming. Guys are better at it in general. However, 'in general' does not mean there aren't plenty of women out there who have that aptitude. No, there aren't as many as there are men; but the number differences aren't anywhere near as large as those we see in the industry.

So those male-female ratios are something we should change and something we can change. Lets do it! If you have a chance to speak to a smart young woman anytime soon, make sure she's considering IT as a career option and show her she can make a difference.

Developing Girls

noreply@blogger.com (Jo) — Tue, 17 Apr 2007 07:11:00 +0000

This post was going to be about how junior developers can learn from the senior devs on the team. However, as I was mentally composing the first few sentences, I realised I was using exclusively male pronouns to refer to said senior developers. A moment's thought on why I was doing this revealed that we have no senior female developers.

In fact, there are a grand total of four female developers in our entire development team, three of whom started working for us as new graduates in the last three years. The fourth, admittedly is recognised as a senior developer, but our group of top senior devs/architects (the 'Development Steering Group') who I was going to talk about learning from are entirely male. To give you an idea of just how shocking these numbers are, our development team in Wellington probably includes upwards of 60 people. Once you add the other offices into the mix the number tops 100 and, from memory, I don't think there are any more women. 4% is a pretty dismal figure!

Don't get me wrong here - I do not for a moment believe that the company is discriminating at all. There just aren't many female developers out there to be hired! The situation was the same studying at university - it wasn't unusual for me to be one of two or three females in a class of more than 60. Female devs have sometimes gone to some fairly extraordinary lengths to assert their presence but nothing seems to be changing.

This reminded me of a blog post I read earlier this year about an article on cnn (unfortunately the link to the original article is now dead) about why women don't get into engineering. Apparently women aim for careers where they feel they can help people, hence the traditional female domination of roles such as nursing or teaching. I had a very close to home example of this recently when a younger friend who'd always aimed to be an accountant decided she never wanted to work for an accounting firm because it couldn't possibly be fun. "I'm a people person, I need to be working with people not with numbers." No amount of explanations could convince her that the numbers would be helping people, that she'd be part of a team, that any job was a 'people job'.

Now, I have nothing against wanting a career where you feel you're helping people - that was, and is, my aim for the work I do. I wouldn't be able to get out of bed in the mornings if I didn't feel that something I was going to do that day would help someone. My actions are focused around helping my clients get software that will make their lives easier and helping my workmates to be happier and less stressed. Yes, I spend most of my day staring at a computer screen; but my job is definitely a 'people job'. I originally got into IT after spending some time working as an admin/helpdesk person and seeing how upset and frustrated computers made people. I got to thinking that maybe if I could help create computer programs that were easier to use the world might be a happier place...

A lecturer in one of my university software engineering papers spent one of our ethics lectures discussing the lack of female developers. Her theory was that most guys get into IT through being interested in computer gaming. The problem is that most computer games, having being designed by men, don't appeal to girls; so the major entry point doesn't apply. Please note I said 'most' - there are exceptions (I'm a big fan of Myst and I have a friend who loves The Sims) but as a general rule gaming is considered to be a male activity.

So what do we need then? For games that appeal to girls we need game developers who understand what girls want to play and are willing to take the risk of trying to develop a new market. But, more crucially I think, we need to educate young women about all jobs being 'people jobs' and the opportunities there are to make a difference in the IT sector. I was talking to my high school computing teacher some time ago and we discussed the possibility of me talking to her classes. Maybe I need to get in touch with her again...