Proof of Work? Proof of Stake? Proof of SOMETHING is important, but how do we know what that is? First we have to know what we want from it.
Repetition is risky. Duplicate code may cause harm. Similar things offer opportunities to get things wrong in different ways. But I repeat myself.
Generous shibes fund tipjars to pay Core contributors for their work making regular Dogecoin releases. How are those tips disbursed to contributors?
The first release of libdogecoin is starting to get bindings for several languages. Here's how Perl's work.
The first release of libdogecoin is really important. Here's what a little free library means, and what it enables.
Doing the right thing in the right way is important. Good developers make it easy for other developers (including their future selves) to figure out just what they were thinking.
Want to earn passive income with Dogecoin in 2022? Beware; most options are scams. Here's how Dogecoin actually works.
Why do release notes need testing? Why do they matter? The answer may surprise you.
Before you can make something better, sometimes you have to figure out what makes it worse, and then stop doing that. Here's now Dogecoin PR 2934 came about.
What kind of power should cryptocurrency developers have? Who gets to decide what happens where? Also: why?
Doctor Who has power over space and time. What can the TARDIS teach us about testing code?
One rule of optimization: avoid needless work. Another rule: sometimes only a human can tell what's needless. Why PR 2974 matters.
Some changes suggest other changes, whether by exposing limitations of the existing design or revealing small improvements. Here's work in progress for managing maximum network connections.
Sometimes an easy change is a lot harder than it looks. Creating a setmaxconnections RPC command definitely was.
When you pay someone and they give you change, it goes back in your pocket. Right? Unless you wrote an embarrassing bug.
Uncertainty is the enemy, and sometimes it takes a long time to figure it out. What testing PR 2698 can teach you.
If you want to grow as a developer, let other people be better than you are. This goes double for working on community-based projects.
Warnings can seem annoying, but sometimes they point to mistakes. Other times, they point out missing improvements.
Building generic software that runs faster on specific hardware is tricky, but it's important.
The Dogecoin Core is a code fork of Bitcoin, via a couple of routes. Sometimes we can get new features from Bitcoin, but they're not free.
Misleading or wrong information is worse than missing data. It's better to show nothing than to confuse users.
Git uses Merkle trees just like blockchains do. Let's demystify what that exactly means for Dogecoin developers though: explaining branches to new developers.
A brief introduction to translations in the Dogecoin core.
Imagine a good micropayments system. What would we need? What if we already have one, just waiting for a little bit of glue?
Let's dig into the implementation of the new private key GUI import dialog in Dogecoin Core's PR 1856, and learn a few things along the way.
People often ask how to get started contributing to projects. It's better to ask why.
Smart developers get the computer to warn them if something looks wrong. Excellent developers make a habit of listening.
Why do code reviews matter? Things you can learn by looking at how projects decide what changes to include.
My Dogecoin PR to allow users to import private keys from the GUI had a flaw; it froze the GUI. That was fixable... eventually.
My first substantial contribution was a GUI change that was more work than it seemed. Here's some background on PR 1856.
Creating my first Dogecoin core PR, a small RPC command help text update.