> Markdown version of [/magazine/529-the-importance-of-not-done](https://www.wearedevelopers.com/magazine/529-the-importance-of-not-done). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# The Importance of "Not Done"

**By:** [Daniel Cranney](https://www.wearedevelopers.com/@daniel-cranney)

**Published:** January 9, 2025

> “Move fast and break things”.

In the years since these words were first uttered by Facebook founder Mark Zuckerberg, the motto has become somewhat of a mantra among tech entrepreneurs, product builders and developers.

Zuckerberg, like many of his peers, believe that features - and software more generally - should be built and launched as quickly as possible, even if this focus on speed results in messy code, is disruptive to an industry, or goes against existing legal regulation.

To some, this is an attitude that allows developers to take products to market quickly, and with the greatest impact. To others, this approach undermines the tried and tested processes put in place by larger organisations to ensure code is clean and maintainable, security vulnerabilities are mitigated, legal requirements have been met, and tasks have been methodically managed, monitored, tackled and completed.

Here lies the issue.

The tech industry moves incredibly fast, and developers - and tech software companies in general - are challenged with finding the balance between quality and velocity; methodically building features and definitively marking tasks as complete, or focusing on speed and accepting that _completeness_ is a state that simply does not exist and so is futile to pursue.

In this article, we’ll consider whether projects - or features - are ever actually _done_, and the impact of mindset around this issue on the software that developers build.

## **The "Not Done" Philosophy**

At first glance, leaving projects incomplete might sound counterproductive.

Tasks are set in order to be completed, right? Well.. sort of.

For a long time now, the software industry has been dominated by the agile philosophy, which breaks down large tasks into smaller, more manageable ones, and gives teams a framework by which they can plan features, sprint to deliver them, reflect on their strengths and weaknesses, before iterating on them to improve them.

When that first cycle ended, was the first version complete? Or was the feature a long way from completion, when we consider what it will likely look a year from now.

In this context, projects are never complete, and represent ongoing opportunities for enhancement and innovation. They celebrate the process of constant learning and refinement, much like agile development.

### **It’s Done… But is it Done Right?**

The agile methodology might frustrate some who strive for the feeling of satisfaction that you get when a task is complete, and can be left behind. However, if we were to work in a way that prioritises giving developers - or team members - this emotional pay-off, the chances are they would rarely get it.

Agile allows teams to assess their product at certain milestones, and adapt, rather than following a fixed plan and ignoring signs that change is needed. Sure, it would be easier to check tasks off as complete, but they’re likely of very limited value compared to what was expected when the plan was first hatched. So change is good, right?

## **The Benefits of "Not Done" for Developers**

Adopting this mindset holds particular benefits for computer programmers and developers, many of whom are familiar with the notion of incomplete projects and iterations.

### Enhanced Creativity and Innovation

Accepting that a project is never finished opens the door for ongoing creativity. Developers can continuously improve and ideate, leading to more innovative solutions. In this sense, creativity doesn’t _stop_ when the plan is locked in.

### Improved Problem-Solving

Recognising what remains "not done" helps developers focus on real issues rather than getting sidetracked by secondary concerns. This clarity leads to more effective problem-solving.

### Holistic Growth

For many developers, it's not just about writing code but understanding the broader impact of their work. The "not done" mindset fosters a more comprehensive perspective, enhancing both technical and soft skills, meaning developers are less likely to be measured by the number of lines of code they wrote, or the tickets they checked off.

### Increased Satisfaction

Seeing work as a continuous journey rather than a destination reduces the pressure for perfection. Developers often find greater satisfaction in the iterative process, celebrating small victories as they come.

## **Conclusion**

For programmers and developers, embracing what is "not done" can be transformative, introducing new levels of flexibility, insight, and innovation into their work. This mindset not only complements agile development but also enriches the overall process, ultimately leading to products that better meet user needs.

### More on This Topic

[
 ![Thumbnail for Vladimir Chernikov's The Importance of Not Done](https://wearedevelopers.imgix.net/public/magazine/articles/529/images/677e4721592f6448ad125f53_677e4645b0d7b89cfb468e10_Not_Done_Thumbnail.jpeg?w=720&fit=max&dpr=2&auto=format)
](/videos/1091-the-importance-of-not-done)

To explore this philosophy further and see it in action, consider watching Vladimir Chernikov's intriguing talk, "The Importance of Not Done," where he dives into how _not_ completing tasks might actually help you get promoted.



## Related Articles

- [Get Old, go Slow, Write Code!](https://www.wearedevelopers.com/magazine/81-get-old-go-slow-write-code)
- [Ignore the Hype: How to Avoid Being Deceived by Technological Trends](https://www.wearedevelopers.com/magazine/528-ignore-the-hype-how-to-avoid-being-deceived-by-technological-trends)
- [The real reason we document our code](https://www.wearedevelopers.com/magazine/518-the-real-reason-we-document-our-code)
- [How to Avoid Over-Engineering](https://www.wearedevelopers.com/magazine/546-how-to-avoid-over-engineering)

## Related Videos

- [Get old, go slow, write code!](https://www.wearedevelopers.com/videos/343-get-old-go-slow-write-code)
- [The importance of "Not done"](https://www.wearedevelopers.com/videos/1091-the-importance-of-not-done)
- [Learning From My Side Project Mistakes](https://www.wearedevelopers.com/videos/1275-learning-from-my-side-project-mistakes)
- [But, you're not Facebook](https://www.wearedevelopers.com/videos/378-but-you-re-not-facebook)

## Related Jobs

- [Senior Software Engineer](https://www.wearedevelopers.com/jobs/ext/15942-senior-software-engineer) at **GitHub**
- [Mid/Senior Full-Stack Engineer (Web-first)](https://www.wearedevelopers.com/jobs/ext/1210833-mid-senior-full-stack-engineer-web-first) at **SMG Swiss Marketplace Group**
- [Lead Software Engineer (f/m/d)](https://www.wearedevelopers.com/jobs/48296-lead-software-engineer-f-m-d) at **Personio SE & Co. KG**
- [Senior Web Designer, Growth](https://www.wearedevelopers.com/jobs/ext/102722-senior-web-designer-growth) at **Intercom, Inc.**
- [Senior Software Engineer, Client Apps Platform](https://www.wearedevelopers.com/jobs/ext/1773893-senior-software-engineer-client-apps-platform) at **GitHub**
- [Senior Software Engineer](https://www.wearedevelopers.com/jobs/ext/159190-senior-software-engineer) at **GitHub**