Tell the story of your capstone and your 100 days
Turn 100 days of Solana into a DEV article that shares your biggest lessons with the developers who come next.
Tell the story of your capstone and your 100 days
The final challenge of the program requires zero lines of code. Yesterday you completed your capstone. Today you step back from the individual transactions, tests, programs, and debugging sessions to ask a more important question: what did these 100 days actually teach you?
Your task is to publish an article on DEV that shares what you learned. You might tell the story of the full program, from your first unfamiliar command to your capstone deployment. Or you might focus on the single lesson that changed how you think about Solana, blockchain development, or software engineering more broadly.
The scenario
Technical documentation explains how a system is supposed to work. A developer’s account of learning it explains what it is actually like to understand.
Over the past 100 days, you have dealt with unfamiliar terminology, new mental models, failed transactions, confusing errors, security constraints, testing decisions, deployment risks, and tools that probably made much less sense on first contact than they do now. That experience is valuable because it contains the context that documentation often leaves out.
Perhaps you learned that accounts are more fundamental to Solana than programs. Perhaps PDAs finally made sense after you stopped thinking of them as ordinary wallet addresses. Perhaps testing an exploit taught you more about security than reading a list of best practices. Perhaps the biggest lesson had nothing to do with Solana at all: how to keep building when you do not yet understand the whole system.
Today you turn that experience into an article another developer can learn from.
The challenge
What you’ll need
- A DEV Community account
- Your previous challenge submissions, notes, commits, screenshots, and recordings
- Your Day 99 capstone repo and devnet Explorer link, where relevant
- Time to look back across the program before deciding what your article is really about
Steps
-
Review your 100 days.
Look back through your challenge submissions, commits, screenshots, and notes. Do not just collect the things that went well. Pay attention to moments when your understanding changed: concepts that took several attempts to grasp, assumptions you had to discard, bugs that revealed how Solana really works, or techniques you expect to use again. -
Choose the shape of your article.
Your article can take one of two broad approaches:- The full journey: Explain how your understanding developed over the 100 days, using a small number of important milestones to give the article structure.
- One important lesson: Focus on the concept, mistake, or realisation that mattered most, and use examples from the program to explain why.
A complete diary of all 100 challenges will probably be less useful than a considered account of the moments that changed how you think.
-
Decide who the article is for.
Write for a developer who is roughly where you were at the start. They might know Web2 development but be new to Solana. They may understand basic blockchain concepts but have never deployed a program. Keep that reader in mind when deciding what needs explanation and which details can be left out. -
Give the article a clear argument.
Before you start writing, complete this sentence:> After 100 days of learning Solana, the most important thing I understand now is…
You do not have to use that sentence in the published article, but you should know the answer. It will stop the post becoming a loose collection of events.
-
Use specific moments as evidence.
Support your reflections with things that actually happened. You might include:- A concept you misunderstood at first
- A transaction or test that failed
- A security flaw you learned to recognise
- A point when the Web2 analogy helped, or stopped being useful
- A challenge that changed how you approached later work
- Something your capstone allowed you to combine for the first time
Include code, screenshots, diagrams, repository links, or Explorer links where they help the reader understand the lesson. Do not add them only to prove that you completed the work.
-
Explain what you would do differently.
Useful learning articles include hindsight. What would you tell yourself on Day 1? Which topic deserved more attention? What approach wasted time? What made a difficult concept finally click? Be honest without turning the article into a list of complaints. -
Connect the learning to your capstone.
Briefly explain what you built for Day 99 and how it reflects what you learned. Include the GitHub repository and devnet Explorer link if they help readers inspect the project. The capstone is evidence of the journey, but it does not need to be the entire subject of the article. -
End with what comes next.
Explain how you plan to use what you learned. You might continue developing the capstone, enter a hackathon, explore a particular part of Solana in more depth, contribute to an open-source project, or help answer questions from developers starting behind you. -
Publish the article on DEV.
Give it a title that tells readers what they will learn, rather than simply announcing that you completed the program. Add thesolana,webdev, and100daysofsolanatags, along with any more specific tag relevant to your subject. -
Read and respond to other Day 100 articles.
Read at least two articles from other participants and leave a specific comment on each. Mention an idea you found useful, a lesson that matched your experience, or a point that made you reconsider your own understanding.
A possible structure
You do not have to follow this exactly, but it may help you get started:
-
Where I started
What you knew about Solana before the program. -
What I expected
The assumptions you brought from Web2 or other blockchain development. -
What changed my understanding
The most important challenge, mistake, concept, or milestone. -
What I understand now
Explain the lesson clearly enough that another developer can use it. -
How it appeared in my capstone
Show how the learning influenced what you built. -
What I would tell another developer
Practical advice based on your experience. -
What comes next
The direction you plan to take after Day 100.
What just happened
You turned 100 days of activity into knowledge another developer can use.
During the program, your progress was spread across individual challenges: a wallet here, a token there, a failed test, a successful deployment, a security constraint, an agent run. Each task taught you something, but the lesson was not always obvious while you were completing it.
Reflection connects those separate experiences. It helps you identify which mental models survived contact with the real system, which mistakes were productive, and which ideas now feel obvious only because you spent weeks learning them.
Publishing that reflection makes it more valuable. Other developers can compare it with their own experience, challenge your conclusions, and avoid mistakes that took you several days to understand. You also create a record you can return to later, when the details of the program are no longer fresh.
One hundred days ago, Solana was unfamiliar territory. Today you have built, tested, secured, deployed, and connected real programs. More importantly, you can now explain what you learned and why it matters.
Resources
- DEV Community: publish your Day 100 article here
- Writing a Post on DEV: open a new DEV draft
- Solana Explorer (devnet): link to your capstone program or relevant transactions
- Solana Developers: continue learning after the program
- Solana Stack Exchange: ask and answer technical questions from the community
Submission
Publish your article on DEV using the #100daysofsolana tag and submit the article URL below.
Your article should either reflect on what you learned across the full 100 Days of Solana program or explain the single most important lesson you are taking away from it. Include your capstone repository or devnet Explorer link where it supports the story.
Submissions are only open during the event.