Long Term Takeaways
- Test first, test during, test after, test, test, test
- When designing algorithms, demand the weakest capabilities (e.g. iterable vs. indexable)
- When designing containers, provide the strongest capabilities (e.g. indexable vs iterable)
- Build decorators on top of containers, iterators, and functions
- Utilize the benefits of being lazy (i.e. yield)
- Always look for reuse and symmetry in your code
- Collaboration is essential to the quality of your code and to your well-being in producing it
How well did the course convey the takeaways?
I think the takeaways were conveyed pretty well. In class, lazy generators were always key to most of the Python HackerRanks. Tests were especially important during the IDB project, and symmetry was emphasized during the refactoring portion of the class.
The biggest takeaway from Software Engineering for me is the importance of collaboration. Our group of six built TexasVotes, and each member was instrumental to getting each phase rolled out quickly. The IDB project definitely could not be done alone.
Collaboration was also important during group quizzes tests and HackerRanks — where we would often learn new things from each other.
Thoughts on two stage quizzes and tests?
As mentioned above, these are amazing. With your group, there’s less pressure on getting answers right the first time and more emphasis on actually learning the material. Plus, you also get to mess around in the breakout rooms if you’re group is fun.
Thoughts on cold calling?
I understand why people don’t like cold calling, as I’m a shy person who likes to avoid getting called on in most of my classes, but I also want to defend the practice. While getting called on in other classes can be anxiety inducing, Professor Downing mitigates this by lowering the stakes. He doesn’t look for an immediate right answer — rather, he tries to lead you to the point he’s trying to make in the lesson. Furthermore, Downing does a decent job of trying to make his questioning seem more conversational than pop-quiz-like. With all of my classes online this semester, I like how cold-calling makes the class seem a bit more in person.
Thoughts on labs and office hours?
I only went to office hours a couple of times, and Downing was nice to talk to there. That’s pretty much it.
While I like the independent learning aspect of the class, it’s a bit ridiculous how much is required to learn on your own. I came in with tons of experience with React, but I also know of teams who had to learn React, a complex front-end framework, from scratch. The same goes with Flask and SQLAlchemy. Having some guidance, maybe through a lecture in class or an outside workshop, would be helpful for students not familiar with full stack development.
The IDB project also contained some ridiculous requirements. Forcing students to rewrite React class components to functional components on the last phase was pretty wasteful, and the strict formatting rules for files was more troublesome than helpful.
This is one of the most important classes to take as a UT CS student. It isn’t perfect, but it is a class that teaches you real world skills you’ll bring into the your workplace after graduation. Along with this, you get to flex your creative skills by making a website you’re passionate about, and you get to meet cool people along the way. Though time consuming, it’s incredibly rewarding!