Build in silence. Share what you did after November.
When a developer completes a significant task - merging a pull request, resolving a complex bug, or validating a new prototype - there is often an immediate opportunity to share that achievement. A screenshot on a social media platform, a commit message on a public repository, or a status update in a community channel are all standard ways to signal progress.
Public sharing serves several concrete purposes: it provides a way to receive feedback, helps in finding collaborators, assists in documenting technical decisions, and can open up professional opportunities. These are important functions of a developer's public presence. However, there is a distinct difference between making progress and preparing that progress for a public audience.
At times, a useful piece of work can be shared immediately. At other times, reaching a meaningful conclusion takes days or weeks of investigation. An unfinished architectural decision, a rejected hypothesis, or a long debugging session may not produce anything suitable for a public update. When we feel the need to report every visible milestone, the time spent on the presentation of the work can sometimes overshadow the work itself.
No Ship November is a voluntary, independent experiment designed to explore what happens when we intentionally remove that pressure to report progress for one month.
The Experiment
From November 1 through November 30, 2026, participants are invited to select one specific focus - a project, a technical problem, a research question, or a new skill - and work on it without publicly sharing any intermediate progress or achievements related to that focus anywhere online.
No Ship November is an independent initiative and is not organized, sponsored, approved, or endorsed by DEV.
The central question of the initiative is: “What changes when you spend a month working on something without turning intermediate progress into public announcements?”
This is an experiment, not a productivity method with a guaranteed result. You might find that you work with greater focus. You might also miss the feedback, discussion, or accountability that public updates can bring. Or you might notice little difference. Any of these outcomes is a valid result of trying the experiment.
Choosing Your Focus
Choosing a focus shapes the experience of the experiment. There is no expected outcome. Work on your chosen focus as you normally would, without publicly reporting its progress, and see whether anything changes for you.
The focus can be a small task, an investigation, a learning goal, or a larger project. It does not need to lead to a public release or a completed product. A suitable focus should be specific enough to navigate easily, but broad enough to allow for genuine exploration. Here are several examples of what a participant might choose:
- Investigating an intermittent bug: Spending the month trying to reproduce and understand a "flaky" issue whose cause is currently unknown.
- Comparing system architectures: Evaluating two different designs (e.g., comparing different database schemas, message brokers, or microservices patterns) before committing to one.
- Deep learning and research: Studying an unfamiliar protocol, a complex compiler, or a new library deeply enough to form an independent technical opinion.
- Improving neglected subsystems: Refactoring a "boring" part of an existing codebase - the kind of work that rarely makes for a good screenshot but significantly improves system health or maintainability.
- Building a "throwaway" prototype: Creating a proof-of-concept to test a specific idea that may be discarded entirely after the first tests.
- Exploring a research question: Collecting evidence for or against a specific technical hypothesis.
A participant does not need to disclose their exact goal publicly. If you wish to join the experiment, a simple comment such as “I’m in” is sufficient to signal your intention.
The Rules
To ensure a consistent experience for all participants, the following rules apply during the month of November.
Rule 1: One chosen focus
The experiment applies to one selected project, problem, question, idea, or learning goal. It does not suspend your entire public or professional life. You are not expected to stop all online activity.
Rule 2: No public progress updates
You must refrain from publicly sharing progress or achievements related to your chosen focus anywhere online during the month of November. This applies to all platforms, including but not limited to DEV.to, GitHub, X (Twitter), Reddit, and personal blogs.
Prohibited actions include:
- Pushing progress-related commits or repository updates to a public repository.
- Opening public pull requests or publishing project releases that reveal progress on the chosen focus.
- Posting screenshots, demos, videos, benchmarks, or milestone announcements.
- Publishing blog posts, technical write-ups, changelogs, or social media updates about the selected work.
- Sharing progress through public community channels or livestreams.
Note on Git: Local commits are permitted. A branch that exists only on your machine is not publicly visible. A private repository is another option. If you push a branch to a public repository, however, its contents are public regardless of the branch name.
Rule 3: Private work and communication remain allowed
This experiment does not require isolation. You may continue to code, research, run tests, and keep private notes. You can continue private conversations with collaborators, internal work communication, and any coordination your work requires. The experiment does not require isolation.
Rule 4: Unrelated public activity is allowed
You are free to remain active in the developer community. You can publish articles about unrelated projects, contribute to repositories that are not your chosen focus, and join discussions.
Example: If your focus is "Investigating a new database schema," you are prohibited from posting an update about that schema. However, you are perfectly free to post an article about a book you read on CSS, or contribute a typo fix to a popular open-source library that is unrelated to your focus.
Rule 5: Responsibilities come first
Participation in this experiment must not be used as an excuse to neglect professional duties. No one should delay security fixes, violate contractual obligations, mislead a customer, or withhold necessary information from collaborators because of the experiment.
If your work involves obligations that make a temporary pause in public progress updates inappropriate or risky, choose a different focus for the experiment. Necessary emergency and professional actions take priority over the experiment.
Rule 6: No mandatory completion or reporting
There are no "streaks," quotas, or required hours. You do not have to finish your project, write a retrospective, or publish a "final" result on December 1. There are no entry fees, prizes, points, badges, or leaderboards.
Who might find it useful?
The experiment can appeal to developers whose work naturally produces visible milestones, as well as to people whose work involves long periods of uncertainty.
For an early-career developer, a month might involve learning a new codebase or trying to understand a difficult concept. For these developers, the experiment might help them notice whether sharing new discoveries changes how they approach learning.
For an experienced engineer, the month might involve architectural investigation, refactoring technical debt, or evaluating competing designs. For these professionals, the experiment might explore how much "invisible work" - the work that keeps systems running but does not make for a great headline - actually occupies their time.
For a researcher, the month might involve testing assumptions before finding an answer worth presenting. They might observe whether the absence of public updates changes how they allocate time between investigation, analysis, and presenting intermediate findings.
Different kinds of work produce different kinds of progress. A new feature is easy to demonstrate; a rejected design, a better understanding of a failure mode, or an avoided mistake is much harder to turn into a public update. This experiment allows you to see what it feels like to hold onto that "invisible" progress for a while.
What counts as a result?
From December 1, 2026, onward, participants may share their results if they wish. A "result" does not have to be a polished, finished product. In fact, some of the most interesting results may be the ones that did not "succeed" in the traditional sense.
A result could be:
- A completed project or a working prototype.
- A technical article, a set of notes, or a clearer explanation of a concept.
- Evidence supporting or rejecting a research hypothesis.
- A benchmark or comparison of different approaches.
- A bug that was finally understood.
- A design that was deliberately rejected.
- A failed experiment that ruled out a promising idea.
- A project that remains unfinished but is now better understood.
- A simple account of what did (or did not) change during the month.
You are not required to provide evidence of your private work, share commit histories, or produce screenshots. You do not have to publish anything at all.
If you do choose to share, you might find it useful to reflect on these questions:
- Did the absence of public updates change what I chose to work on?
- Did I miss external feedback or accountability?
- Did I spend less time preparing demonstrations, or did that make no difference?
- Was it harder or easier to explain the eventual result?
- Would I use this approach for another project?
How to participate
The goal is to keep this initiative low-friction and free of bureaucracy. There are no registration forms, no application processes, and no community servers to join.
- Choose your focus: Pick one project, problem, or goal for November.
- Work within the rules: Follow the guidelines listed above throughout the month.
- Optional Check-in: You may leave a brief comment on this article before November to let others know you plan to participate.
- Share later: From December 1 onward, you can return to this article to share your result or your reflections on the experience.
Frequently Asked Questions
Is this against "building in public"?
No. Public development is valuable for feedback, networking, and collaboration. No Ship November is a temporary, intentional alternative to that practice for one specific focus for one month.
Can I continue committing code?
Yes. Local commits and private work are encouraged. The restriction is specifically on making progress about your chosen focus public.
Do I need to publish a result on December 1?
No. That is simply the earliest date allowed for sharing results. You can share whenever you are ready, or not at all.
Top comments (0)