Patrick did not start out wanting to be a software engineer. In high school he was drawn to physics, spending enough time on it to work through undergraduate-level material in competitions. But later he realized the part he enjoyed most wasn't physics itself. It was understanding how systems worked.

"During high school I was really interested in physics and mathematics. Around Grade 12, I realized studying physics at university wasn't what I was looking for. I wanted something more applied, so I chose computer science."

Computer science, to him, was mathematics with somewhere to go. He is less interested in what gets built than in how and why it gets built. That instinct defines almost everything Patrick does during his internship at Jurin AI.

Patrick had a plan for his co-op experiences.

"I wanted to start at startups so I could learn how to build new things, then eventually go to big tech to deepen my technical skills. In startups everyone is so busy that you don't always have time to learn from senior engineers, so you have to figure out a lot yourself.”

He had four offers when Jurin AI came into the picture. One startup felt too small. Another was paying well but where he heard interns mostly meet KPIs without learning much.

"I chose Jurin because Alex talked about it all the time. Great product, great culture, everyone's really nice. (Don't worry, he didn't leak any technical details.)”

Alex had done the same Waterloo co-op the term before and hadn’t stopped recommending Jurin since.

"During the first month I was spending a lot of time reading the codebase. I feel like I was not that productive because I shouldn't be doing that. I should focus on doing my tasks. I was sometimes just waiting for other people to tell me what to do."

The turning point came when he started paying attention to how the engineers around him actually worked. Nobody waited for work to arrive. Nobody finished their assigned task and stopped there. People naturally wandered through the product, noticed rough edges, and fixed them.

"After talking to more people I realized people are treating Jurin as their own project. When they have time they explore the app and see if there are places they can optimize. I wish I had that mindset earlier so I could have done more meaningful work."

Once he adopted that mindset, the work became much more interesting.

"I'm more like a fixer. When I dogfood the product, I naturally notice things I think we could improve."

That meant going deeper than the surface of whatever task he was given. When another engineer flagged something small, Patrick used it as a starting point to look at the broader codebase and identify areas worth improving. When he noticed a specific  feature could be faster, he pulled it apart to understand why and came up with a plan… then found another engineer had also started to work on the same thing, and jumped in to help instead.

Patrick's favorite quote comes from the mathematician John von Neumann:

"A method is more important than a discovery, since the right method will lead to new and even more important discoveries."

He likes it because it describes how he approaches engineering.

Patrick enjoys building features, but he's just as interested in understanding the systems they're built on. The better he understands how something works, the more confident he is changing it… and the more opportunities he sees to improve it.

One of the features he built during his internship was the working-hours system, giving every member configurable working hours and integrating them into escalation flows across the product.

"Previously members didn't have their own working hours. I built this and I'm integrating it into other features in the app, like escalation. The most important use case is for phone calls. We don't want to disturb someone at 1am. Working hours acts as a gate."

That same curiosity also showed up in the problems Patrick chose to spend time on.

One investigation took several weeks before he eventually traced the problem beyond Jurin’s own code to an unexpected bug in a third-party library.

"At first it seemed like a small issue, but I got curious and kept digging into it. Then I found that it was actually a bug in a third-party library we use, which is quite rare. I never expected the library itself to have a bug. After so many weeks I finally found it and we fixed it. That's maybe the thing I'm most proud of because I worked on it for a long time."

The same philosophy explains why he's opened more than ten pull requests that only add unit tests.

He laughs because he knows most engineers don't put that on a resume.

"Writing tests just doesn’t sound as impressive as creating new features. But if we have a deep feature with a lot of logic, the previous steps have their expected behavior. To make sure other people won't break what you worked out, you write a small unit test. Next time when someone breaks your function they'll see: did I want to break this intentionally or did I break it by mistake? Without unit tests you unexpectedly break what other people built."

Alongside feature work, he also contributed integration and end-to-end tests.

Patrick's understanding of engineering shifted significantly during the term. Different people changed how he thought about different parts of the craft.

From his team lead, he learned what it means to take design seriously.

"I spent two days on a feature and when I woke up he had changed everything I did. I was so sad. It turned out we had different concepts of design. Early on I didn't have much experience with structural design, so I just tried to stick to the existing conventions. But my team lead has a deeper understanding of the overall architecture and sees areas where the structure could be improved. He was like, 'I've always wanted to change this. I think it can be better.' That made me realize design is really important. You need a good understanding of both the technical side and the product to design something well.”

From a senior engineer, he got a different kind of perspective: someone who learned to code before AI existed and has had to rethink how he works as the tools change.

"I learned more about how we should use our own knowledge while also using AI as a tool. He came from a time when there was no AI. I discussed with him how he programs now that AI exists. He said AI is the equalizer. There are really good engineers and really bad engineers, but after using AI the bad ones have to become better. But design and understanding the product, that's still the human part.”

Patrick agrees that AI can help write code, but it still can't replace the judgment that comes from understanding a product, making design trade-offs, and knowing why something should be built in the first place.

"I felt like knowledge was more important. After coming to Jurin I can feel the importance of culture."

One example is what Jurin calls the paranoid culture.

"Usually during the first three or four hours I'm 100% focused, but after I get tired the quality of my work becomes lower. If I have the paranoid mindset I push myself during the last two hours. It somehow helps me become more productive and keeps the quality of my work better.”

Another is the emphasis on getting things done.

"Everyone is trying to become efficient and productive during work. No one wastes time on meaningless meetings."

Over time, culture has stopped feeling like an abstract concept and started feeling like a collection of habits to Patrick. It changed how he approached his work, how he managed his time, and even how he thought about his own standards.

But there’s one cultural shift he’d like to advocate for: more in-person time. Jurin AI is almost entirely remote so he has only been in the office twice.

"I'd like to go to the office once every week so I can get to know people better. When you know someone well, communication becomes much more direct. Even brainstorming and technical discussions become easier. It’d just be much easier to communicate, I think.”

Patrick's working day doesn’t follow a conventional schedule. He wakes up around 11, works through the afternoon from a park or Starbucks, walks around Tokyo before dinner, rejoins the team for evening meetings, heads to the gym, then finishes the day with pull request reviews or a movie.

It is a rhythm built around a globally distributed team, and one that has taught him how to do deep work in short bursts across the day.

After a while, the schedule simply became normal.

"It's really fast-paced, so you learn a lot. Everyone is pushing things forward, but at the same time everyone is genuinely willing to help. It's a very productive place, but also a really good team to work with."

That combination of speed and support is what Patrick thinks he'll remember most at the end of his internship.