Periodically, the graphic design magazine HOW publishes a Best Work issue. Design firms and individual designers submit their recent “best work”–projects whose creators feel are of great quality–and the magazine editors decide what, from the submitted work, is featured in the magazine.
When I first looked at one of these magazine issues, this idea of self-selecting “best work” struck me. Many industries have annual awards ceremonies, prestigious associations, or other ways of recognizing merit. But within an organization, or even on an individual level, the notion of putting regular self-reflection effort into recognizing accomplishments was foreign to me. Sure, I’ve been through the gamut of personal goal plans and annual performance reviews and yearly “here’s what we accomplished last year” organizational meetings. But when your goal is continual improvement, it becomes important to regularly pause to reflect on what you’ve accomplished.
What are you most proud of from the past month? The past six months? The past year?
If you work on a single project, then you grasp onto certain milestones throughout the progress of that project. If you continually jump onto new projects, then you look back to particularly successful ones.
But how do you measure success? Externally, the success of a software product can be measured by client satisfaction, or number of users, or by a high percentage of satisfied users within an otherwise small userbase (small but valueable niche market). Internally, you remember all the compromises that had to be made in order to ship, and you’re aware of the weaknesses that exist in the final product, yet you can be proud of the amount of effort and the good work that did go into it.
But–like in many product-based industries–the success of software is often tied to factors outside of a simple merit-based equation. Marketing, pricing, release timing, competitor reaction, and customer support are just some of the components that affect the success of a product. A well-made product can flop in the market; the people who built the product can be proud of their work, but it’s a pride that’s tainted by that product’s ultimate lack of success.
On such projects, where the ultimate success lies with so many players outside of the ‘makers’, it’s difficult to go back and point to a specific thing saying “there– that’s my best work. That is the culmination of six months or a year’s worth of my life in which I helped build the thing I am most proud of.” So sometimes the successes have to be more modest.
While working on this project I was able to open-source a specific part of it.
While working on this project, I was able to use a new technology that can be reused in future projects.
While working on this project I was able to learn and use several new design patterns that were well-suited to the problem.
The other thing that struck me while reflecting on the “best work” self reflection process is that, when I looked back at the products that I worked on, either individually or as part of a team, I wouldn’t call any of them my “best work.” I’d focus too much on the inadequacies–the inelegance of some of the code, or the lack of user uptake.
I don’t know if I’ll ever be able to go back and look at something I wrote a year–or even three months–ago and not think it’s terrible. When you’re constantly learning new techniques, and constantly learning from experience, everything that came before now just isn’t as good–because it isn’t informed by any of that new knowledge and experience.
When the goal is to continue to get better, it’s important to regularly reflect on past accomplishments, even with a realization that my “best work” is what I’m working on now. My “best work” isn’t accomplished yet.