Dawid Ciężarkiewicz aka `dpc`

contrarian notes on software engineering, Open Source hacking, cryptocurrencies etc.

I really like the Urbit project. I don't know how long I've been following it now. It was definitely earlier than 2016 when I discovered it, probably even 2014.

I think #Urbit is fundamentally trying to address the right set of problems in a comprehensive, holistic way. The fact that the Internet is broken for anything but centralized silos. I am deeply enthusiastic and cheering for Urbit. I do want it to succeed!

But in this post, I'm going to focus on an honest critique. I've actually read a lot of interesting critique of Urbit over the years – all that I could get my hands on. Mine is going to be less ambitious, and mostly down to earth and pragmatic. I hope it won't come out to harsh.


Test runners/frameworks caused me a lot of grief over the years. It's part of the reason why really appreciate how standard #Rust test runner works. As usual with Rust, core developers, and the community at very least avoided the most common misfeatures and made the right thing to be the easiest and most natural thing to do.

That's why i recently (probably too abrasively) bashed an announcement of some new Rust testing library.

I've taken some time and collected a list of feature request, misfeature rants, that I just want to share.


This is a part of #altswe series, where I describe ideas for an alternative approach to software engineering.

I've been a part of teams between 3 and around 20 software engineers; in companies between 3 and thousands of employees. I have used corporate messengers, IRC, Hangouts, Slack and many other IM tools. After all of that, I think they are generally counterproductive.


This is an introduction page for the #altswe series, where I describe ideas for an alternative approach to software engineering.

I've been fortunate to work on software with a lot of smart and hard-working people, in a lot of cool places. And while the companies I worked for were often very different: their business, products, size, growth, etc., the way software engineering was organized, was actually very similar.

I feel like generally, we just keep doing things “as we did them at my previous company”, and very rarely anything truly different is being considered.

I'm a natural contrarian, and I'm always on the lookout for alternative approaches. I just couldn't help myself but to develop a list of things that I really wish I could have an opportunity to try one day.

If I am ever in charge of a team or a company, I'd like to try some or even all of them, and see how well (or bad) they work.

For now, I am just gathering them here, under the #altswe tag. The ones without a link, are yet to be written.

  • Kill Instant Messaging – less is more.
  • Less is more – cut unnecessary tools, projects, features.
  • Work in pairs
  • 4x7 – 4 days a week, 7 hours – again: less is more.
  • No Scrum, No Standups, No “Wish Points”
  • Ownership – Root of safety in Rust, prosperity in the markets, and quality in SWE.
  • Avoid success at all cost

or: Notes on indexing blockchains

A copy of this post can be found on rust-bitcoin-indexer wiki.

Abstract: I have ventured on the quest of discovering the best way to index a blockchain. Surprisingly little has been written about it, considering that it is a common task for any organization handling blockchain-based interactions. It seems that, it is an area dominated by in-house solutions, with very little knowledge sharing. In this post, I go over the problem, ideas, discoveries, and experiences. I also describe a Bitcoin Indexer implementation that I have worked on while researching the subject: rust-bitcoin-indexer.

I expect the reader to be familiar with at least the basics of Bitcoin.

Please note that this is not scientific research and only a spare-time project. Feel free to contact me with comments: pointing out any mistakes and ideas for improvements.


or: A token (even smart one) needs a blockchain, like a fish needs a bicycle.

Tokenizing assets on a Blockchain

Image above: Tokenizing assets on a Blockchain


In this post, I explain why I believe Blockchains are just coincidentally associated with “token economy” and smart contracts, and how in essence they are not their enablers, but actually a hindrance. Then I propose an alternative: a concept of an open, federated smart contract system, that maintains all the benefits traditionally associated with blockchain platforms like Ethereum and can practically support a global scale token-economy, without all the problems inherent to blockchain-based systems.


Today, I'm going to give a contrarian view on tests and testing in software.

From my experience, the most common view on software testing is: “Tests! Tests! Always have tests! Start with a test! End with a test! More tests – good! Less tests – bad! 100% coverage! Test everything! How can you not have tests everywhere?!” ...

... or its opposite-side tween: “Tests? Why bother? Maybe later.”

Before I go any further, a note for the typical distracted reader, that is going to skim over the text, misunderstand it, and go rage over social media how stupid the author of this post is: I'm not saying that tests are bad. I'm going to focus on the bad side, but that is not the only side. Go read somewhere else about the good sides.


I am a crypto-finance enthusiast and though I am strongly skewed toward Bitcoin maximalism, I still try to follow the space looking for promising technologies and ecosystems.

One of the coins that really caught my interest was Grin

  • It has no fishy business (pre-mine, dev-taxes),
  • is written in #Rust (which, I think, is a perfect language for #cryptofin),
  • it is based on MimbleWimble which is a very promising tech improving blockchain scalability.

It ticks all the boxes to be a reasonable altcoin.

The only problem with it is it's controversial monetary policy. Basically: one coin, every second, forever. While I don't mind the “forever” part, the problem with Grin's monetary policy is the steady and long initial inflation rate.


Code reuse in Rust

In my opinion, one of the biggest reasons why Rust is so productive is that it's a superb language for code reuse.

First, ownership and borrowing system allows exposing in the API properties that are often impossible to express in other languages. The fact that the API communicates and enforces how the resources are being created, shared and moved and destroyed, all checked at the compilation time, gives the user great confidence that they are using any API – internal or external – correctly.

Second, Rust comes with first-class built-in tooling around discovering, creating, sharing and using publicly available Open Source libraries. It's not a property unique to Rust, but it builds a powerful synergy when combined with the first point.

Third, the community (at least so far), were strongly encouraging uniformity and commonality: similar code style, similar documentation style, common core libraries, and patterns. A big chunk of this effort was achieved through great tooling like rustfmt and clippy. Thanks to this, Rust ecosystem does not feel fragmented. Jumping into a code authored by someone else does not feel like a venture into a foreign land, as it often does in other programming languages.

Together, this properties creates a language and ecosystem where code reuse is almost effortless. While in other languages it's often more tempting and more convenient to implement things yourself and avoid learning a new API, in Rust the difference between own and 3rd party code, often blurs completely. In a way, this creates a completely new quality of building your software.

Despite all these strengths, there's one problem that sticks out like a sore thumb: trust. Every additional dependency is another piece of code that could be buggy, or even malicious. And in my opinion, it's problem so serious, that is entirely blocking the untapped potential of code reuse in Rust.