Hours 65-66: Stuck on an Applied Math Problem

I was going to do three hours today but only ended up doing two because I was working on a super-hard problem and my brain kind of gave out after two hours of non-stop thinking about it. It wasn’t a Java problem though. It was an applied math problem. I only wrote a few lines of code so not much to report here.

I need to get better at solving these really difficult problems. Perhaps this would help?

The only even remotely Java thing I have to report about is that I finally learned about how to use the netbeans debugger via this tutorial.

Hours 63-64: Bugs and Emotions

I got a fair amount done in my coding session today, but rather than drone on about that, I’d like to mention something I’ve noticed in myself: when code fails, I find myself reacting in what is clearly an unproductive way. There’s this little sinking feeling, and I kind of sit there for a few moments, blanking out. And then I sort of foggily hope that the problem just pops into my head, or I dilly dally, kind half thinking about which of the many different approaches to take in looking for a solution. This is unproductive. I’m going to do two things to try to make bugs less deflating:

1. Cultivate a kind of attack attitude.
2. Develop a “bug fixing” checklist, that will allow me to launch my attack without hemming and hawing over what I ought to try first.

The big question though is: what should be the sequence of steps in the checklist? It might begin like this:

1. If you’re in any way unfamiliar with the error message, google it. If solution’s not obvious…
2. print to the screen the variables which could be causing the problem. If the solution’s still not obvious…
3. etc…
4. Verify the fix works

I need to think about it though. I’ll start with something simple and modify over time as my understanding of bug fixing improves. More on that later. Now off to dinner.

 

Hours 60-62: Coding by Googling – Faster Search, Faster Coding?

Today I completed my a new simple board game using the hex board object I finished in my last session, and learned a bunch of stuff about ArrayLists: how to iterate over them, how to convert them to strings for printing (which confused me at first because the syntax is different than for arrays even though the key method for the procedure has the same name both for Arrays and ArrayLists), etc. Feels good to make progress.

Learning to code in the age of Google is so much easier than it was before. Whenever I have some problem I can’t figure out, 90% of the time the solution to my exact problem is one search away. This is probably why I’m learning so much faster than I did when I first learned to code in Matlab 14 years ago.

I’m doing so much Googling maybe I should read more about how to Google effectively. If I could cut my searching time down by 30%, I’d go faster [heads off to google for a sec]. Yep, stuff like this, and this.

Hours 58-59: Treat Coding like Writing Prose

All the work I did in my last session building a difficult class was somehow lost, and I had to start over today. It turned out to be a good thing. Rewriting a piece of code from scratch can yield huge improvements, and it did in this case. The code came out cleaner and my understanding improved greatly.

The experiences reinforces the truth of some advice I got a while back: treat code like you would an essay. That is, write a messy first draft and then go back and revise over and over until you’ve got something great.

Not only will it improve your understanding and the end product, but it allows you to more easily overcome the intimidation that comes with starting a new and difficult piece of code. If I allow myself to produce a hacky first draft, I give myself mental permission to dive right in and muck about to my heart’s content.