Run the program and see if it crashes

I don't have a lot of patience for constructing test cases when it comes to testing my code's functionality. When it comes to GUI-oriented applications, my preference is to run the program and see if it crashes (or behaves in some way contrary to what I had intended). At which point, I would go to whichever section of code is most likely the offending code and get trigger-happy with the logging statements.
This may not be the most effective debugging method for some people, but it has largely worked for debugging my Android apps. "Largely worked" because every now and then I'd have a bit of code that looks like it would  work in the way I wanted it to, but doesn't.

Improvements in debugging?

Is it a sign that you're becoming a better programmer when you notice that you're relying more on error logging to tell you what's wrong with your code, instead of trying to brute force a solution and raging about it when you can't figure it out?

I've only ever encountered one error logging framework before: log4net. I started using it at work when the team wanted to convert the their old error logging framework over. To be fair, log4net was a bit too complex for my liking.

I only started to take error logging a little more seriously when I started learning Android development. I started doing databases a few weeks into Mobile Applications Development - we weren't scheduled to learn it until week 5. It only when I hit a snag in incorporating a database into the class exercise for that week, that I finally began to see the value in using error logging.

Error logging

It was only recently that I started to take the whole debugging process a little more seriously.
Before that, I used to brute force solutions to my programming woes. This wasn't exactly the best approach, in hindsight.
Maybe it had something to do with the Mobile Apps Development tutor nagging us about using logging to check that our code works.
That leads to the question of: what is the most effective approach to error logging?
Getting trigger-happy with the logging statements? Or just putting them where the code looks like it needs to be monitored?
My personal approach was to only put the statements where I thought the code looked like it needed to be watched.
For me, logging statements tell me more about a piece of code than setting breakpoints and stepping through the dodgy code.

Musings of a novice Android developer

On the train to uni at the moment. I realised yesterday that I'd have to juggle 3 group-work assignments on top of work and everything else. *sigh* Today I have a 3 hour Mobile Applications Development class. I'm not entirely sure of what I should do for my assignment: a simple tool or a more elaborate database-based app? The problem is that when it comes to big systems, I get overwhelmed quite easily and everything goes messy. But if I could pull it off, it would be quite awesome. If I go with the tool, I'd have to add some features to it that would make it 'shinier'.

Number Puzzle - Android version

This app was ported from one of my old Intro to Games Programming lab exercises. The original (done in XNA) had a 10x10 grid. I put an 8x8 grid in the Android version so that the text on the buttons would be legible.

The player is allowed to move 3 spaces if moving in a straight line, or else 2 spaces if moving diagonally. The player has to try and file the entire grid with numbers from 1-64.

Programming languages to date

VB .NET
This was the first programming language came across (if I recall correctly). I learnt how to program in VB.NET through a combination of Home & Learn's tutorials and following examples in a reference book. It was a good beginner's language, in a way, as its syntax closely resembled the English language. Looking back, VB.NET got me into a lot of bad programming habits. *cringe*

Java
Java was the first language I had any formal instruction in, as it was the language that Programmming Fundamentals worked with. I remember that I struggled a fair bit with the syntax because it was completely different to VB's. But in the end I enjoyed it a fair bit and even managed to get a Distinction for PF.

C++
I started learning C++ as part of Data Structures and Algorithms. The language was a complete and utter nightmare. The syntax was the main thing that cheesed me off. The lecturer I had for DSA, whom I shall only refer to as the "Toadmaster", only exponentially increased my dislike of the language. After that particular semester, I thought I'd seen the last of C++. But no, Introduction to Computer Graphics used C++ as well. The lecturer for ICG did almost exactly what the Toadmaster did where C++ was concerned.

C#
I remember I started experimenting in C# during the holidays sometime last year. I developed an interest in it upon hearing that the syntax was a cross between VB.NET and Java. Again, I took to the Home & Learn tutorials to 'learn' the basics of programming in C#. As I grew more comfortable with the language, my experiments became more adventurous. At one point I developed a Pokedex application that used a database. One used SQL statements to search through the Pokedex (which was in National Dex mode). I think it was kind of lucky, in a way, that I acquired an interest in C# because I work with the language on a daily basis in my cadetship.

Java code project: Hangman

After sucessfully doing this in C#.NET, I decided I'd have a go at doing this in Java. The main drawback is that Java doesn't have an equivalent to .NET's generic List.