“On the Topic of” articles expound endlessly on a topic that is completely and utterly ridiculous.

Good afternoon, the internet. I, Curtis Lassam, tireless champion of gentlemanly beverages, have just enjoyed a steaming mug of morning ambrosia.

Well, it was really more ‘afternoon ambrosia’. My morning was almost entirely consumed by meetings, as would be expected of a soulless corporate drone such as myself.

This tea was especially sweet, because yesterday, I failed at morning tea. I failed at all possible tea metrics. There was no recoverable deliciousness.

The morning was, of course, dominated by training meetings. We’re learning why Data Architecture exists, from a Dutch man who was programming in COBOL back before computers existed. I made my tea, and left it behind, distracted by more meetings.

So, that was an initial tea fail. Cold tea is no good. I thought, ‘hey, I’ll microwave this into palatability’, forgetting that my travel mug was forged out of what could only be described as a solid sheet of stainless steel. The explosion, and resulting stench of burning plastic, was noticeable throughout the entire department.

I tried making tea in the shattered wreckage of my old tea mug. It just tasted like metal and failure. I had to discard the whole sordid failure-pile that had once been my morning routine.

The whole compound fail that was my tea of yesterday, however, just made today’s tea all the more sweet. Well, that and the six or seven teaspoons full of sugar.

Royal Bank online banking now provides an extra feature – the ability to see a breakdown of expenses by category. “Food, telephone, entertainment…” One category is notably excluded from the list, however – ‘Bank Fees’. It’s hidden in a grey pie-slice called ‘Other Expenses’. Nice.

Last little while, my food experiments have been failing left and right. Popcorn? Burned. Dumpling soup? Too lemony, not oniony enough. Heck, my last frozen-perogies-from-a-bag were kind of boring, even.

But today, I’m three for three. I started by putting a brine together. A half cup of salt, a full cup of brown sugar, mustard powder, and black pepper, in a bowl, and then hot apple cider vinegar poured over the thing. Mix it up, give it some time to dissolve. Throw in two racks of ice, and shake a bit to cool it all down. Bam, brine.

Then, I tossed some pork chops in the brine. Just let them sit there and soak up flavor and juiciness.

Later? I got hungry. Chicken broth with green onions, fresh ground ginger, garlic, soy sauce, and rice noodles. It needed meat, so I fetched one of the half-brined chops, sliced it into convenient little strips, fried it up, and tossed it in the soup. Verdict? Delicious.

Even later still? I fried up a full chop. Flavorful, juicy, and delicious.

And then? Popcorn in a pot. My last two attempts at popcorn used a stock pot and fairly low heat, and the popcorn ended up being not-quite-burned-but-definitely-pretty-overdone. This time, I used a much smaller pot at a much higher heat. The smaller pot, while offering a decreased popcorn payload, was easier to ’shake’ over the element… and the popcorn came out fluffy and perfect. Nice. Three for three, baby.

So, a few days ago, I made a post about Grooveshark – but I never bothered to share a playlist.

So, here’s mine.

So, every year, the Computing Science Student Society produces a “Frosh Guide” for new Computing Science students. I remember typesetting our standard guide and adding batches of crazy rambling, one year.

As for “Advice for CS Students”, I polled Dan, Travis, and Dovic, and used their advice. The school did not appreciate Dovic’s advice.

The call has gone out once more, and so now I’m presenting my advice.

