School is real life

I spent a big part of this week doing recruiting-related stuff around UofA. It was a really great experience to (re)connect with professors, see what's going on, and get a different perspective on the department and job hunt process. I've talked about some of the good and bad versions of applicants before, so I'll skip that here. Instead I'll focus on the realities that I basically refused when I was a student in their shoes.

I heard in multiple classes that difficult group members happen, that projects require testing, that I probably suck at writing. I didn't believe any of it. However, all these things translate directly. Let's take a look, one by one.

You can't write:
I never ever believed this one until I started working at IBM and one day read a bug report:
"when I put the RDP in, it flashes then gets stuck" it read. What? Huh? There's like 100 versions of this. I wandered over to check it out, and on the way over grumbled about how this person is not considering that I have no idea what they are looking at. And then I realized that I was guilty of the same. This was a mini epiphany, and I suddenly got much much much better at writing effectively. And yes, most people suck at this. It takes practice. Not only do you want to be effective, but also concise. There's a big difference between a colloquial ramble like this and a well-composed, tight piece of prose. Opt for the latter in formal situations.

Sloppy testing:
As devs we want to believe that our code will always be perfect. Tests prove this. Unit testing is growing in popularity. I don't believe it's the be-all-end-all, but it's certainly a good way to help organize. If you're having a hard time creating unit tests, you probably don't have good units. Having good units leads to clean code with clear boundaries. These have clear roles with clear expected behaviors. It's just good policy.

But my teammate dropped the ball, give me a break!
Yeah, this happens. And guess what? You're at fault too. But you can't be expected to make them do their work, right? Well, true, sorta. The key here is to develop the ability to manage a project. Establish the pieces you need. Figure out the dependencies. Make sure the deep dependencies get taken care of first. Look at the pipeline here. If a piece is critical, make sure it gets done. If your assigned person isn't delivering, prod them, take over, whatever, make it happen. Understand the downstream effects of any particular piece slipping. Clearly N-1 people can do less than N, but you can mitigate the damage of the missing person by making sure that critical pieces roll off them. You may still not love the outcome, but you should be able to avoid getting burned.

Awesome possum. Go rock'em.