You’re starting a project, excited to get right into it; discovering new ways of linking things together, functions you’ve never seen before or used in ways you’re unfamiliar with. The exhilaration of knowing that it’s going to be a tough but worthwhile endeavor that’ll take you closer to the goal of mastery. But before that, you’re supposed to come up with a write-up of what it is you’re going to do.
This was me when the project started. After painstakingly figuring out what project I should take up (which is a project in and of itself), I got the approval to go ahead with it. I recall getting excited at the notion of reading papers to figure out how to come up with an implementation strategy. I had done my homework and came up with a collection of papers that I’d use for my research, imagining myself as an erudite student looking through papers to solve a gnawing problem. In my mind, it was as close as I could get to the scientists I’d grown up watching on TV as a kid.
When we began, we were told we’d need to come up with a proposal for our project. No problem, I thought. A simple write-up should do. But as with life, sometimes it’s never that simple. My worry began when the words evaluated like a master’s candidate were mentioned in the same breadth as the proposal. At this point, my grand ambitions were being shadowed in doubt, nothing too daunting, hope was still alive. I would still be able to do a simple write-up and come back afterward to fill in the gaps with all the wisdom gained from implementing the project.
“Success is most often achieved by those who don’t know that failure is inevitable.”
Coco Chanel
We were introduced to the methodology we’d be following for our proposal and subsequent project. The CRISP-DM methodology. Another setback, but nothing a more expanded simple write-up couldn’t solve. My grand ambitions were crushed when the expectations for each section were made clear. It was clear from the onset that this would be a very involved process. Hopes crushed.
I like documentation. Most people I know do not read documentation to be entertained, they read it because it’s necessary. As the author of documentation, you do not have to engage in long-winded tales explaining why someone should take the time to read the documentation. If someone is reading documentation they have a specific problem in mind that they’re trying to solve. Your job is to explain that in the best way possible to save your reader from countless hours of hair-pulling. Documentation is terse and straight to the point. Not a proposal though. With a proposal, you have to weave a narrative to convince the reader that it’s worth their time.
My first hurdle was writer’s block. We were instructed to come up with a narrative that’s supposed to draw the readers in and captivate them with your project. Sounds easy enough when said but proved harder in practice. I tried to write daily but ended up staring at a blank page as the deadline slowly draws closer and anxiety grows with it. As I was swimming in the sea of anxiety and despair, a thought crossed my mind; why not approach this task like a software project. Start with a small chunk that’s rough around the edges then improve and add on to it based on feedback given by the project supervisor. This took away a lot of the burden of performance I had placed on myself and I was able to write. I knew it would be nothing spectacular but that was okay, I could always improve on it as time went on and off to the races, I was.
At the end of it all, I was happily surprised by the outcome of the proposal. It came out better than I had expected and I did end up getting a much better understanding of the project than had I just jumped in headfirst into implementation. The feedback provided during the weekly project sessions proved invaluable to the writing of my proposal. It enriched my project and each completed section served as a template to the next. By finishing a section, I always had an idea of the format the next would take and it made it easier to start.
In conclusion, I learned that as long as you’re not seated in an exam room, a slow or small start isn’t necessarily a failure as long as you can constantly improve on the initial start. I also learned to seek feedback early and often and use the feedback given to constantly improve. The final output might just be better than what you expected going in.