This was an action packed week for me, with minimal coding and maximal activities. I went to a hackathon that I wasn't even participating in, watched interesting videos about software, did a lot of reflecting on myself personally and professionally, and had a lot of fun with friends!

The greatest physical challenge... ever (hyperbole)

I saw friends on Monday and had a great experience at Cube Challenge. They have rooms that test various abilities: strength, skill, and smarts. Each room is a combination of the 3, but also focused towards one of the abilities. Unlike Activate (another company with room-based games), the strength challenges seemed almost impossible in some rooms. For example, the first room required going across two pairs of handhold railings a meter off the ground (think the type that you'd do triceps dips on), and spinning red beams that were located between the railings. The beams would swipe above the rails. The challenge is to get across the railings without touching the floor or letting the beams touch you. It is not a distance one can simply jump. A couple of us somehow managed to get over by jumping right after the beams passed, and then swinging our legs to catch on the other side. It was a perilous journey, as if we took too long to move the rest of our bodies over, the other beam would smack us. Fun room, but not so fun for my friends who had trouble jumping/swinging.

Reflecting on communication

As I relaxed one day, I began to think about communication. What is effective communication? I believe that because communication is a two-way street, there is no single method for effective communication. The best methods begin by understanding your communication partner.

I've written another blog post about communication because it ended up being far too lengthy for this one. In summary, I enjoy having context within communication, while I've found that most people prefer information that is delivered quick and concise. My communication style often reflects what I prefer, so I've learned to compromise and get better at matching other's communication styles. I think it's gone well so far me in life.

Interesting tech videos

I also watched two very interesting videos this week (more details below). The first was someone who got laid off from Atlassian. He'd worked there for at least 8 years and completed a very impressive feature stack for load balancing. Again, my full thoughts will exist in another blog post, but I must say that I enjoy hearing from people with such depth of knowledge. I've found immense value in my co-ops from this, in large part because it helps me understand which mistakes to avoid and productive paths to attempt.

The second video was a keynote by David Pamas on AI software and regulation of AI and "other unstrustworthy software". This one was very funny and informative. He started it off by saying that he hopes to get boo'd because it will show that he's talking to people with opposite viewpoints to him. My favourite part was when he referenced the "Turing Test" and how Alan Turing referred to it as the "Imitation Game". Other than the test being misunderstood by the wider community as a test that proves intelligence, he say that AI's passing of the test (as well as its inherent nature based on being trained on a large corpus of human-written text) means that it should instead be called "Imitation Intelligence". Something to think about for the big fish in the field.

Attending caseHacks

Finally, I attended [case]Hacks, a Scotiabank sponsored hackathon. I was really scared going into it, because I was attending alone, driving more than an hour, and didn't even know if the people I knew from Scotia would be there. I also couldn't make the second day of the competition, so I wasn't participating in a team, making it harder to talk to people when everyone already has a team.

That's what I thought going in, but I surprised myself by having an amazing time! I had fantastic conversations with competitors and panelists, stumped the CIO of Scotiabank (Head of Global Wealth, Investment Banking & Capital Markets Technology) with a "very good question", and was told by Scotia recruiters that I embodied the values that they want their interns to have. Needless to say, that was a wonderful day. I've done a full writeup of how that went, and think it's far more action packed than this weekly review, so will be linking that as another blog post :)

Video reviews - 2026-05-22

Note that these are my raw notes, included in this reflection as I decided not to give them their own blog post.

Watched a talk about someone who got laid off from Atlassian. He went over the entire architecture of developing a load balancing service that let people send simple requests, and handled the configuration, scaling, and balancing of their services. It was very informative, and cool seeing how many sections interact as well as the internal mechanisms of authentication, DDoS protection, and more play out within a service. He seems like a great guy, sharing non-technical lessons as well that I completely agree with. Managing different eprsonalities and conflict that inevitably shows up, what successful mentoring is, and how code churn (when new people come in and always want to refactor or improve the same sections of the code) is probably a code smell and how to deal with that so maintanability is possible. Both at Scotia and in InfraTech, maintainability is something I've foicused on, so it's reassuring to have an experienced developer say what he did. It's a hard one because the business doesna't care about maintainability until it becomes a problem. Preventative work is "unsexy" yet so necessary. I could spend hours ensuring that a system is maintainable - I made sure to check that this is a system which will live for years and maintainability is a key trait rather than something I'm doing for my own satisfaction - and those hours seem wasted unless I have a manager who understands the need for it.

There's another keynote by David Pamas on AI software and regulation of AI and "other unstrustworthy software". He went into it saying that he hopes to get boo'd because he doesn't believe in AI and considers it untrusthworthy, where even the name itself is incorrect. Referencing that the Turing Test was called the "Imitation Game" by Turing himself, David says the AI should be called "Imitation Intelligence", or "II". That it merely imitates, but is not artificial. Furthermore, machines can often do things far more efficiently than humans if they are built to take advantage of their characteristics, so why are we making neural networks to simulate the brain? His example was in washing clothes, an "AI engineer" would simply make a robotic arm that uses the same clothing washers that a human would make. It's an interesting perspective because even after a course on Natural Language Processing and the basis of LLMs, I don't know what alternatives are out there. From what I can tell, we went with an architecture that models the brain and have built everything off it, from Transformers to ResNet. That said, even an imitation can be useful. Using Claude Code for web development, it is clear that it can quickly create new pages/features that match the style of the rest of the website extremely well, and require minimal tweaking. Just imitating the pre-existing development creates useful boilerplate that saves hours. Yet David's talk focuses on security and regulation, saying that we don't regulate software itself enough, and replacing the word "AI" with "automation" clearly shows that it should be regulated more and doesn't change the meaning of the following examples. For one, "AI can make serious mistakes". It is the same with automation, and the reason that automation is often held to a stricter standard, because there is no human verification.

This itself poses an interresting question. Many in software would probably argue that automation is safer than having it done by humans. Computers can't make mistakes if we tell them exactly what to do, right? Yet humans are error-prone, so shouldn't it be safer? Even at work, I automated tasks for the sake of reducing manual error. Yet my automation always ensured human oversight. Status emails with what occured so someone could manually fix it if the numebrs looked wrong. Reports at the end of the day to check that every task completed succesfully. Rather than being safer or less safe, I believe it comes down to the need for responsibility. A human must be responsible for errors, because you cannot blame a machine. And when errors can cost thousands of dollars, the need for strict verification becomes greater. I'm sure that's why "human-in-the-loop" systems have grown in popularity after the booming of AI software, because people realized that someone needs to be accountable.

I'll end this reflection with a funny screenshot from David's slides (which he mentioned in the video are okay for everyone to have access to)