Just published my third article in the DCDD series. This one clarifies where DCDD applies

Just published my third article in the DCDD series. This one clarifies where DCDD applies — and w...Just published my third article in the DCDD series. This one clarifies where DCDD applies — and w...

The network for creativity

Join 1.25M professional creatives like you

Connect with clients, get discovered, and run your business 100% commission-free

Creatives on Contra have earned over $150M and we are just getting started

Back to feedPost

crystal zhu

• Jan 5

Just published my third article in the DCDD series.

This one clarifies where DCDD applies — and where it doesn’t.

It’s not about vision or strategy.

It’s about keeping systems buildable when reality is messy.

https://medium.com/@crystalhyomin/dcdd-isnt-about-vision-it-s-about-making-systems-buildable-7fecd8be0a24

Technical Writing backendarchitecture systemdesign

medium.com

DCDD Isn’t About Vision — It’s About Making Systems Buildable

DCDD solves how to build, not why to build

Mateo Szymkowicz

max

• 2d

Building my own product, I keep doing the exact thing I warn founders about. Made a splash animation I loved. Watched it on a real device and it dragged. Told founders a hundred times: the first impression is a budget you spend in two seconds. The advice I give for a living is the advice I have to force myself to take.

Product Design UI Design UX Design

Kate Maricheva

• 19h

Is that the real preview? So brrright! 😉

Scott McLeslie

• 1d

Weekend build, real engineering lesson.

Spent a chunk of this year building Scottina, a diagnostics toolkit around a Raspberry Pi — CAN bus tooling, custom firmware, a little touchscreen dashboard. Fun stuff. But the interesting part this week wasn't hardware.

It was documentation. Specifically: what happens when you're pairing with an AI assistant across sessions and your source-of-truth docs quietly go stale. I lost a full day to three files disagreeing with each other about a CAN schema — no crash, no error, just silently wrong values downstream.

The fix ended up being a small five-step discipline (Distill → Harvest → Verify → Purge → Declare) for keeping scratch work and locked decisions from bleeding into each other. Wrote it up here, including the exact failure that caused it:

https://hackaday.io/project/206266-scottina/log/249906-the-day-scottina-prime-turned-into-three-documents-arguing

If you're doing any AI-assisted engineering work, the "which document does the agent actually believe" problem is worth thinking about before it costs you a day too.

hackaday.io

The day Scottina Prime turned into three documents arguing | Details | Hackaday.io

<p>Every earlier log in this series describes a piece of Scottina working. This one is about a piece of <em>process</em> that had to work first, before any of that code could get written without stepping on itself.</p> <p>Work stalled entirely, for a full day — not on a bug, but on not knowing which document to believe.</p> <figure><img class=“lazy” data-src=“https://cdn.hackaday.io/images/4529951786329534348.png”></figure> <h2><img class=“lazy”><img class=“lazy”></h2> <h2>The scene</h2> <p>Early on, README.md and CLAUDE.md laid out a CAN addressing and message schema — one that had worked before, on an earlier project. As real edge cases turned up on the bench, that schema needed a small rework. Small on paper. In practice, code built against the old schema didn't fail loudly — it produced silently corrupted values instead of a visible fault. Anything built without the new schema in mind still ran, just wrong. That surfaced as a string of errors with no obvious common cause, and panic mode followed.</p> <p>The overhaul that came out of that panic was thorough — except it left README.md and CLAUDE.md untouched, on the theory that the old schema was just a useful historical note, not something actively poisoning new work. It was poisoning new work. A later session picked up README.md and CLAUDE.md as ground truth, never checked whether a newer document overrode them, and rebuilt against

acream

pro

• Aug 8

Visualizing Blockchain Architecture by Animation

Thinking:I’ve always believed that art is a way of conveying information through the senses, and for me, the process of understanding how things work is the most essential part of it all. I deeply enjoy taking the concepts I’m passionate about and translating them into a language humanity intuitively understands—whether visual, auditory, or tactile—to create a genuine connection with people. This is what I truly love doing.

From conceptualizing the underlying blockchain principles to executing the final visual animation, every step of this project was completed entirely by myself.

Thank you all for taking the time to check it out!