Some of the most useful lessons I carry into software came from jobs that had nothing to do with software.
They came from a paper route as a kid, working my way through the kitchen at a restaurant, and running into QA for the first time during a co-op term at Waterloo. None of those experiences felt profound at the time. Mostly they felt tiring, inconvenient, or mildly annoying. But looking back, they shaped how I think about work more than I realized then.
Learning to be dependable
One of my first paid jobs was a paper route around my neighborhood.
On paper, it was not that much: a handful of streets, a stack to deliver, and a route to finish. In practice, when you are about twelve years old, it can feel enormous. I would head out in the rain, in the dark, walking house to house and stopping back at home to pick up more bundles. Some of the places were clearly seasonal homes, sitting empty while I dropped off one more paper that nobody seemed particularly eager to receive.
It did not feel meaningful. It did not feel rewarding. A lot of the time, it barely felt sensible.
But it was still my job to do.
I wanted to quit. I was wet, cold, and irritated, and every extra driveway made the route feel longer. Still, I kept doing it for quite a while, until I eventually moved on to restaurant work.
What stayed with me was not the idea that you should grind through anything without thinking. It was something more practical than that: being dependable often means doing ordinary work well, even when it is repetitive, inconvenient, or mostly invisible. Not every task will feel important in the moment. Not every contribution comes with instant feedback or obvious meaning. But learning to take responsibility for the work in front of you still matters.
That lesson has held up.
Not everything is about you
As a teenager, I worked at a restaurant and moved up gradually from dishwasher to pizza maker to fry cook to regular cook. Eventually I got the Sunday morning shift, where I would do prep work when things were quiet and jump in on breakfast or lunch when needed.
One morning, I rode my bike there around 8 a.m. and found the door locked.
I tried the other doors. Also locked. I did not have a key, and my boss was usually there before me, but he was not that day. I did not have a way to contact him, and I had no real fallback. I waited around for a bit, then rode back home because I genuinely did not know what else to do.
Later, my boss called. He was upset and wanted to know where I was. We argued. It got heated. Eventually he came to pick me up, and somewhere during that drive he made it clear that he was not really angry at me. He was angry at himself for not being there.
That stuck with me.
When people are frustrated, embarrassed, or under pressure, it often comes out sideways. In the moment, it is easy to hear that frustration as a direct indictment and jump straight into defending yourself. But not every sharp reaction is really about you. Sometimes you are just the nearest available target for a problem that started somewhere else.
That lesson has been useful in every kind of job I have had since. It has made me less defensive, but it has also made me more aware of my own impact. Stress has a way of leaking outward. If I do not manage it well, other people end up dealing with it.
That was true in a kitchen, and it is just as true on an engineering team.
Users do what users do
During an early co-op term at Waterloo, I worked on a form with standard fields like name and address. It seemed straightforward.
Then QA started logging bugs because the form allowed garbage text in places where it clearly should not. I remember pushing back. In my mind, the field was for a first name. Why would anyone type nonsense into it?
That was the first time I really understood what QA was doing.
They were not there to confirm that a careful user could move cleanly through the happy path. They were there to test the boundaries of the system, including the parts a developer might be tempted to dismiss as unrealistic. Real users mistype things. They paste unexpected values. They misunderstand labels. They skip steps. They do things in an order that seems strange from the inside but makes complete sense from where they are sitting.
In other words, they behave like real people.
That shifted something for me. Good software is not built around the assumption that the user will cooperate perfectly. It is built to handle reality with some grace. A system that only works when the user behaves exactly as you hoped is not robust. It is just brittle in a polite disguise.
Looking back
None of these moments felt especially important while they were happening. They were just jobs, shifts, and small frustrations. I was not trying to collect life lessons from them. I was just trying to get through them.
But they left marks.
They taught me that dependability matters, especially when the work is not glamorous. They taught me not to take every tense interaction personally, and to be careful about where my own stress lands. And they taught me that systems should be designed for real behavior, not ideal behavior.
I learned those things long before I had words like architecture, product thinking, or user experience. But they have probably shaped how I work just as much as anything I learned later.