At Flatiron, we’re often reminded to “make it work, make it right, make it fast,” a saying attributed to Kent Beck. As a lifelong perfectionist, this strikes a cord with me, and reminds me of Sheryl Sandberg’s advice in Lean In that “done is better than perfect.” Many times I’ve delayed getting started on something because I didn’t know the “right” way to do it, or wanted to find the perfect wording. But I have found that doing this will prevent me from getting started on something when I wanted to. Other times (such as in a memorable sculpture class in college) I’ve insisted on massive undertakings beyond the scope of what a project is supposed to be, and sacrificed many hours of sleep and free time to accomplish it. It’s a tendency that I’ve been becoming more aware of over time.
For some reason, perhaps because it’s so new to me and because I know I still have so much to learn, this perfectionist do-or-die inclination has been coming through less in learning programming. Do I want to make something “perfect”? Yes, of course. But I also recognize that I may not yet have the knowledge to do this, or even if I do, I should first get something working before adding on bells and whistles and things that aren’t necessary but are nice to have.
I think a few things about programming help contribute to this. Test-driven-development helps, since it forces me to plan out a project and break it into smaller, isolated chunks before I start to write the code. The project overall may not be perfect, but I can focus on getting each chunk done, and then thanks to the tests refactor towards perfection after everything works without fear of everything crumbling. The concept of “minimum viable product”, which I’ve frequently heard developers use, is also something that I try to keep in mind. If I start a project and think of other features or challenges I want to add in, I’ll make a note, but make sure to get the base concept working before delving deeper.
I guess what it comes down to really is that I know that I can always improve on my code, and as long as I keep on wanting to learn I always will be able to. At some point I just realized that it’s better to do the bare minimum to see if my idea of how something works is correct and add on more after, than to build a more ambitious project filled with extra features only to find out after it’s supposedly complete that I was wrong about a cornerstone of its structure.