Write about what you learned

The Scenario

You have gone from zero to building real tokens on Solana. You created a mint, gave it a name and symbol with metadata, attached transfer fees at the protocol level, reinforced the full workflow end to end, and experimented with non-transferable tokens that act like permanent credentials. That is a lot of ground covered, and you now understand something that most Web2 developers never get to see: how a blockchain can enforce economic rules in code, not in policy documents.

But here is something every experienced developer knows. If you build something and never write about it, the details fade fast. The commands blur together, the “why” behind each decision gets fuzzy, and the lessons you learned the hard way disappear into your terminal history. Writing forces you to organize what you know, identify what you still do not fully understand, and create something that helps the next person avoid the same stumbling blocks.

Today, you are going to write a technical blog post on DEV Community documenting your token-building journey on Solana. This is not a homework assignment. It is a skill that compounds. Developers who write about what they build get noticed by teams, communities, and collaborators. Your post does not need to be perfect. It needs to be honest, clear, and useful.

The Challenge

What You’ll Need

• A free account on DEV
• Your code and notes from Days 29 through 33
• A text editor or the DEV built-in editor (supports Markdown with a formatting toolbar)

Steps

Step 1: Pick Your Angle

A good technical post is not a diary entry. It has a point of view. Before you start writing, decide on a single angle for your post. Here are a few options based on what you have built:

• “What I Learned About Token Design on Solana as a Web2 Developer”: Compare your expectations coming from traditional platforms with the reality of on-chain token mechanics.
• “Transfer Fees, Metadata, and Soulbound Tokens: A Tour of Solana Token Extensions”: Walk through the extensions you used and explain why each one exists.
• “From npm install to Minted Token: My First Week Building on Solana”: A step-by-step narrative of the progression from your first mint to non-transferable tokens.

Pick one of these or come up with your own. The key is having a clear throughline that a reader can follow.

Step 2: Outline Before You Write

Open your editor and sketch a rough structure. A solid technical blog post typically follows this pattern:

1. Hook: One or two sentences that tell the reader what they will get from the post and why it matters.
2. Context: A brief explanation of your starting point. What did you know before this? What were you trying to accomplish?
3. The walkthrough: The core of the post. Walk through what you built, include code snippets, and explain the decisions you made. This section should have subheadings.
4. What surprised you: Every honest technical post includes at least one moment where something did not work as expected or a concept clicked in an unexpected way.
5. What’s next: A short closing that tells the reader where you are headed and invites them to follow along.

Step 3: Write the Draft

Log in to DEV and click Create Post in the upper right corner. The editor uses Markdown, so you can format headings with #, code blocks with triple backticks, and lists with - or 1. characters. If you are new to Markdown, the DEV Editor Guide covers everything you need.

A few writing tips that make a real difference:

• Show your code. Include the actual commands and snippets you ran. Readers want to see working examples, not abstract descriptions. Use fenced code blocks with language hints (e.g., ```bash or ```typescript) for syntax highlighting.
• Explain the “why,” not just the “what.” Anyone can copy a command. What makes your post valuable is explaining why you used the Token Extensions Program instead of the original Token Program, or why non-transferable tokens solve problems that off-chain rules cannot.
• Keep paragraphs short. Three to four sentences maximum. Technical readers scan before they read, and dense blocks of text get skipped.
• Link to official sources. When you reference Solana concepts, link to the docs. Good starting points include Tokens on Solana, Token Extensions, and SPL Token Basics.

Step 4: Add Tags and Publish

Before you hit publish, add tags to help other developers find your post. DEV allows up to four tags per post. Good choices for this content include:

• solana
• blockchain
• webdev
• beginners

Set a cover image if you have one (even a simple screenshot of your terminal output works), write a short meta description, and publish. Your post does not need to be long. Anywhere from 500 to 1,200 words is a good range for a focused technical walkthrough.

What Just Happened

You just did something that separates builders from bystanders: you documented your work in public. That post now exists as a reference for you and for every other developer who searches for “Solana token extensions” or “how to create tokens on Solana” in the future. You contributed to the ecosystem, not just consumed from it.

Writing about code also reveals gaps in understanding. If you struggled to explain why the Token Extensions Program exists alongside the original Token Program, or why non-transferable tokens need to be enforced on-chain rather than in application logic, those are signals pointing you toward concepts worth revisiting. That is the hidden value of documentation: it is a feedback loop for your own learning.

In Web2, developers who write consistently build reputations that open doors. The same is true in Web3. The Solana ecosystem is growing, and the developers who take the time to explain what they are building become the ones others turn to for guidance.

Submission

Share the link to your published DEV post using the tag #100DaysOfSolana.