Why Did I Start Writing Bad Code on Purpose?

If you started writing bad code on purpose, it may be a deliberate experiment rather than a sign that you have lost your skills. Developers intentionally make code awkward, inefficient, or incorrect to learn, test tools, demonstrate a problem, or explore how software behaves—but the reason and the safeguards matter.

What “bad code on purpose” can mean

“Bad code” is not one precise category. It can mean code that is hard to read, needlessly complicated, inefficient, fragile, or simply wrong. A person may deliberately introduce one of these qualities while keeping the others under control. For instance, a programmer might write a correct function in an unnecessarily verbose style to compare it with a clearer version.

There is also a difference between code that looks inelegant and code that produces incorrect results. A long solution may still be reliable; a short one may hide a serious bug. Calling code “bad” without identifying the specific property makes it difficult to learn from the exercise or assess its risks.

Deliberately awkward: valid code made harder to understand so it can be refactored or discussed.
Deliberately inefficient: a slow approach used to compare performance with a more suitable algorithm.
Deliberately faulty: a controlled defect used to practise debugging or test whether a check catches it.
Playful or experimental: code written for humor, exploration, or a constrained programming challenge.

Why developers do it

A common reason is learning. It can be easier to understand a good practice after seeing the problem it prevents. Someone learning refactoring might first write a function with repeated logic, then extract the repeated parts. A student studying algorithms might compare a simple nested-loop search with a more efficient approach on the same data.

Intentional defects are also useful in debugging practice. A learner can add a small, known mistake to a private exercise and then trace the program’s behavior. In testing, a developer may alter a program temporarily to see whether tests notice a changed result. This is related to mutation testing: tools or people make small changes, or “mutations,” and check whether the test suite detects them. A mutation that passes all tests may reveal a gap in the tests, though it does not by itself prove that the software is defective.

Other motivations are less formal. A person may be joking, participating in a deliberately constrained challenge, exploring a programming language, or making a teaching example memorable. The surrounding context matters: a rough prototype written for a short-lived experiment has different expectations from code that other people must maintain.

How to make the experiment useful

Choose one property to investigate and state it plainly. “Make this harder to read” is too broad; “repeat this calculation in three places, then measure how a refactor changes the code” gives the exercise a target. Keep the original version so you can compare the before and after, and write down what you expect to learn.

Use a disposable setting. Work in a local branch, a scratch file, or a small teaching project—not in a live service or shared production code.
Limit the change. Introduce one clear example of the issue instead of making unrelated changes throughout a project.
Check behavior. Run relevant tests or use a small known input and expected output. For performance experiments, use repeatable inputs and compare like with like.
Explain the intent. Add a note, commit message, or exercise prompt that says the code is intentionally awkward or faulty.
Restore or improve it. Revert the experiment or refactor it into the desired form, then rerun checks.

For example, suppose a program calculates the total cost of a small set of items. You might deliberately repeat the tax calculation to demonstrate duplication. First verify that both versions return the same results for representative inputs; then extract the repeated calculation and rerun the tests. The point is not that duplication is always wrong, but that this example lets you examine how a change can be made in one place rather than several.

Risks and common misunderstandings

The biggest practical risk is that an experiment escapes its intended setting. A deliberately broken change can affect a teammate, damage shared data, or be mistaken for an accidental defect. Avoid trying this in production, on someone else’s project without permission, or against systems you do not control. Don’t use real credentials or sensitive information in a scratch exercise, and don’t deploy code whose behavior you have intentionally compromised.

Another common misunderstanding is that “bad” means “unprofessional” or that all inefficient code is automatically harmful. Learning often involves trying an inferior approach in a safe setting. Conversely, code that runs successfully once is not necessarily correct, clear, or robust. Tests cover only the cases they check, and a performance result from one machine or input size may not generalize.

There is no single universal measure of code quality. Readability, correctness, performance, maintainability, and fit for purpose can pull in different directions. A deliberately awkward example is most useful when you name the tradeoff under discussion rather than treating style preferences as objective rules.

When to stop and how to recover

If the experiment is in a version-controlled project, inspect the changes before sharing them. Keep only the intended teaching or testing change; revert unrelated edits. If you are unsure what changed, compare your working copy with the last known-good version before committing or deploying anything. A branch or saved copy makes recovery simpler, but it is not a substitute for reviewing the result.

If you wrote messy code because you were tired, rushed, or frustrated rather than as a planned exercise, that is a different situation. You do not need to label yourself a bad programmer. Pause, identify the smallest behavior that must work, add or run a focused test, and improve the code in manageable steps. If the code is important to others, ask a colleague to review the changes before release.

Frequently Asked Questions

Is writing bad code on purpose a normal way to learn?
It can be a useful exercise when the goal is clear, the code is isolated, and you check what changed. It is not necessary for every learner, and it should not be confused with shipping knowingly defective software.

Does bad code mean I am a bad programmer?
No. A particular piece of code can be awkward or contain a bug without defining your ability. Developers at every level write imperfect drafts; review, testing, and revision are part of programming.

Can intentionally broken code help me learn debugging?
Yes, a small known defect can provide practice tracing causes and verifying a fix. Keep it in a controlled exercise, record the expected behavior, and restore or correct it afterward.

What is the difference between messy code and buggy code?
Messy code is often difficult to read or change; buggy code behaves incorrectly for at least one relevant case. They can overlap, but neither automatically implies the other.

Should I commit deliberately bad code?
Only when the repository and collaborators are meant to contain it, such as a clearly labeled teaching exercise or test. Explain the intent and avoid merging it into a release branch or deploying it as production code.

How do I make bad code better?
Start with observable behavior: write or run tests, then improve one issue at a time. Reduce duplication, clarify names and structure where appropriate, and rerun the checks to confirm that the behavior remains correct.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →