It’s become cliche to say that you should get fresh eyes to look at what you’re working on once in awhile. It’s cliche though because it’s true. So, I don’t have a problem with the saying, per se. My problem is with the way that people approach the cliche.
All too often, I’ve seen it play out a a little like the following scenario. You’ve been working on building something for quite awhile, so you ask one of your teammates or friends that is a coder and to give it a look. They look at it, understand what you’re going for and say it looks good or points something minor out. You feel good, maybe you make a small tweak as a result and move on. Always helpful to have those fresh eyes to catch something small or validate where you’re going with your work, right?
Wrong. The cliche asks for a fresh set of eyes. Bringing someone in with knowledge of what you are doing or a similar background is not truly that. Not unless you’re looking for a fresh set of eyes to debug code. Then, of course, you need someone with at least a knowledge of the programming language you’re using. If you’re looking for a fresh set of eyes to evaluate a product or a feature over all, then you want someone from your potential audience with no prior knowledge of the product. How they react to what you’ve built and their questions will get you a much better idea of how your product would impact your potential audience. That is extremely useful information. How someone on your team reacts to what you’re building has it’s own benefits, but it probably won’t be as large a factor in the success of the project once it launches.
At some point, your project will need some fresh eyes. When it does, you’ll have to talk to someone a little farther away than the next desk. Don’t worry, it’ll be worth the time.