• Visit the IRC channel. (irc.freenode.net – #sfucsss) – it’s populated
  mostly by ex-CSSS who are industry professionals, and we know
  everything about everything.
• If a course says “Lecturer: Staff” or “Lecturer: TBA”, avoid it like
  you would avoid gonorrhea – unless you look forward to a whole
  semester of a clueless grad student reading PowerPoint slides off of
  an overhead projector.
• If a course says “Lecturer: Bart”, “Lecturer: Mori”, “Lecturer:
  Vaughan”, or “Lecturer: Baker”, take it. It doesn’t even matter what
  they’re teaching. Just take the course. I guarantee that it will be
  excellent.
• Occasionally crack open a textbook. Sometimes the concept that the
  lecturer has utterly failed to teach is in there, and explained in
  detail.
• Take notes in lecture and do the assignments, and nine times out of
  ten, your review-for-the-final will be a breeze. The tenth time out of
  ten, it’s because your professor dropped a big ol’ bridge-o-crazy on
  the class, and you’ll still do okay thanks to the magic of curved
  grading.
• All-nighters are a recipe for bad code.
• A lot of people come out of university with nothing to show for it on
  a resume except a hollow degree and a tiny amount of Java experience.
  This is bad. Do Co-ops, Project Courses, and Hard Courses. Do as many
  as you can. It’ll halve the time you spend in Junior Programming
  positions when you graduate.
• Try your very best not to do a co-op as a QA tester. The only
  experience that’ll give you is how to be a QA tester. It’s an unending
  loop of mediocre jobs.
• Bring a towel.
• Contribute to open-source projects.
• Have fun.
• You will never be surrounded by as many members of the opposite
  (/same) sex in your age, education, and interest group as you will
  over the next 4-8 years. As computing science students, this may
  occasionally mean that you need to branch out and try courses in
  Criminology, Journalism, or Biology. Join clubs. Meet people. You
  can hide in the protective shell of Computing Science culture for the
  entirety of your degree, and that’s just sad.
• Some students just come up to the mountain for classes, then go down
  immediately afterward. Soak up some SFU culture. Hang out somewhere.
• The student newspaper is terrible, until you consider that it’s
  written and edited almost entirely by amateur volunteers. They do an
  excellent job with limited experience and resources.

“Executive Summary” articles are highly compressed versions of semi-important things that I’ve read.

The Mythical Man-Month : 3 – The Surgical Team

The Problem

• Teams, of course, should not be more than about 10 people.
• Certain employees are much better at producing code than others.
• How do we maintain the conceptual integrity of a single, well-architectured system if there are 10 people building it?

The Surgical Team

Instead of divvying tasks up equally amongst all team members, Brooks suggests a ’surgical team’ – with the bulk of the coding responsibility on one man, and the support tasks divvied out amongst the team members.

• The Surgeon: Designs the software, writes the software, writes the tests, and writes the documentation. He is a very busy man.
• The Co-Pilot: The pair-programming partner to The Surgeon, the Co-Pilot understands all of the code, and has more time to discuss it with the rest of the team.
• The Administrator: Handles money, people, space, and machines – everything non-technical. Can serve multiple teams.
• The Editor: The documentation produced by the surgeon is likely to be a bit technical, unclear, and ‘engineery’. The editor takes that documentation and polishes it like nobody’s business.
• The Secretary: For filing and typing and answering phones. This book was written in 1975, remember. Replace this today with The Bitch, a young and semi-useless fellow (co-op) used to fetch coffee, make appointments, fill out Sprint charts, test, fix minor bugs, and dance for the entertainment of others.
• The Program Clerk: The guy who runs batches. 1975. In the case of 2010, replace The Program Clerk with The Build Engineer – the guy who manages source control, constant-integration build/compile/test chains, and what-have-you. Can also serve multiple teams.
• The Toolsmith: When The Surgeon says “I need a library that does X” or “I need a tool that does X”, the toolsmith finds or builds it.
• The Tester: Writes tests. Executes tests. Manual tests. The tester wants to break the system.
• The Language Lawyer: One guy who knows the language/library/toolkit really, really well, for consultation & code review. Can serve multiple teams.

The Benefits

• The Surgeon is the single point of contact for any work on the code, making inter-team collaboration easier.
• If The Surgeon gets hit by a bus, The Co-Pilot can step in right away.

“Executive Summary” articles are highly compressed versions of semi-important things that I’ve read.

Saying “No”

Here

Reasons to Say No:

• Kill a bad idea.
• Keep a project on time/budget

Ways to Say No:

• Cite Best Practices: Educate your customers. If everybody else is doing it, it’s probably for a reason.
• Use Data: Gather data. Authoritative-sounding numbers are convincing.
• Use Price: Quote a price for the bad feature. A high price.
• Who’s Using It? Usability testing from ‘potential customers’ is a good way to squelch bad ideas, as stakeholders visibly see the customers struggling to understand the features.

Cushioning the Blow:

• Yes-No-Yes: “Yes! It’s a good idea to try to blah!” – “No, that’s probably not a very good way to do it.” – “Yes! Let’s try to think of better ways to do that!”
• Wait: Think carefully before you ‘no’.
• Plan B: What if they don’t accept your ‘no’? What then?
• Same Data, Same Conclusion: Instead of saying no, give stakeholders the same data that you used to come to the ‘no’, and let them come to your decision.
• Less is More: A short, well-expressed reason why something is a bad idea handily beats a multi-page treatise.