Blogs!

Written by Armaan Hirani

Part 1: Looking Back
Looking back, I think the course conveyed its main ideas pretty well, especially because the concepts kept coming back in different ways instead of only being taught once. Testing, design patterns, abstraction, inheritance, polymorphism, and class design all felt more abstract at first, but they started to make more sense once we applied them to projects like Darwin and Life. Some parts did feel overwhelming because there were so many details and requirements at once, but that also made the course feel closer to real programming work.

One lesson I will carry forward is the importance of writing code that other people can understand, test, and build on. Unit testing and acceptance testing surprised me the most. At first, they felt like extra work, but later they became useful because they made it easier to catch mistakes and feel confident about changes.

One tool or technique that I found really useful was the use of testing in smaller scale projects. I had mostly thought of testing as something for larger projects before, but using it for Darwin and Life made it easier to check edge cases and avoid breaking earlier functionality. It also made the development process feel more organized and efficient, which was a nice experience.

Compared to my other CS classes at UT, I think I grew more in practical object-oriented programming skills than in theory. This course made me more comfortable designing classes, separating responsibilities, reading specifications carefully, and thinking about how different objects interact in a program. That kind of growth feels valuable because it connects more directly to real-world software work.

Part 2: Your Experiences
14 collaborative exercises on Ed Lessons with 2 drops
What worked well? They helped reinforce weekly concepts through practice and collaboration.
What could be improved? Some exercises could be shorter and less repetitive.
40 collaborative quizzes on Canvas with 5 drops
What worked well? They kept us consistently engaged with the material.
What could be improved? There could be fewer quizzes overall.
9 problems on Kattis with 1 drop
What worked well? The immediate feedback made debugging and learning easier.
What could be improved? Some problems could connect more clearly to the course projects.
Continuous Integration
What worked well? It helped catch errors early and made testing new features and improvements smoother.
What could be improved? The setup and error messages could be explained more clearly.
Cold Calling
What worked well? It encouraged participation and made class more active.
What could be improved? It would help to have a little more time to think before answering.


Part 3: Closing Thoughts
Overall, this course was challenging, but it taught me a lot about what good OOP looks like. Even when parts of it felt overwhelming, the mix of concepts, testing, tools, and projects helped me build habits that I know I will carry forward.

Written by Armaan Hirani

This week felt heavy in terms of content, but it brought a lot of clarity. Many concepts I had encountered before started to connect in a more cohesive way, which really helped deepen my understanding. The biggest takeaway for me was the recurring idea that strong solutions depend more on how you approach a problem than on advanced syntax or clever methods.

Diving into iterator tags gave me a lot of understanding into how the intricate design of iterators works in C++. It took a bit to understand the concept of blank structs that existed just to be a parameter and overload functions, but after seeing it in practice and in the quizzes it made a lot more sense.

This week's paper on the Open-Closed Principle made the idea feel much more grounded than how it sometimes comes across in class. In coursework, it can feel like we are told to add abstractions or interfaces preemptively just to say the code is “open for extension, closed for modification,” even when there isn't a clear need yet. That can make OCP seem overly abstract or like unnecessary extra structure. After reading the paper, it became clearer that OCP is really about anticipating realistic areas of change and designing systems so new behavior can be added without constantly rewriting stable code. Framed that way, it feels much more connected to how real-world systems evolve over time. I understand it's hard to fully simulate those long-term change patterns in a classroom, but it's helpful to see how the principle plays out in practice.

Pick of the week: This week's tip is also from DeepMind: Nano Banana. This is a generative image model from these insanely talented folks who are pumping out creation after creation. It's insanley impressive and can create hyper realistic images based on one prompt. I've used this to try and see how my house would look with different pieces of furniture, and it's actually crazy how well it is able to do that. When comparing the images back to back it's actually hard to tell which one is the real image and which one is the generated one. The use cases for being able to generate in context hyper realistic images are endless, and this brings us one step closer to being able to alter memories or events previously thought to be unchangeable.

Written by Armaan Hirani

This week felt heavy in terms of content, but it brought a lot of clarity. Many concepts I had encountered before started to connect in a more cohesive way, which really helped deepen my understanding. The biggest takeaway for me was the recurring idea that strong solutions depend more on how you approach a problem than on advanced syntax or clever methods.

Diving deeper into iterators this week gave so much clarity into the genius design decisions that went into C++. From my blog post last week, but for whoever reads my post this week: Stuff like this makes me appreciate the thoughtful design decisions that went into creating the foundations of programming languages that the world runs on today. Fun fact about the world running on C++, there are over 16.3 million C++ developers according to this LinkedIn Post from Bjarne Stroustrup, the creator of the language.

This week's paper on the Single Responsibility Principle made the idea feel much more practical than how it is sometimes applied in class. In coursework, it can feel like we are forced to split code into separate classes just to follow the rule, even when it does not clearly help. That approach makes SRP seem like a chore rather than a useful design principle. After reading the paper, it became clear that SRP is really about separating responsibilities based on real patterns of change, not hypothetical ones. That perspective made it feel much more aligned with how software design actually works in practice. I guess on the counter it's hard to emulate these situations in a classroom environment, but I'm glad the pieces are coming together.

