I passed my Prince2 practitioner exam. As “that guy” would say: “Awesome. Totally Awesome.” And then we would do the safety dance.
For the Futurama-impared among you, suffice it to say that I am happy that I don’t have to do the exam for another 4.99 years, and then only a tiny one.
It’s a shame that the only information that I can find on tailoring Prince2 to smaller projects is in book form… Oh well. Perhaps I can find some time between meetings *cough* to get some info together.
So the big news is a new job for me! It’s pretty crazy, being the second week and all, but I’m still in the steep end of the learning curve. So I’ll let that discussion pass for now.
The thing that is really killing me though, is no JIRA. I had gotten so used to having JIRA there to organise myself/others in, that without it I am stuck with (gasp) actual to-do lists. The humanity! There’s an installation of Gemini somewhere that is disused; which as far as I can tell is a feature-clone of JIRA, but, well, it’s a bit of a mess really. Needs a good ol’ DELETE FROM TASKS WHERE 1=1 I think.
The upshot of this is that everyone in dev land is a bit unsure from day to day what is supposed to be happening, which inevitably leads to meetings. Oh meetings; stealer of time, destroyer of fun.
Gemini seems ok, don’t get me wrong, it’s just that to the untrained eye (aka non-technical folk) it’s a bit complicated. Which, seeing as the only way to placate the meeting monster is by making reports, that’s not good. I don’t want to trade the time I spent in meetings with the time generating reports. I’d like it if someone wanted to know how that thing that has to be done by the end of the week, you know, that thing, was going, they could just check.
Maybe JIRA is complicated to the untrained eye too. I dunno. But save me from meetings!
I jsut finished reading an interview with Zed Shaw on O’Rielly called Zed on Ruby, Rails, Mongrel, and More
and I have to say it was very enlightening. It was interesting and encouraging to ‘hear’ him say: My motto here is “If I KMFU (Know My F*ing Users) they won’t have to RTFM.â€
I think that this principle is so often overlooked in the programming world – and not just the Open Source world either. I can’t count the number of times that I’ve had a go at some program or other and just been lost without the docs. I do try to keep it simple for my stuff but sometimes you kinda get caught up in some idea (yours or someone else’s) and you end up implementing some crap that does the job, but that’s about it. It doesn’t ‘just work.’
This relates to something else I read today, called The Art of No. As professional coders on deadlines that usually ‘cannot move,’ there seems to be a strong inclination to say ‘no’ to any change request or feature enhancement. While this makes the deadline less distant, it makes the client/your superior/the user more distant and lowers your rapport with them all. After all, they’re paying you! So, the article above says “ask why,” so you open a dialogue into the problem and see the other side of the story.
I’ve found that telling them that “you’ll see what you can do” works wonders too. This has the following benefits:
This last point is important – none of us can work for free, but customers can sometimes forget that. Bring it back to the bottom line. Underlying this has to be a strong spec of some kind, or a time-and-materials (per hour) agreement though – otherwise there’s gonna be pain when you get to talking about what was supposed to be delivered at what tie for what cost. Get your ducks in a row at the start, and everything else is a lot simpler.