I attended a conference in 2014 about web design and development called An Event Apart. During the conference, Erika Hall gave a presentation entitled “Just Enough Research.” You can watch it here or even purchase her book!
Erika Hall at An Event Apart: Orlando. Photo by Eric Meyer on Flickr.
The point she makes in the presentation is to do just enough research as you’re approaching a project in order to have better results. It’s about finding a balance between not doing enough research to do an adequate job, and doing too much research to the point that you never begin the project.
This has stuck with me the past few years as I’ve started and completed countless web development projects and switched jobs. And I’ve been able to apply it to more than just the research leading up to the project.
Just Enough Understanding
When I started at Vox Media in 2016, I spent time on the support team fixing a backlog of bugs for our eight brands. This was a wonderful experience, because it forced me to become familiar with the codebase that powers all eight brands.
The codebase backs our proprietary content management system called Chorus. Chorus is huge – in scope as well as in lines of code. Trying to familiarize myself with a codebase like this was – and still is – incredibly daunting.
Often times, I’d be trying to fix a visual bug on the homepage of Vox.com for example. Unfortunately, the problem wouldn’t be solved by a simple one-line fix on the view template. It would likely cascade down through multiple abstractions in the codebase.
This is where using the “just enough” principle came in handy. I had to learn just enough about this section of the codebase to solve this one specific problem. I didn’t have to worry about how the navigation was rendered, or how the stories were pinned on the homepage, or how the ad slots were targeted. I just had to find out how this one visual bug was being produced and fix it.
I had to learn just enough about this section of the codebase to solve this one specific problem.
As I accomplished more and more of these support tasks, I started to build up a mental library of “just enough” codebase knowledge. This library is still under active development, because I’m still learning about new parts of the codebase each week – nine months into the job!
But I wouldn’t have been able to build this mental resource had it not been for that first parcel of “just enough” research.
Just Enough in the Agency World
Before I left Happy Medium, I helped launch a website called The Art of Education. It’s an online resource for art teachers across the world offering years of helpful articles and additional course materials. The Art of Education also allows teachers to enroll in online graduate-level courses to earn professional development.
We built the e-commerce functionality into the website which talked to the third party course management vendor in addition to three or four other APIs. This alone was a daunting task – any time e-commerce is involved, stuff gets real.
When I switched jobs, I realized how large and complex the website’s codebase had become. And with a limited timeline and limited budget – like every project in the agency world – we didn’t have time to properly refactor and document every nook and cranny.
As the next developer began sifting through the codebase, I realized how useful the “just enough” principle is for starting new projects of any size. As bugs popped up, he would learn about a new functionality the website, and I would be able to help deliver that parcel of information to his personal knowledge library.
You’re Never Going to Understand Everything. That’s OK.
I think my flavor of “just enough” can be boiled down to one statement:
Being comfortable with uncertainty is important.
So many times, I sit down to start a new development task at work or in my personal time and immediately get a queasy feeling – a churning in the pit of my stomach. It’s the feeling of uncertainty. I’m uncertain that I’ll be able to accomplish the task, uncertain that I’ll be doing it the most efficient way, or uncertain that I’ll be able to finish it within the given timeframe.
But over time, I’ve become more comfortable being uncertain. It’s how we all begin new projects. And if we were certain about everything we were doing, we would already know everything there is to know in the world.
It comes back around to Hall’s presentation and the emphasis on avoiding doing too much research. I can’t sit around looking at every file, class and method in the codebase before beginning my task. I would never get anything done!
Parallels to Test-Driven Development
As I become more familiar with the concept of test-driven development (TDD), I’m noticing a lot of similarities to the “just enough” approach.
When using TDD, you only write just enough code to make your tests fail. Once you fix your code and your tests pass, you write a test that covers just enough new functionality for your tests to fail again. Rinse and repeat!
This is one of the biggest reasons I enjoy employing TDD in my development workflow. I’m not required to know how every single piece of functionality is going to work in the project. I just need to focus on building tasks one chunk at a time.
I’m sure the “just enough” approach has parallels to other development methodologies. And I’m sure this approach can be used in other industries and aspects of life! But I’ve gained so much from using this approach in my daily workflow, and I hope you can, too.
Cover image: “Iceberg” by Lisa Stoll on Flickr