Blockers in a project always present a unique set of difficulties. I think that in crunch times they can be incredibly infuriating, and even outside of those, if they continue to persist for long periods of time it can contribute to a very large sense of failure. In programming, there’s no shortage of blockers to be found, whether its in a new language you’re learning, a large complicated project , or even in the software we use, each presents a new hurdle to be crossed.
I guess the one good thing is that we live in the age of the internet. It seems as though you can find a stack overflow article or YouTube video covering any specific topic you might need. I went into my capstone project knowing that I would need to play catch up. It involves sorting data and creating dashboards for 10 years of climate change data in a program called ‘Tableau’. Now while I had not used Tableau in the past, I had some bare bones experience with PowerBi, a similar tool developed by Microsoft and thought it might be applicable. Boy was I wrong.
I think the difficult thing here was not WHAT application I was using, but rather HOW it was applied. While I understood from an overhead perspective what is needed to complete the capstone project, the biggest difficulties came between the expectations of our sponsor and our group. In now way do I mean to imply that there was anything wrong, misleading, or incorrect about the project description, in fact our sponsor has been incredible about answering questions and connecting us to resources when we need it. With that being said, the sponsor (who has said this themselves) has incredible expertise in something other than data, and therefore there is a bit of a gap in what they are hoping to get at the end of this and how we as a group can get there. It made me realize how similar this would be to the real world. In a full time job you get project outlines or ideas from Project managers, VP’s, supervisors, and there’s no guarantee that any of them will know already what the exact process will be to get even to a MVP. It’s part of our job as potential programmers to take a write up, potentially written by someone with no CS experience, and then use the skills we have to develop a plan that meets as many of the deliverables as possible.
This project started as something where I thought I could get some good experience in data organizing and sorting, but slowly I’m coming to realize that one of the greater benefits of it is learning how to communicate effectively with groups outside of my own. Regardless of where I go with this program, I will always need skills to take a description and translate it into a working project, and to an even more important degree I’ll need to translate it back, into something that other groups can use in meeting updates or board presentations.
Ultimately there are plenty of blockers in this project, but regardless of which ones we can push through or not I’ll still be coming out of this with vastly improved communication skills and a new perspective of what it takes to put an effective team together.
Leave a Reply