Freedom of Mind

I’ve had an interest in Buddhism from the time I first saw the Dalai Lama speak at the University of Washington in April of 2008.  Since then I’ve read texts on the Dalai Lama and Buddhism, started yoga, and started a meditation/mindfulness practice.  As my “studies” have matured, I’ve begun to understand Buddhist principals more and more.  I’ve written before about compassion — how it makes us happier because we give to the community that in turn gives to us.  Today I’ll explain how a free mind is a happier mind, free of the influence of our surroundings on our feelings and emotions.

A free mind is one where emotions and moods aren’t changed by our environment.  This concept is likely very foreign to most of us.  When we see our sports team lose, we can’t help but be upset.  When we get fired from a job, rejected from a school, bad results on a test, what have you, we can’t help but become upset and saddened.  A negative response to these negative events is completely normal, and in many ways good.  Silicon Valley has always celebrated failure as a way to motivate us to learn from our mistakes.  The trick is to be practical with negative events in our lives — learn from them, remember them, build on them — but don’t let your emotions and general well being be affected by them.  With more stable emotions comes more stable and long-lasting happiness.

As for how to reach a free mind, I’m still figuring that out.  Yoga and meditation help a lot.  The hardest part, though, is not falling into apathy.  As my mind becomes more free, I’m finding that bad events around me aren’t inspiring me to change them.  For example, if a coworker does a bad job at a task, my default reaction is to say to him or her, “It’s all good,” when instead I should be coaching them to be better, for the sake of themselves and the team.

We should all strive to have a free mind, where our emotions and happiness aren’t changed by negative events in our lives, where fears don’t limit our capacity to do good, and where jealousy and greed don’t prevent us from enjoying what we already have.  Practice gets us to this state, slowly but surely learning how to balance emotions with practical outcomes.

Getting Started with Android Development

Note: this blog post has been translated to Russian here.

I thought I’d give some tips to those of you interested in getting started with Android.  A few weeks ago I launched my first and only Android app, FoneDoktor, after developing it for about three months.  Overall my experience was very positive — the Android docs and community are both amazing.

Getting Started with the Basics

