Get Out of the Learning Loop and Do the Work: My Journey to Becoming a Btrust Grantee

When I first started learning about Bitcoin, I understood it as money. I knew it was a decentralized monetary network and that a lot was happening underneath the surface. What I did not understand was what any of that meant for me as a software developer.

Before Bitcoin, I was a software engineering student and backend developer, mostly taking on short-term gigs and freelance work. I had also moved between roles at a renewable energy startup, including business development and technical writing. I was still figuring out where I wanted to focus my skills.

Bitcoin eventually became the place where my interests in software development, energy, and open-source technology came together. But getting there meant learning to stop preparing indefinitely and start contributing.

Finding My Foundation

My first serious exposure to Bitcoin was through Dada Devs. I joined without a particular goal. It was mostly curiosity and, honestly, for the plot.

We worked through Mastering Bitcoin, and it was intense. We learned about transactions, UTXOs, scripts, digital signatures, blocks, and the peer-to-peer network. I quickly realized that Bitcoin was much more than I had initially thought.

The assignments helped me understand the technical concepts, but the discussions were probably even more important. I could read a chapter and think I understood it, only for someone to ask a question that revealed another layer I had not considered.

I did not understand everything immediately. But I kept showing up, doing the assignments, asking questions, and trying to explain concepts to other people. That became my first real foundation in Bitcoin.

After Dada Devs, I went through the Btrust Builders Python pathway. As someone who already had software development experience, I could start connecting what I was learning about Bitcoin with programming. Instead of seeing Bitcoin only as something to study, I began thinking about what I could build.

Finding an Exit from the Learning Loop

I explored different parts of the ecosystem. I built products, taught, and participated in communities like BitDevs NBO. But contributing to existing open-source projects was something I had not tried.

I was learning a lot, but I was also stuck in a loop. There is a point where learning becomes its own activity. You read another book, take another course, attend another workshop, or try another pathway because it feels productive. Meanwhile, the work you are preparing to do stays somewhere in the future.

But a loop without an exit condition never terminates. It keeps running, consuming resources, and never returning anything.

Sy from BitDevs was the person who told me plainly: at some point, you have to actually do the work. That advice stayed with me. When I joined Chaincode Labs’ Bitcoin Open Source Software (BOSS) Challenge, I decided to stop waiting until I felt ready.

I had been treating readiness as a prerequisite for contributing. Instead, I started working backward from the contribution itself. If I wanted to understand open-source Bitcoin development, I could start with a real issue, read the relevant code, ask questions, make a change, and learn through the process.

The BOSS challenge became my exit condition. We were required to build a portfolio project, so I built Know Your Coin History, a privacy-focused Bitcoin transaction graph explorer that allows users to audit and label their personal coin history.

Alongside the challenge, some of us from Dada Devs started an open-source accountability group. We shared our contributions, reviews, and progress. Having people to check in with helped, even as I struggled to find a project I could contribute to consistently.

I explored different parts of the ecosystem. I built products. I taught. I participated in communities like BitDevs. Open-source development was the part I never tried. I was learning a lot, but I was also stuck in a loop. There is a point where learning becomes its own activity. You keep reading another book, taking another course, attending another workshop, or trying another pathway because it feels productive. But a loop without an exit condition never terminates. It keeps running, keeps consuming resources, and never returns anything.

My First Merged Pull Request

My first open-source contribution was to Warnet, a tool for creating and interacting with Bitcoin networks in a controlled environment. I found an issue and left a comment. The maintainer, Pinheadmz, responded and gave me direction.

I ended up working on how Warnet handled external peers and .onion addresses. The changes involved detecting external peers, removing assumptions that every peer was a regular Warnet container, handling message-capture paths correctly, and fixing validation that could reject valid onion addresses.

It took about two months, but the pull request was eventually merged.

That contribution changed how I thought about open source. I had spent so long treating it as something I needed to be ready for. Now I had contributed a change to a Bitcoin-related project.

More importantly, I had learned how to enter an unfamiliar codebase, investigate an issue, communicate with a maintainer, respond to feedback, and stay with the work through to completion.

I did not need to understand the entire project before starting. I needed a specific problem to work on and the willingness to keep investigating. After that, I wanted to contribute more consistently.

Connecting Bitcoin, Mining, and Energy

Around this time, I was teaching myself Rust. Discussions at BitDevs were also making me increasingly interested in Bitcoin mining.

Mining felt like a natural direction to explore. I care deeply about electrifying Africa, and mining is one of the places where Bitcoin and energy intersect.

That interest led me to Braidpool, a project working on decentralized bitcoin pooled mining.

To understand why that matters, it helps to understand the problem mining pools solve. For a miner with relatively little hashrate, solo mining can mean a very long wait to find a block. Pools allow miners to combine their efforts and receive more predictable payments rather than depending entirely on finding a block themselves.

But conventional pools also concentrate coordination in the hands of pool operators. Depending on the pool’s design, operators can control block templates, assign work, account for shares, and distribute rewards. The hashrate may come from many independent miners, while important decisions remain concentrated at the pool level.

Braidpool aims to preserve the benefits of pooled mining without relying on a trusted central pool operator. Its design uses a directed acyclic graph, or DAG, to organize mining shares represented as beads. The payout mechanism remains an area of active research.

There was a lot for me to learn: mining pools, Stratum, mining jobs, shares, extranonces, block templates, coinbase transactions, and how miners communicate with pools.

I started reading the Braidpool code and gradually became more comfortable with its Stratum layer, the part involved in communication between mining software and the node.

That became the area where I began contributing. My work has included addressing scalability issues associated with supporting more than 10,000 miners, working on Stratum V2 integration, improving validation and error handling, and refining how mining jobs are stored and shared across connections.

These were concrete problems I could investigate while deepening my understanding of the system.

Learning Alongside the Work

I still learn constantly. I read documentation, study code, ask questions, and attend discussions. The difference is that learning now runs alongside the work instead of taking its place.

That shift eventually led to me becoming a Btrust grantee, giving me the opportunity to work full-time on open source and contribute to Braidpool.

The grant gives me time to stay with difficult problems, understand the project more deeply, and contribute consistently.

Outside my development work, I love teaching and making this journey easier for the people coming after me. I do that as a peer lead at Dada Devs, through BitDevs meetups, and through Hack4Freedom.

I know how valuable it is to have someone answer a question, help you understand unfamiliar code, or encourage you to take the next step. If I can help someone find their exit condition sooner than I found mine, that is worth it.

Start Before You Feel Ready

To anyone trying to get into Bitcoin or open source, my advice is simple: do not get stuck in the learning loop.

There will always be another tutorial, another book, another course, or another concept you think you need to understand before you begin. Learning matters. But you do not have to finish learning before you can contribute.

Build the project. Investigate an issue. Open the pull request. Ask for feedback. Fix a bug. Improve the documentation.

Join communities, ask questions, and let people see what you are trying to do. A contribution does not have to be large to be useful, and your first one does not have to define the rest of your career.

As Stephanie puts it, "Do the work and good things will happen."

I am a product of communities and the people in them. I am grateful to everyone who has supported me throughout this journey: Dada Devs, Btrust Builders, the BitDevs Nairobi community, and everyone who has taken the time to answer questions, have discussions, review my work, or simply encourage me to keep going.

And to the Braidpool maintainers, Bob McElrath, Mohd Zaid, and Ansh Sharma, thank you for building something worth contributing to. I look forward to seeing this protocol come alive and being part of the work behind it.