Week 1

Tackling Coding Bat challenges has been a real journey for me, and I've definitely refined my approach along the way. My first step is always to really understand the problem. I don't just skim; I read the description several times and then spend a good chunk of time analyzing the examples. Walking through them manually helps me solidify exactly what's expected.

Once I feel like I grasp the core idea, I move on to planning. When it comes to implementing the code, I take an incremental approach. I'll get the basic logic working first, then gradually layer in the solutions for those trickier edge cases. I also make a conscious effort to use clear, descriptive variable names.

For testing and debugging, I rely heavily on print statements. If my code fails a test, I'll flood it with print statements to see the values of variables at different points and trace the execution. This, combined with carefully reading Coding Bat's error messages, usually points me right to the problem. I've found that just guessing at fixes is a waste of time.

What really worked for me was patience and methodical thinking. Breaking down problems, even simple ones, into smaller steps and actively looking for edge cases improved my success rate dramatically. What absolutely did not work was skipping the planning stage and just trying to brute-force a solution. That usually led to more time debugging than if I'd just planned it out from the start.

The number of tries it took varied wildly. For the really simple challenges, it might have been one or two attempts. For the medium ones, maybe three to five tries, often due to small off-by-one errors or minor logic slips. But for the toughest problems, it could easily take five or more attempts, sometimes even forcing me to scrap my initial approach and start fresh with a completely different idea. It's a great way to learn to be persistent!

Comments

Post a Comment

Popular posts from this blog

Week 4

Work with some of your fellow classmates and go through your solution to project 1: LDPM You can work with up to three people (you MUST work with at least one other person) With whom did you work? I worked with Serena Ngo and Chanroop Randhawa. What was your strategy for solving the assignments? Did you start writing code right away? Did you plan it out on paper? I started as soon as I could. I always write code out on paper to visualize it. What was THEIR strategy for solving the assignments Chanroop -  Her project strategy involved thoroughly reviewing documents and then working file by file, finishing with Monster.java . She planned her code using rough UML diagrams on paper.  Serena - Her approach involved first outlining variables, methods, and classes from the document, then adding JavaDoc comments as guidance. She then went method by method, writing pseudocode and comments, followed by a rough code draft.  How would you change your strategy having worked on the ass...
Read more

Week 2

This week, I focused on core software development concepts from Lab 00 and Lab 01: unit tests , Git commands , and interfaces . Lab 00 introduced me to writing focused unit tests to verify code components, a practice I see as vital for reliable software. I also began learning essential Git commands like add , commit , and push , understanding their role in version control and collaboration. In Lab 01, I got an early look at interfaces . I learned they define a contract, outlining methods a class must implement. This concept, though new, already suggests how interfaces promote code abstraction, flexibility, and modularity. The biggest challenge was grasping the Git workflow , especially minor merge conflicts. However, the immediate positive feedback from passing unit tests was a great motivator. Moving forward, a strong understanding of Git is clearly crucial, and the initial exposure to interfaces has already begun shaping my approach to designing reusable and extensible code.
Read more