Malika's Blog

Dark mode: Manual Signature Implementation

 Light mode: When there is no added signature

Reaching the midpoint of this project feels like a good moment to pause, not because the work is slowing down, but because I finally have enough context to see the bigger picture.

At the start, everything felt new: the codebase, the community, the workflow, and even the way problems are framed in open source. Now, halfway through, things are starting to connect.

Where I Started

When I began working on Papers, my main focus was understanding the codebase and how contributions actually happen in a real open-source project. Reading unfamiliar code, following discussions, and figuring out where my work fit into the larger system was challenging.

Early on, progress felt slow. Tasks that seemed small took longer than expected, mostly because I was learning how the project works, not just what to code. But that foundation has been critical.

Photo: Build failure I encountered during development

What I’ve Accomplished So Far

At this midpoint, I’m much more comfortable navigating the codebase and understanding the project’s architecture. I’ve worked on the manual signature feature and related fixes, which required carefully reading existing implementations, asking questions, and iterating based on feedback. I’m now working on the digital signature implementation, which is one of the most complext part of the project and builds directly on the foundation laid by the earlier work.

Beyond the technical work, I’ve learned how collaboration really functions in open source:

• How to communicate progress clearly
• How to receive and apply feedback
• How to break down problems instead of rushing to solutions

These skills have been just as important as writing code.

Challenges Along the Way

One of the biggest challenges has been balancing confidence and humility, knowing when to try things independently and when to ask for help. I’ve also learned that progress in open source isn’t always linear. Some days are spent coding, others reading, debugging, or revisiting decisions.

Another challenge has been shifting my mindset from “just making it work” to thinking about maintainability, users, and future contributors. That shift takes time, but it’s starting to stick.

What’s Changed Since the Beginning

The biggest change is how I approach problems.

I now think more about who will use the feature, who might read this code later, and how my changes fit into the overall project. Thinking about the audience, both users of Papers and fellow contributors, has influenced how I write code, documentation, and even this blog.

I’m also more confident participating in discussions and expressing uncertainty when I don’t fully understand something. That confidence comes from realizing that learning in public is part of the process.

Looking Ahead

The second half of this project feels more focused. With the groundwork laid, I can move faster and contribute more meaningfully. My goal is to continue improving the quality of my contributions, take on more complex tasks, and deepen my understanding of the project.

Most importantly, I want to keep learning about open source, about collaboration, and about myself as a developer.

Final Thoughts

This midpoint has reminded me that growth isn’t always visible day to day, but it becomes clear when you stop and reflect. I’m grateful for the support, feedback, and patience from GNOME community, especially my mentor Lucas Baudin. And I’m so excited to see how the rest of the project unfolds.

When I started writing this blog, I didn’t fully understand what “think about your audience” really meant. At first, it sounded like advice meant for marketers or professional writers. But over time, I’ve realized it’s one of the most important lessons I’m learning, not just for writing, but for building software and contributing to open source.

Who I’m Writing (and Building) For

When I sit down to write, I think about a few people.

I think about aspiring developers from non-traditional backgrounds, people who didn’t follow a straight path into tech, who might be self-taught, switching careers, or learning in community-driven programs. I think about people who feel like they don’t quite belong in tech yet, and are looking for proof that they do.

I also think about my past self, about some months ago. Back then, everything felt overwhelming: the tools, the terminology, the imposter syndrome. I remember wishing I could read honest stories from people who were still in the process, not just those who had already “made it.”

And finally, I think about the open-source community I’m now part of: contributors, maintainers, and users who rely on the software we build.

Why My Audience Matters to My Work

Thinking about my audience has changed how I approach my work on Papers.

Papers isn’t just a codebase, it’s a tool used by researchers, students, and academics to manage references and organize their work. When I think about those users, I stop seeing bugs as abstract issues and start seeing them as real problems that affect real people’s workflows.

The same applies to documentation. Remembering how confusing things felt when I was a beginner pushes me to write clearer commit messages, better explanations, and more accessible documentation. I’m no longer writing just to “get the task done”. I’m writing so that someone else, maybe a first-time contributor, can understand and build on my work.

Even this blog is shaped by that mindset. After my first post, someone commented and shared how it resonated with them. That moment reminded me that words can matter just as much as code.

What My Audience Needs From Me

I’ve learned that people don’t just want success stories. They want honesty.

They want to hear about the struggle, the confusion, and the small wins in between. They want proof that non-traditional paths into tech are valid. They want practical lessons they can apply, not just motivation quotes.

Most of all, they want representation and reassurance. Seeing someone who looks like them, or comes from a similar background, navigating open source and learning in public can make the journey feel possible.

That’s a responsibility I take seriously.

How I’ve Adjusted Along the Way

Because I’m thinking about my audience, I’ve changed how I share my journey.

I explain things more clearly. I reflect more deeply on what I’m learning instead of just listing achievements. I’m more intentional about connecting my experiences, debugging a feature, reading unfamiliar code, asking questions in the GNOME community, to lessons others can take away.

Understanding the Papers user base has also influenced how I approach features and fixes. Understanding my blog audience has influenced how I communicate. In both cases, empathy plays a huge role.

Moving Forward

Thinking about my audience has taught me that good software and good writing have something in common: they’re built with people in mind.

As I continue this internship and this blog, I want to keep building tools that are accessible, contributing in ways that lower barriers, and sharing my journey honestly. If even one person reads this and feels more capable, or more encouraged to try, then it’s worth it.

That’s who I’m writing for. And that’s who I’m building for.

There’s a quiet assumption that once you’re accepted into a program, an internship, or a new opportunity, things are supposed to click. That confidence should come automatically. That the struggle somehow ends at the door.

It doesn’t.

Lately, my struggle has been feeling like I should already know more than I do.

I’m an intern working with a large codebase that was unfamiliar at first. On the surface, everything looked final, I read the documentation, followed discussions, and tried to understand the flow. But when I began contributing, I realized that understanding a codebase and working inside it are two very different things. Functions referenced other functions I had not seen. Libraries behaved in ways I didn’t fully understand yet. I spent hours chasing what seemed like a simple issue, only to realize I misunderstood something basic.

What makes this harder isn’t just the technical difficulty, it’s the voice in my head. The one that says, “Everyone else gets this faster.” The one that whispers, “You’re behind.” The one that asks, “What if I disappoint the people who believed in me?”

That voice is convincing. Especially when you’re surrounded by smart people who ask sharp questions and navigate complex topics with ease. It’s easy to compare your confusion to their clarity and conclude that the problem is you.

But here’s what I’m slowly learning: struggling is not a sign of failure. It’s a sign of being in the right place.Every time I get stuck, I’m forced to read more carefully. Every time I ask a question, I learn something I wouldn’t have learned alone. Every mistake shows me how the system actually works, not how I assumed it worked. The struggle is uncomfortable, yes, but it’s also doing real work on me.

I’m also learning the difference between struggling silently and struggling with support. When I finally ask for help, the response is rarely judgment. More often, it’s reassurance: “Yeah, that part is confusing.” Or, “I struggled with that too.” Moments like that remind me that nobody arrives fully formed.

Everybody struggles. Even the people who look confident. Even the people whose code you admire. The difference isn’t who struggles and who doesn’t, it’s who keeps going despite it.

So if you’re in a place where things feel hard, where progress feels slow, where doubt shows up uninvited: you’re not alone. This is part of learning. This is part of growing. And this, too, counts as progress.