The Capstone project has the highest order of magnitude in terms of difficulty when compared to any of my previous courses. One may think that this is because it brings forwards all the skills that one must have learned in the past. The truth, however, is much simpler. Yes, one must have a developed method for learning technologies and methodologies on the fly, but the reality is that the human factor poses the biggest complexity of them all. While it is relatively simple to build a system based on a set of specifications, it is much less simple to arrive at those specifications by way of speaking. You may be asking yourself what I mean by that, and the answer is very plain and mundane. When attempting to create the specification, it is a developed skill to read between the lines, so to speak, when meeting with a client (or sponsor in our case). I can’t express how many iterations of technical documents we have gone through while attempting to decipher exactly what it is that we are expected to deliver. Just when we think that we’ve hit the nail on the head, we run into another unexpected roadblock. Having gotten used to applying an algorithm to solve a problem, I oftentimes find myself frustrated by the lack of applied-problem methods for dealing with people, but I suppose this situation is normal otherwise I’d find myself delving into the field of psychology rather than computer science. In contrast, my team is a great source for learning. Watching them work is inspiring and awe-inducing. I consider myself lucky to be able to observe how quickly the gears turn and solutions are produced. Having to keep up with that level of competency is both great for improvisation, and very exhausting. I can’t complain about the results, however. We are on track to build a better Deepfake incident reporting tool, just the way one would do it in the real world. As long as we are able to keep on our current track, there is no reason why we can’t deliver on our project.