Y’all may have noticed from my Twittersplosion that I had a frustrating time trying to install and run the AndEngine examples.
This involved 7 hours, 3 different tutorials (including 2 ones on video!) and at least 10 distinct errors requiring a stop-and-Google. At four in the morning I got the emulator to launch the example but then crash, and I gave up.
To be fair, my process had to include installation and setup of Eclipse, which I didn’t have on my home PC. Maybe a true Android developer would have had Eclipse and ADT all set up in the way it needed to be, and I should not have expected the AndEngine tutorials to address those issues.
Even so, I’m going to step away from AndEngine because this much trouble installing can’t bode well for development. I may come back to it after I try a couple of other things (HTML5! Akihabara!), but I’m really angry and frustrated with it right now.
So here are some takeaway lessons to help give merit to last night’s nonproductivity:
1) Set a limit. This is hard as hell when you keep thinking you’re 20 minutes away from “getting it to work,” when each solution is really 20 minutes until the next error. I understand now how planes full of passengers end up on the tarmac for 8 hours. But, since I wasn’t locked in to AndEngine or even developing for the Android, if I had decided at the beginning I was only going to Google three errors and then cut my losses and try something else, I would have saved myself four hours.
2) Because you have a limit now, treat each error as a separate investigation and UNDERSTAND the problem before adopting a solution. For me, the desire to get past an error and keep moving is overwhelming. I’m probably going to grab the first solution that shows up in Google and works and keep going. Unfortunately there is 90% likelihood it’s going to cause another problem later, and I’m not going to remember the change I made because I didn’t understand it fully in the first place.
This has already happened twice on this project. I managed to screw up my git install while doing a homebrew install. Yeah, that is possible.
3) Document what you’re doing. That way if something breaks later you have something to refer to. Also you have a concrete explanation if you make a decision to use something else, instead of just a fog of fury.
Nowadays half of programming is choosing a toolkit and installing it, so if I take these steps going forward I can save myself a lot of heartache. With this project I’ve gotten to the point where I can get willing to set aside the time to do the research. What I need to do is get willing to set aside the time to do the installation, too.
So I feel a little mellowed out now. But seriously until I successfully install SOMETHING it’s a fragile peace, so don’t provoke me. DON’T PROVOKE ME I SAY.