Pick of the week: This week's tip is also from DeepMind: Veo. This is a generative audio/video model from these insanely talented folks who are pumping out creation after creation. Outside of school I'm a cinematographer, or at least try to be one, and seeing some of the stuff this generates, is frankly insane. Actually unfathomable. The use cases for being able to generate in context hyper realistic video with matching audio to fill in a few seconds at a time when I need it is going to be such a useful thing to have going forward. Looking at this I wonder if I'll even need to edit anymore soon.

Written by Armaan Hirani

This week felt like a lot. This was a lot of content, but offered a good bit of clarity. A lot of the things I had "seen" before started to line up in a more connected and understanding way, which was great for my own understanding. The one thing that stuck with me the most was a constant idea in this class, that a lot of solutions matter more on how you approach a problem than the advanced syntax and methods used (which can still be useful, but benefit more on a better thought process).

We talked about pointers a LOT. Some point throughout the lectures of this week, I felt like we were just exploring the intricacies of C++ for the fun of it, and was genuinely wondering when in the world I would use const int* const ever. Like it has been very so often in this class, whenever we started walking through the examples for actual use cases (similar to assertions and the example for the ATM failing on user withdrawal) I saw the usefulness behind it.

Stuff like this makes me appreciate the thoughtful design decisions that went into creating the foundations of programming languages that the world runs on today. Fun fact about the world running on C++, there are over 16.3 million C++ developers according to this LinkedIn Post from Bjarne Stroustrup, the creator of the language.

This week's paper on pair programming made the topic seem a lot more useful and worthwhile than the pair programming we had to practice in OS, making sure we switch off every 15 minutes and log exactly what was done where. In the latter it made the concept seem like a chore and not really effective. After reading this, it was essentially just nice reminders to the things that happen in tech outside of education.

Pick of the week: This week's tip is also from DeepMind: AlphaFold. This comes to mind because a recent PhD from UTCS was awarded after increasing the speed of AlphaFold by almost 3X while not degrading accuracy and quality of results at all (not even a hundred thousandth of a percentage).

Written by Armaan Hirani

This week was almost entirely working on Collatz, both in a good way and a very frustrating one. Spending so much time on a single problem really made me slow down and think about how complex software can be when getting past working code. What stood out most to me was how much of a reliance there is on infrastructure and tooling as opposed to just clever logic written in code. Between setting up the CI/CD pipeline, using checktestdata, and making sure things all worked together, the experience was very similar to that I've had in industry. It was a reminder that in practice, code is such a small piece of software engineering.

Working through a couple of the in class quizzes, I realized how important it is to remember some basic and quick arithmetic in the scope of computation (i.e. that 'n >> 1' is equivalent to 'n / 2', or that 'n & 1' is equivalent to 'n % 2 == 0'). Some quick little bits to produce huge savings in time complexity and computation at a bit and hardware level. Also, being reminded about some bit manipulation tricks to count trailing zeroes and speed up computation made a switch click in my brain that flooded memories of computer architecture and learning about all these little things. A walk down memory lane wasn't something I was expecting from a project here, but it was great.

My tip of the week is another invention from the folks over at Google DeepMind, but not Genie 3. This week, I want to talk about WeatherNext2. Using AI and ML algorithms, this is one of the most advanced weather prediction algorithms ever created. It's being rapidly integrated into every way you interface with the weather across all Google services, and it's wicked good at what it does. Given the insane freezing we've had in the last 5 years, that I had never seen in my life before. Many of us can agree that being able to predict the weather accurately in times where we're getting more and more wild forecasts is extremely important, and this is doing just that.

Written by Armaan Hirani

The idea of Docker before this week has always been one that's more foreign to me. I had always associated it with the idea of containerization, but never realized the usefulness of being able to just pull down an already configured and working environment with all my relevant tooling and needed dependencies ready to go.

It took a little while to comprehend, but after doing some personal experimentation on my own with mounting physical volumes to virtual Docker space, was my biggest a-ha moment this week. When learning about it in class, honestly I was very confused. It took a good bit of searching on Youtube and Google to understand all that was happening and how it worked, but now that I do I see the usefulness of it through and through. I found a lot of use in a video by "Ethereum-Blockchain-Developer | BlockOnAir", linked here. It's only 10 minutes, but definitely a very worthwhile watch.

Moving on, to Collatz optimizations. When dealing with large problems, I've realized that I tend to focus heavily on the bigger picture. This week's lectures were a great reminder that sometimes smaller optimizations can lead to massive improvements in efficiency through and through. Pairing this with optimizations previously mentioned in passing, and doing more research about the subject, my current working solution is far more advanced than the ones that I attempted while first attempting the Problem on Kattis as well as working on the assignment. I completely forgot how useful it is to know some quick math skills and their relation to binary manipulation, and this was a great reminder to that skill.

My tip of the week is something from the folks over at Google Deepmind: Genie 3. They describe it as "A new frontier for world models" capable of creating entire three dimensional game spaces based on a single prompt, combing hyper realism and animation together in ways that are rarely seen outside of Hollywood levels of production. I spent some time on the website over the last couple of days after hearing about it from my roommate, and it's safe to say, I'm shocked.