Reviewing Your Own Work

There’s a lot of value in two (or a few) people stopping to review a design. A conversation can really help to find issues and explore ideas. Having more than one person involved can add an element of objectivity; it can encourage consideration of the user. And someone else often finds it easier to say what you, yourself, do not want to accept.


Working alone, on the other hand, can be very different. The internal dialog a developer has with themselves can result in different patterns of work…

My current project.

Intentionally (see footnotes), I’ve spent most of my time working on Codename: Instalist, alone. There are some areas, such as the app’s name and icon, that I’ve discussed regularly. But across the full range of the app’s workflow and feature set I’ve iterated on the design myself.

I’ve missed having an ongoing discussion. And it’s made me wary.

Delayed review.

Without frequent feedback and questioning from someone else, the development of an idea can go on for longer than it perhaps should. If we’re attached it can be more difficult to honestly review that work:

  • You can get attached to an idea because you worked hard on it. The idea must have value because you put all of that effort into it?
  • You can also get attached to the time itself. Even if you’re not particularly enamoured with the idea/implementation, you might be reluctant to let it go. Wouldn’t it be a waste to throw away all that work?

Working solo can make the situation worse; the lack of collaboration can silently adjust our focus:

  • You’re working through a list of tasks.
  • You’re doing it solo so you’re responsible for moving the project forward.
  • As you near completion of one task you might be starting to think about what needs to be done next…

Churning through tasks can make us forget to stop and review the design, as a whole, from the user’s perspective.


When we review something it’s almost always possible to think of ways in which that thing can be improved. At this point we have to weigh up the benefit of changing/improving/dropping-it vs. the cost of doing more work in that area.

On one hand, conceding quality is never a good thing, but on the other, you have to ship.

So we make compromises.

Invariably our software is going to have compromises in it. Too many and the overall design is sloppy. Too few and we risk suffering the penalty of delaying the true feedback. That which comes from the market when we release. The challenge is finding the right balance.

The danger with delayed review, especially delayed solo review, is that we don’t have the courage or discipline to make a change because it seems big.

Reviewing v1.0

I’m done with v1.0. It’s not perfect, but for my ability I’m happy enough with the compromises I’ve made. I’ve worked with a submission date in mind, but I haven’t rushed. I’ve spent enough time iterating to good…

As for the working-solo-review process, this is my take home:

  • Have something that encourages you to step back and review the whole, regularly.
  • Be honest and uncompromising, to a point.