Hi everyone,
I participated in the Swift Mentorship Program with a goal of submitting my first pull request to a Swift open-source repository. By the end of the program, that pull request was still ahead of me. Through conversations with my mentor, Demian, I had begun to change how I approached unfamiliar problems and checked my understanding.
Demian kept asking why, even when I thought I already knew the answer. Alongside the program, Jaeseong, a Tech Mentor at the Apple Developer Academy, helped me turn an overwhelming learning goal into questions I could investigate. I wanted to share how those mentoring experiences shaped my learning, especially for others who build apps with Swift and are curious about contributing.
Where I was getting stuck
Before the program, I had been building apps with Swift and SwiftUI, but I knew very little about Swift Evolution or how people collaborated on Swift open-source projects. When I found a repository that interested me, I was unsure where to begin. Should I read all the source code? How could I tell whether an issue was manageable?
Learning that documentation fixes and small clarifications can be useful contributions made getting started feel more approachable. I also learned to use the entry points a project already provides: its README, contribution guidelines, build and test instructions, and existing issues and discussions.
Running the tests before changing anything gave me a baseline. Reading discussions helped me understand the context around a problem. These steps gave me a more concrete starting point than trying to understand the whole codebase at once.
Even after doing this, I still struggled to choose my next step. Each unfamiliar concept seemed to lead to several more things I needed to study.
Jaeseong helped me give my learning a direction
I wanted to understand enough to contribute, but I could not tell what to study first or when I would be ready. Trying to learn every unfamiliar concept felt endless. I brought that uncertainty to Jaeseong and asked for help with my learning process.
Together, we used Challenge Based Learning (CBL), a framework we used at the Academy, to revisit my goal. On the whiteboard, we framed a question: How can I understand the open-source contribution process?
Working through this with Jaeseong helped me make the investigation concrete: contributing to an existing repository, creating an open-source project myself, and examining how issues, pull requests, documentation, packages, CI, testing, and code conventions fit together.
That conversation gave me a more specific goal: solve a small issue in an Apple or Swift open-source repository and apply what I learned about its structure and workflow to a Swift package for my Academy project. I could now connect what I was studying to something I wanted to do.
Putting that direction into practice
With this clearer direction, I decided to use my own project as a learning environment. I separated my app's design system into a Swift package and studied the concepts that came up along the way.
Initially, I assumed that making the code reusable would make it easier to maintain and probably improve performance too. Working through the separation made me question those assumptions. I had to think about products, targets, modules, dependencies, access control, and the boundary of a public API.
I also learned to ask what I meant by a performance improvement: build time or runtime? Which measurement would support the claim? Under what conditions?
Asking how another developer might use the package changed my perspective on API design. An exposed API or dependency could affect someone else's code, so future changes needed more care.
When Demian kept asking why
Later in the program, I studied SwiftUI diffing and stable identity in ForEach. At the time, I associated stable IDs with better performance, but I couldn't explain why.
Demian kept asking why. His questions pushed me to examine what I actually understood:
- Why does stable identity matter?
- How does SwiftUI associate views before and after an update?
- How is recreating a view value different from preserving its identity?
- What can I establish from the public interface and documentation?
- If I cannot inspect the framework's internal implementation, what evidence can support my explanation?
I could not immediately answer those questions. Working through them with Demian made me realize how much of my understanding rested on knowing a conclusion. To explain it, I needed to examine the mechanism, my assumptions, and the evidence available to me.
His questions stayed with me after our discussions. When I encountered a new concept, I began asking why it behaved that way, which parts of my explanation were verified, and which parts were inference. I also began asking whether I could reproduce the behavior with a small example.
That was a concrete change in how I learned: the questions Demian had been asking became questions I started asking myself. A familiar answer now gave me a starting point for further investigation.
Carrying those questions into a contribution
My next goal is to follow one small issue through the contribution process: understand its context, reproduce it locally, add a failing test where appropriate, make a focused change, and work through review.
I still want to strengthen my Swift fundamentals. Working on my package showed me that I can learn the relevant concepts while solving a concrete problem, without waiting until I feel prepared for every possible question.
Jaeseong helped me give a broad learning goal a direction. Demian helped me examine the reasoning and evidence behind what I thought I knew. I want to carry both into that next step: choose a problem I can investigate, then keep asking what supports my understanding as I work through it.
I'm grateful to @Demian, @j_sung_0o0, and everyone who makes the Swift Mentorship Program possible. Their guidance has given me questions I can keep using as I work toward my first contribution.
For other mentees and contributors: was there a question or conversation with a mentor that changed how you approached an unfamiliar problem? I'd be interested to hear about those moments.
