what-to-code: A Curated List of Programming Project Ideas

what-to-code as a Source of Project Briefs

what-to-code solves an early-stage problem for programmers who know how to code but do not know what to build next. It is aimed at developers seeking a personal project, contributors looking for an interesting implementation, and maintainers who want to turn a short feature request into a pull request. The repository is not an application with a startup process, plugin API, or reusable library. Its value is editorial: it collects problems with enough detail to establish an intended user and, in many cases, a suggested command-line interface.

The catalog covers command-line programs, local libraries or daemons, desktop applications, games, improvements to existing things, reimplementations, Vim functions, websites, and services. That breadth is useful for someone looking for variety, but it also creates an important boundary. A line in the README is a proposal, not a product with documented behavior. The repository contains only `CONTRIBUTORS.md`, `LICENSE`, and `README.md` at its top level, so consumers should not expect source code, tests, build definitions, or a shared library under `master`.

The contribution model is correspondingly lightweight. The README asks contributors to add their project heading and repository URL to `CONTRIBUTORS.md` if they complete one of the ideas. There are no documented issue templates, acceptance criteria, versioning rules, or automated checks for new entries. This makes the catalog easy to browse, but it leaves maintainers and adopters responsible for defining scope, licensing, compatibility, and completion criteria themselves.

Command-Line Ideas and Their Intended Interaction

The command-line section provides the clearest technical briefs. One proposal is `where-is`, which would search likely locations for configuration files. Its example uses a natural-language-looking query and returns paths such as `/boot/default/grub.d` and `/etc/grub.d`. Another is `leave`, described as the opposite of `rm`, with a C implementation requested.

Several entries go further by defining syntax and output. The proposed `dp` command would retrieve challenges from `reddit.com/r/dailyprogrammer` and print them to standard output. Its examples include selecting one challenge by number and difficulty, selecting all variants of a challenge, and requesting every easy challenge. The README also shows an invalid identifier returning a reported challenge-number error. This is a clear interaction contract, although the README does not document Reddit API access, authentication, rate limits, retry behavior, or an installation process.

The file-extension utility `ext` is given concrete examples for `hello.jpg` and `myfile.test.php`, with expected output containing `jpg` and `php`. The random-string generator `chars` would accept a length and return a string such as `gwrtp+5gl~`. The proposed `help` command is especially specific: it would inspect a flag such as `rg -g` and display the relevant help, manual, or information page.

These entries are best treated as product sketches. They identify the command name, input shape, and intended output, but not error handling, shell completion, cross-platform behavior, compatibility with existing utilities, or performance constraints.

CSS, HTML, SQL, and MIDI Analysis Concepts

The list also contains developer tools with more specialized inputs. A CSS design linter would inspect a file and report issues such as too many font sizes, multiple font families, excessive color values, inconsistent margins or padding, and non-standard media-query sizes. The README gives the proposed invocation as `css-lint style.css`, followed by diagnostic text. That is enough to understand the intended class of problems, but not enough to reproduce the project's eventual rule set.

The CSS and HTML regression testing idea follows a distinct data flow. It would visit a webpage on the current branch, capture a screenshot, visit the corresponding master branch or specified image, capture another screenshot, and compare them with ImageMagick. A difference would produce a warning and an image diff. PhantomCSS is mentioned as an existing option, while the README expresses a preference for an approach that is less dependent on Node. The README does not define browser versions, rendering engines, viewport sizes, fonts, timing, or how to reproduce stable screenshots.

A SQL parser is proposed for producing better error messages than MySQL's. Bison and Flex are named as likely implementation tools. The MIDI drum-track linter would inspect bars and identify issues such as impossible simultaneous hits, overly uniform hi-hat patterns, unrealistic tempo, and machine-gun snare dynamics. These are analyzers with explicit diagnostic goals, but the catalog does not define grammars, supported MIDI formats, thresholds, severity levels, or exit codes.

Building the List's Ideas Safely and Deliberately

The README does not give installation steps because what-to-code is not documented as a package or executable. It is presented as a repository to read and contribute to. A first real use is therefore to inspect the command-line ideas, select one narrow proposal, and define its behavior before creating any code. The `where-is` entry is a reasonable starting brief because its input and expected output are concise:

where-is grub config

The README says that this should produce a possible list of locations, including paths under `/boot/default/grub.d` and `/etc/grub.d`. A developer choosing this idea would still need to decide which operating systems and configuration roots to search, whether matching is fuzzy or exact, how permissions errors are handled, and whether results are sorted or ranked.

For contributors, the documented first action is to add a completed project heading and repository URL to `CONTRIBUTORS.md`. The README does not define a release workflow, pull-request template, or automated validation command. A proposed implementation should therefore state its supported platforms, test cases, security boundaries, and license in the implementation repository rather than treating the catalog entry as a complete specification.

The repository itself is under the MIT license. That license covers the repository's material, but it does not automatically settle the license of software a contributor later writes from an idea. Projects derived from or inspired by specific examples should preserve required notices and review their own licensing.

Repository Boundaries, Alternatives, and Maintenance

The most significant limitation is that the repository does not implement its own ideas. There are no releases, no installation target, and no documented compatibility matrix. The repository is not archived, and its last push was on 2026-08-11. That indicates recorded repository activity, but the README still describes several entries as ideas and asks contributors to build them.

A real alternative is to use an established tool in the same problem space. For CSS validation, the catalog's `css-lint` concept can be compared with a dedicated CSS linter rather than beginning from an unspecified implementation. For SQL diagnostics, a parser built with Bison and Flex would be a new implementation, while existing SQL tooling may already provide parsing or error reporting. For endpoint input testing, the README describes a template-based fuzzer that could issue requests with negative, empty, zero-padded, and very large integer values, but that idea belongs in an authorized testing environment. It is not a general-purpose attack tool and should never be pointed at a service without permission.

The repository is also different from a conventional curated list. It includes implementation preferences, such as C for `leave`, possible use of Bison and Flex for the SQL parser, and a preference for a less Node-dependent CSS regression tool. That editorial detail can help someone choose a project, but it can also bias the result toward the author's preferred technologies. The right comparison is therefore between a project brief and an existing maintained tool, not between what-to-code and another idea catalog.

Editorial conclusion

Independent developers, students, and contributors looking for a concrete exercise should adopt what-to-code as a source of briefs rather than as a dependency. Teams needing production software should not treat the list as evidence of an existing toolchain, API, or release process. Check the README, LICENSE, CONTRIBUTORS.md, and repository activity before assigning work, with the last recorded push occurring on 2026-08-11.

Frequently asked questions

Official sources

1. Issues
2. joereynolds/what-to-code on GitHub
3. License: MIT
4. README