Ten Google Nanodegree Tips and the Philly Android Study Jam

THE STUDY JAM

I had the pleasure of working with some really bright and motivated new Android programmers at the Android Study Jam, hosted by Android Alliance Philly this week.  The Jam goes through a beginning Udacity course, and since I've been programming Android for going on 3 years now, and had recently finished the Udacity Nanodegree, I decided to volunteer.  It will run for 5 weeks. I will specifically call out, that this was an incredibly diverse group of students with respect to gender, generation, and ethnicity, something that  is wonderful and that I have not typically seen at tech meet-ups in Philly.  It did leave me wondering if there is something unique about Android that has a broader appeal.  (If you look at iOS versus Android adoption statistics internationally, there is some data that bears this out.)

You might also be interested in a paper I gave at FOSSCON '15 about technologies like Computer Graphics used to entice new programmers to take up computer science.  Using commercially and culturally relevant tools is important for bringing in new programmers.

 

With respect to how we performed as instructors, I think Michael Jordan has a good quote about working hard, taking shots, getting some baskets, and missing others.  I feel like it was a good session, I definitely served up some klangers in response to deep questions from students ("You absolutely must have JDK 1.7 on a mac!" -- not!), but also facilitated some "aha!" moments.

I've missed more than 9000 shots in my career.  I've lost almost 300 games. 26 times, I've been trusted to take the game winning shot and missed.  I've failed over and over again in my life.  And that is why I succeed.

--Michael Jordan

Bottlenecks in running an event like this are as follows:

  • The wifi kind of cries quietly when 20 people try to download Android AVDs (emulator images) all at once.
  • I take for granted the fairly recent hardware that I develop on (mac), and probably don't know as much as I should about how to optimize for older development machines, including Windows machines with limited RAM and CPU.
  • Once you have a development rig set up, with Android Studio, Java, an emulator, and the right drivers to connect to your phone (and a USB cable), things go really smoothly, but the first session getting all that together is a pain!
  • Speaking as someone who has taught a lot of beginners to program Python, Android is a pretty heavyweight option for someone who has never written a 'hello world' before.  This is partially due to the availability of cloud development environments like cloud 9 for Python and other interpreted languages, but also partly just the nature of a text-based, command line, interpreted scripting language over a statically typed, GUI IDE.

10 TIPS FOR SURVIVING THE GOOGLE / UDACITY ANDROID NANODEGREE

screen-shot-2016-01-14-at-12-25-03-am1.png

10. AND is scheduled for 12 months, but you can (and should) do it in 3.

The Nanodegree is set up for a 12 month timeline, but it would be hard to imagine being able to maintain any kind of continuity between development sessions if you spent the entire 12 months on it.    I had the summer off, and even though I had quite a bit of Android experience already, I still believe that the best way for someone (even a beginner) to do this program is to hit it as hard as possible for as short a period of time as possible.

9. You'll discover that there is a lot more to learn.

Screenshot_2015-09-24-16-25-43
Screenshot_2015-09-24-16-25-43

One of the hard things in technology is tapping into the current professional zeitgeist or ecosystem of libraries, toolkits, and best practices that are being used on real commercial projects, particularly if you are not working in a shop full of senior people who are willing to share what they know.  The AND gets you part of the way there, illuminating enough advanced fundamentals to put you on good footing.   After graduating, I feel like I have a solid platform to now explore going from sort of 'prototype-level' apps (monolithic activities, no testing...etc)  to production apps using libraries like Dagger,Retrofit, and Mockito.

8.  You will learn from (some of) the code review.

I had at least one amazing code review early on in the Nanodegree, but they sort of deteriorated after that.  I'm not sure what the economics and incentives are for code reviewers, but towards the end of the program it just seemed like whoever was reading my code was copy and pasting code review from a set of canned responses.  Early on, code review taught me about passing around Context (an Android specific thing that was probably the number one cause of crashes early on).  However, as I got better, I was wishing for comments like: 'you could have done this better here by..."  or "you could make this more modular here by..."...etc.

[embed]https://www.youtube.com/watch?v=1Atri6TjIxQ[/embed]

7. Your time between 'idea' and 'deployed app' will shorten drastically.

ash-feature
ash-feature

I launched two of my own apps while doing the Nanodegree.  I feel like I can now pump out a reasonably visual UI interpretation of REST data (especially if its geo-referenced data on a map).

6. You'll get good muscle memory for Android Studio.

In terms of just the general day to day writing, debugging and deploying of apps using Android Studio, I feel like I'm much more comfortable now than when starting the degree. I felt like I just sort of learned when a build was taking a normal amount of time, or when it was hung, and other things like when the debugger isn't talking to the phone properly...etc.  I still dread 'R' compilation errors (if you've done any Android, you know what I mean.  One bad XML tag can hose your app.).

5. Gradle will not seem mystical.

gradle
gradle

In AND, you spend a couple of weeks just working on the Gradle build system.  The material in the Gradle unit is hugely valuable, and I feel like many of the developers I know (myself included before the course), just sort of hit the buttons in Android Studio to make it work, without really understanding how to configure a build.  Obviously this is a learning process, but I feel like I've moved along that learning curve a bit.

4. You'll scratch the surface of creating Android Libraries.

My first professional Android project a few years ago was to take a half-complete application, build it out, and then launch 5 child themed apps from it.  In the AND you will scratch the surface of some of the techniques for code reuse in Android.  My current philosophy on app development is that where possible your app just shouldn't have that much code in it.  If your app is huge, then the pattern you should adopt is a series of Java libraries, wrapped in a thin app.   For example:  a generic REST client for a particular API that is not tied to the UI of the app is an easy thing to break out into its own module.

3. You'll write a lot of code but come to hate at least one of the projects.

Some of the AND projects are amazing.  My favorite was the multi-flavor Gradle  build project discussed in 5 above.  However, some of the projects build on a single weather app for what seems like weeks on end. You use it in the intro, intermediate, advanced, and ubiquitous computing courses. That seemed like something that Udacity and Google did to scale the program quickly, but the demotivation from having to hack on "Sunshine" for weeks at a time is huge.

2. You will miss the clarity of highly structured problems.

docmentaries
docmentaries

The AND is structured around really good project specifications, and in some cases complete UI mockups of the thing being built.  There is someone there who measures your app against the specification and either marks it "meets specification" or "does not meet specification", and that is it.  In my experience in the real world, the Android client is being built at the same time the larger web/iOS apps are being designed, the database schema and API are being finalized...etc.   Where it takes a week or two to build out the projects in the AND, it could take months of somewhat more frustrating work to get to a finished commercial product.

1. There is still a lot of work left to do.

I had the privilege of working with a master wooden boat builder at one point in my career.  Mac McCarthys's catch phrase was "There's nothing to it, but to do it!"  This is as true of attaining mastery in software development as anything else.  Every project I build, including the 8 projects for the Nanodegree, move me towards speed and dexterity with the platform.  Maybe the ultimate goal is a sort of 'expressiveness', as in drawing or boats -- being able to express a vision for something within the scope of the media, knowing its limitations, and working within a competence for the materials.

My medium term goal then is to just keep on building the apps and getting better!

Screen Shot 2015-09-25 at 7.04.31 PM
Screen Shot 2015-09-25 at 7.04.31 PM