Simply put, I’m dissatisfied with my performance with MarkUs.

Up until now, I’ve been doing what could be considered the bare minimum of work to get a passing “grade” for UCOSP. This is my final school term which means I’m looking to the future a lot this term, searching for full time employment. While I’ve been very successful in this endeavour to tell the truth, it does mean that certain trade offs have been made which have not been to MarkUs’ benefit. When I had interviews to prepare for, MarkUs got put off. When I had assignments due in other classes, MarkUs got put off.

When I do work on MarkUs, it’s mostly a joy! It benefits from being a Ruby on Rails project in that 90% of everything is intuitive and easy to do. Most importantly, it’s fun! It’s fun to get results quickly and do meaningful work in so short a time. Occasionally there’s a sticking point that has me butting my head against a wall (converting fixture based tests to machinist for example), but that has taught me to take advantage of the ease of communicating with my fellow devs on the IRC channel, the mailing list, or through the review board. When I do work on MarkUs, I feel that I’m making up for deferred time, because I can get things done so quickly.

My feeling of being behind is a relative measure. I don’t post to review board nearly as much as Brian or Bryan. My submissions have not been as far reaching as Farah’s.  I haven’t blogged as much as Joseph. I’ve made only 3-4 submissions since the codesprint, when in my mind, I feel I should have been making at least one a week. There’s lots for me to do, I just need to go ahead and do it.

The only thing I’m satisfied with as a performance metric is the blog posts I’ve written.

From a development standpoint, I don’t believe I’ve learned anything new from the UCOSP experience, but it’s certainly re-enforcing what I’ve learned from my co-op work terms.

  1. Communication is key. There are no stupid questions when you’re unfamiliar with the code base.
  2. Go ahead and try things. Mistakes are the engine of learning, and by learning from them, you’ll do better next time.
  3. Be transparent. If you can’t get work done on time, then you can’t get work done on time. Don’t pretend you’re being productive when you aren’t.
  4. Be helpful. If someone is having a problem, and you think you know the answer, pass on the knowledge! It’s one thing to encourage independent learning, but in a team based project, it’s better to be cooperative rather than competitive. The project benefits from it.
  5. Code reviews are invaluable. Code review others stuff, and they’ll make time to return the favour. It’s proof reading for the programming set!

My goals for the rest of the term is to simply get more done.  I’ll have a job after the 1tth, which means that I’ll no longer be spending 1.5-2 courses worth of time on interviewing. I’m not in any heavy project courses this term beyond UCOSP, which means my time and energies can be focused on it.  I want to review more code, write more code, and generally make MarkUs better off than when I left it. I also hope that the Powers That Be (AKA Greg, Karen, and Mike) see fit to grade me on my overall performance for the term, rather than be focus on the unstable start to the term.