Import Verizon Contacts to Google Voice using Backup Assistant.

Get Backup Assistant

1. Select Get GOING or Media Center (some newer phones go to Tools On The Go or Browse and Download.)
2. Select Business/Tools.
3. Find Backup Assistant.
4. Download it to your phone.

as per http://support.vzw.com/faqs/Get%20It%20Now/faq_backupassistant.html#item2
You may have to subscribe to it for $1.99, you may get it for free. Either way,  do it! You can cancel it tomorrow. You only need it once.

Get your contacts in CSV

1. Let BA sync at least once
   (should happen when you install it. If not, it happens twice a day)
2. Login to http://www.verizon.com
3. My Services (top right)
4. My Contacts (middle left)
5. Export to CSV (middle right next to contact search bar)

Import to Google Voice

1. Login to Google Voice
2. Contacts (middle left)
3. Import (upper right)
4. Select the CSV (no modifications necessary)
5. My Contacts (upper middle)
6. Find Duplicates (lower middle right)

Now you're done!

Notify all of your friends that you're using GV and give them your new number.

(406) XXX-XXXX What?

Google uses a scoped 406 number for each of your contacts. 

Have a friend text you and notice that you get two numbers: one is google's 406 id for that person in your contact list. The other is their number.

What that means is that you can call or sms (text) the person from any of your Google Voice registered phones with that 406 number, but not from someone else's phone. Use this as the Mobile 2 number for your contacts and when you call them on Mobile 2 your GV number will appear on their caller ID.

P.S. I may be lying about the scoped number, I made that part up. I don't have any research to back it up, but it makes sense so I assume it's true until someone tells me otherwise.

How to tell if something is broken.

A few days ago I DJed for a church dance. I had taken my router hoping that I'd be able to create or bridge or whatever an internet connection so that I could download music on the fly (good idea).

It all worked out well, but when I got home and tried plugging it back in it didn't seem to be getting a connection, I swapped the cable with a different one and then it began to function.

Last night I was cleaning up my computer desk area and trying to decide if the cable was broken. Since I've had a problem with it once before (though it was working for several months straight this time) I decided to cut it in half and throw it away.

That's right. If you're not sure if something is broken, the sure-fire way to know is to break it.

You see, the most important thing isn't actually to use or keep the thing in question, it's just to know whether or not it needs to be thrown away. Once it's broken, it's want to be tossed.

I do this with lots of things actually. I find it's the best way to keep myself clutter free. It also help prevent that OCD obsession with not throwing something away which works (even if it's worthless or impractical).

Once I decide I don't need a piece of paper I rip it. Once I don't need a CD I break it in half. When I find something that I'm not sure what to do with and it's not worth giving away, I break it. If I'm not sure if it's broken and it's not worth much, I break it.

Occasionally I regret my action a moment or so after, but then another moment goes by and I realize that it's better this way.

After all, the more stuff you own, the more stuff owns you.

P.S. I didn't follow through on my decision entirely, I was actually feeling to lazy to cut the cable at the time, so I simply threw it away, but that's what I would have done normally.

Identify the problem.
Determine the the ideal solution.

Tonight a friend of mine and I were studying for a test and going off on tangents of our religious beliefs about software design. Incidentally we touched on a great life lesson.

Identify the problem. Determine the ideal solution.

Too often we (especially in the student world where the professors want to fill our heads with theories rather than teach us how to get ahead in life) start from the bottom up - designing code having an idea of the functions we're going to fulfill, but not really grasping the problem holistically. Then by the time we get around to creating the user interface we have a bunch of code that isn't convenient to use.

Too often in the database class I TA for I find that the students have been so focused on creating the database tables (perceived practical end result) that they never consider the actual use and viewing of the application and data (actual practical end result).

If you start by identifying the problem and then drawing out what the ideal solution looks like and what the ideal workflow is (also considering the occasional workflows such as monthly reports or emergency procedures), then you know what interface to provide to the lower level code and which functions will be most useful to create and how to group them.

Life is similar. If you jump to a practical or immediate solution because that's what you're familiar with or because you think that an ideal solution would be somehow impractical then you're short-selling yourself. Once you identify what the ideal solution is you may in fact find that it takes less effort to create than a more "practical" solution.

Elegant.