Write like a builder
Dein Ø'Lynn publishes practical, technical stories that help hardware engineers make better decisions. We value clarity, honesty, and hard-earned lessons.
Show the constraints
- • Start with the context and the hard limits
- • Describe your decision points and tradeoffs
- • Close with outcomes and lessons learned
Builder-to-builder
- • Write for engineers, not press
- • Be specific with numbers or measurements
- • Include the messy parts and fixes
Evidence wins
- • Photos of boards, rigs, or setups
- • Diagrams, BOM links, or schematics
- • Bench data, test logs, or results
Submission ready?
- ✓ Clear problem statement and goals
- ✓ Named constraints (cost, power, time)
- ✓ Measurable outcomes or test results
- ✓ Photos, diagrams, or schematics
- ✓ Links to artifacts (optional)
Ready to publish?
Start with the contributor guide and we'll help you shape the draft. We review every submission and provide editorial feedback.
Examples
What good looks like
"We needed sub-10ms latency for motor control. After testing three MCUs (STM32F4, ESP32-S3, Teensy 4.1), the Teensy hit 6.2ms average with a dedicated timer interrupt. Cost was 2x higher but saved us two weeks of optimization."
Why it works: Clear constraint, specific numbers, named alternatives, measurable outcome, honest tradeoff.
"We chose the best microcontroller for our project. It's really fast and has great performance. The results were amazing and our clients loved it. Highly recommend this approach."
Why it fails: No specifics, no measurements, vague claims, no evidence, reads like marketing.
Questions about guidelines?
We're here to help shape your draft. Reach out before you write or during the process.
Get in Touch