The Android developer docs ( are amazing.  The first thing you should do is read up on the basics, and here’s a good starting point:

  1. Application Fundamentals
  2. Development Environment Introduction
  3. Activities and Services
  4. Intents
  5. User Interface

Next, I strongly recommend following the Notepad Tutorial, which will guide you through building a basic app. See my notes on the development environment below before you get started.  And actually write the code, don’t just read through the tutorial.

Development Environment

Use Eclipse.  The Android SDK has an Eclipse plugin that is worth learning Eclipse for.  It can create signed and unsigned APK files, run the emulator, manage virtual devices and API levels.  It more or less makes all the shitty development tasks easy.  Use Eclipse even if you aren’t familiar with it.  The ADT plugin is covered in detail here.

General Development Advice

Use lots of logging.  adb‘s logcat program is great and makes filtering logs very easy.  Keep UI work within Eclipse at first, using the XML editors and renderers as a first try, and moving to either a physical device or the emulator to be sure the UI is polished.  I tended to prefer developing on a physical phone docked right in front of my keyboard.  The emulator is annoying to use with a mouse, though it is slightly faster to send new code to.  Oh and don’t stop the emulator every time you want to try some new code — the Eclipse plugin does the right thing and only updates the app you’re working on in the emulator.

API Version

You’ll be tempted to use one of the higher, recently released APIs such as Gingerbread or Ice Cream Sandwich, but what you’ll find is that most people are still on 2.2 (I forget its release name). Start developing on 2.2 and only discover and love the newer and better APIs as you make your app work on later versions of Android. Starting on 2.3 or 2.4 will only frustrate you when you need to use older and worse APIs for 2.2.

The Eclipse plugin makes selecting API versions very easy.

HTTP Requests

Make sure that whenever you do any HTTP request (or anything with IO blocking for that matter), you do it in the background. There are several alternatives for doing background processing, each with different advantages.  Read about Services, IntentServices, and AsyncTask.  Once you read about them you’ll understand which is good for what purpose.

I used Apache’s HTTP libraries to make HTTP requests.  They worked great.  I don’t know Java all that well, so I’m not sure if there are better alternatives.  I hear Roboguice has good HTTP and JSON support, though I never played with it.

Polling and Receiving Data from the Server

Most apps have a server component, where the app interacts with a server in the background.  I used the AlarmManager to fire off a background process every 15 minutes, which would make a HTTP request asking for more data.  Using the AlarmManager is ideal because it helps Android schedule recurring jobs in a battery-efficient way, and it also guarantees that whatever background service you’re running will be scheduled accordingly and not de-prioritized.

I used Android’s built-in JSON support to serialize and deserialize JSON data.  It worked great.


Don’t roll your own threading solutions. Use what I’ve outlined above (Service, IntentService, AsyncTask) instead.

Font Size

Font size was probably the biggest gotcha for me. For whatever reason some devices don’t respect px and pt as font size units. Instead use sp units.  Without sp units font sizes will be different depending on the device, which turns out to be a debugging nightmare.

Exception Handling

If you have an app that starts itself on startup, don’t ever let it throw an Exception, otherwise the user will need to restart the app themselves.  Look into Exception handling services that will catch the exception for you and log it somewhere.  I don’t know which of these systems is the best (I’m not using one of them), but I know they exist.  If you’re more OK with your app crashing and throwing an Exception to the end user, the good news is the Android marketplace will collect all the errors that occur and give you a full stack trace explaining them.  Although, probably obviously, the user experience of getting an Exception is pretty awful.


Cache data whenever you collect it from a HTTP request.  There are a few reasons for this.  First, with cached data you’ll be able to display information to the user without requiring an internet connection.  Second, you’re able to display data immediately while a background HTTP request is made to fetch new data.  And third, since your app will either be updated by the user (when the app is opened or with the refresh button is pressed) or by the AlarmManager, having a cache around will let you create a better user experience while data is either stale or waiting to be fetched.

Depending on your data you can either use the built-in sqlite3 database, or SharedPreferences.  SharedPreferences are great for key-value data, whereas sqlite3 is great for more relational or complex data, which includes data that requires more complex querying.  Learn more about data storage in general here.

UI Layouts

Android offers several layout alternatives such as RelativeLayout and LinearLayout.  Many of these layouts work in obscure, odd ways.  Read their docs in full before you start hammering away at XML.  The time you spend reading upfront will save lots of debugging time down the road, trust me.

Data Records

If your app will have several different types of stored data (e.g., user profiles, messages, game objects, feed items, etc), definitely create a Record interface–with each record type implementing it–that can be easily stored in sqlite, packaged in a JSON HTTP request, or sent between Intents as a Parcelable.  For example, create a,, etc., where each class can send or receive a new or set of records via HTTP and serialize/deserialize as JSON, be stored to and read from sqlite3 with Cursors and ContentValues, and be sent across intents as a Parcelable.  Really it’s too bad that Android doesn’t provide this for you — a serialization format that works in both sqlite3, intents, and HTTP requests — but oh well.  I never looked into other serialization alternatives such as Protocol Buffers or Thrift.

Getting Help

Whenever I was stuck I’d always consult Google and stackoverflow for guidance. The Android community on stackoverflow is amazing.  You’ll find most answers to your questions on stackoverflow. I never tried the IRC channel, though I hear it’s good, too.


I had a lot of fun learning and working on Android.  All other development tools and platforms should use Android as an example for how to make developers happy (I’m looking at you, Ruby and Rails).  And the community is blooming and accessible.

Hopefully this guide can help you get started with Android.  I’ll update it as I think of new bits of advice to give.  Otherwise don’t hesitate to ask me questions in the comments, and don’t hesitate to share any advice you’ve learned as well.

Your True Inner Voice

I have a friend who is very unhappy with his job.  He mentioned to me that he applied for an internal position in a different department that sounded interesting to him, but the department never responded to his application.  Eventually he decided to email the VP in charge of the department.  No response.  Driven to change his bad work situation, he considered going to the VP’s office and pitching he or she in person.  But he decided against visiting the VP.  He let his timidness outweigh his ambition.  He let his timid inner voice win over his ambitious inner voice.  This post isn’t about being ambitious, though.  It’s about finding your true inner voice.

We all reach forks in our path through life, faced with the decision to do or not do something.  Often these decisions are influenced heavily by our current mood or state of mind.  If you’re feeling sad or tired, you’ll be less ambitious.  Whereas if you’re feeling energized and excited, the world is your ouster and you can do anything you want.

Again, this post isn’t about being ambitious, because not everyone is.  You can’t just one day become more confident in yourself and all of a sudden be ready to tackle the world.  Instead you need to find that inner voice that you believe is a true representation of yourself — that above all other voices relates most to your person.  If you’re faced with a decision to be timid or ambitious, and you think of yourself as being timid, then let that voice rule over all others.  But if you think you’re rooted in ambition, never let any fear, phobia, or concern get in your way of accomplishing what you set your eye on.

Finding your true inner voice is challenging; it takes time.  And it’s scary.  I find myself, both while working and snowboarding or snowmobiling, asking myself if I should jump off that cliff, pitch that famous investor, or speak in front of a large audience.  I’ve decided that I’m ambitious — that I should never hesitate to take a challenge that’s important to me.  Unfortunately I’m visited by my anxious and nervous side more often than I’d like.  So I try my best to remind myself why I’m on top of that cliff or behind that speaking podium — my true inner voice is ambition.  I won’t let anything else dampen that voice.

The next time you’re faced with a decision or opportunity, recognize those inner voices at play, and pick the one that you think is the representation of yourself.  And love yourself for it.  If you’re not an ambitious person, don’t beat yourself up for it.  Stay true to yourself, because that’s all you have.

The Transition, Or How To Be A Good Leader

A passion in software usually starts with a job at the bottom of an organization, slaving over lines or code or mocks in Photoshop. Yet many of us long for moving up in an organization — we want to be leaders. We’re hungry for more responsibility. We want to make an impact. There will come a time when many of us at the bottom move up to the top. I’ll call this the transition. And success is gated by letting go.

Most leaders tell people what to do. They believe they’re right (smart leaders often are) and expect others to listen to them and follow their every command. I think I speak for everyone when I say that working for a micromanager is terrible. There’s basically nothing fun about it at all.  Working for a micromanager forces you to not think, to not do my best work, to not be excited about working, and to ultimately be unhappy with your job.  I’ve never met anyone that actually enjoyed working for a micromanager.

I don’t blame smart leaders for micromanaging. They’re in a leadership role because they’re smart. They probably know the right answers, which they then dictate to the rest of the team.  What I’ve explained is a completely natural tendency, which is why so many leaders are micromanagers.

Micromanaging makes a team only as smart as the leaders, and no more. Actually, it makes the team less smart than the leader. We all think differently, and when we’re forced to think like someone else we’re worse. Furthermore, micromanaging makes people unhappy because their responsibility and impact potential is completely removed from their job.

When someone smart makes the transition, they need to let go of their belief that they’re always right and challenge their team to do their best thinking. If a leader thinks they have all the answers and hopes for everyone to do as they’re told, people will be unhappy and far less productive. Let go of your intelligence and give your team the opportunity to be smart, to try things, to fail.  People do their best work when they’re given an opportunity to fail.

Letting go is no easy task. You think you’re smart and you’re probably right. But if you want to be a leader for the long run, where your employees are challenged everyday and absolutely happy because of it, you need to let go and pass the responsibility onto others. You need to build on debates with “yes, and” responses instead of “no, but” responses. And you need to trust your team.

The transition isn’t easy. But think back to the times when you were unhappy with your boss, where you wanted to be more responsible and impacting. Remember how you felt. And treat your employees how you wish you were treated then. If you fail at this your team will only be as smart as you (or probably less smart) and they won’t be excited to come to work every day.