Lessons Learned from Videos:
When I read the titles of the first few videos, I thought they were going to be similar to the videos from last week. But the videos about quantum machine learning were much different than last weeks video about quantum mechanics and machine learning. Seth Lloyd didn't speak technically about what quantum mechanics or machine learning was. Instead, he spoke about forms of communication and how they have changed through out the history of humanity. I thought it was very interesting that he said that “human language is not only a way of communicating things, but it is also a way of reasoning and thinking using the notion of logic.” We not only have to use our language as a means of communication but a way to logically solve problems by taking things out. By figuring problems out logically, I learned from Feynman that in order to do this, you must 1. guess, 2. compute consequences of the guess, and 3. compare your guess to the laws of nature (experiment). This is similar to what Stephen Wolfram did while developing his computational website WolframAlpha. He started with the notion of Mathematica that uses symbolic programing to build it and used the space of all possible programs. He then tested it using the principle of computational equivalence, because although we are used to letting science predict things, the only way to see an outcome is to watch it evolve, and that just takes too long. So using the principle of computational equivalence was faster because even complicated systems do computation. With this, he wanted to go even further and figure out what knowledge in the universe we can make computable. His logical thinking and reasoning is what last weeks videos called moonshot thinking. He had an idea, stuck with it, and once he achieved his goal, he went even further. With this, I am becoming more familiar with the idea of moonshot thinking and believing that all those who have a dream shouldn't just let the sky be the limit, but go past the sky, the moon and the stars and never let anyone put a limit on what you're capable of thinking or doing with your ideas.
It was shown in the second set of videos that, even a large company such as Google, has to run tests and code review is a necessary thing for a company to develop and grow. If we do not do code review, things will break over and over again. It is designed to make things easier and as the last video (“the testing user experience”) said, we need to motivate engineers to adopt a sort of post mortem culture of how to fix problems so it will be easier to fix next time the breakage happens. Google is constantly coming up with new ways to better improve their company and make it grow. I think that NS is the same way. Because we all have to learn from failures (whether their our own or others) and by watching the videos about Google and how they are constantly trying new things to improve what they do, whether its having their engineers do code reviews or building a continuous build system for their testing.
Lessons Learned in Class:
We started by reviewing the lessons from the previous week, then talked about composition and aggregation. No class Tuesday or Wednesday (didn't talk about terms). We discussed the ideas we had and why we were doing ideas rather than discussing slides on concepts. Reason? Coming up with these ideas enables our creative thinking and problem solving; shows us that software's not the only thing we use to solve problems. No class Thursday or Friday (didn't meet). Instead of taking the time to enjoy my free morning, I spent it reviewing what we had already learned the previos week. I am still trying to get a better understanding of OOP, but I think the more I review, it the more I will come to understand it.