Handover is very important, but with practice it can be done well with little effort. One centralized repository for knowledge is good, although in this case it's more like a combination of Mingle and direct email.
Turning a temporary build server off and back on again will teach you everything about how to set up new ones- also, where the script to do it is. Scripts are wonderful. I think that automating everything using Puppet would be even more wonderful.
Servers without enough space on them are an enormous nuisance when testing giant data import tasks. How to fix this: ask nicely. Also, back channels of communication.
Never assume that you know what an error message means (in Resque tasks, one task can fail because of a parsing error, without the rest of them failing. This happens when there is a small anomaly in the data. You don't need to fix the anomaly in order to finish running the test.)
Developers (well, me) are much happer when they get comfortable chairs, and floors with no holes for chairs to fall into.
git:// vs git@ is an important distinction: the first one gets a read-only copy, the second gets read-and-write. Your build server needs the first one, your development machine needs the second one. The second one throws interesting authentication errors against some firewalls. (I haven't figured out exactly what happened there yet.) When git clone fails and you're in a hurry, you can just scp over the most recent version from a different machine. This is deeply suboptimal because git pull will fail either consistently or sporadically, depending on your firewall configuration.
The db/data directory in a rails app is my favorite because you can auto-generate rake data import tasks by putting things in it.
RHEL (RedHat) 5.5 has no package for git. Use wget, configure, and make. Pick your favorite package version. http://kernel.org/pub/software/scm/git/
Always put your hardware diagrams and reference scripts in the repository.
If you have problems with unstable commits, label the obviously unstable and obviously stable ones. Git tag is a great command.
Making a diagram of iOS certificate signing is difficult, can be done in many different ways, and although ideally it would explain itself that is so far not the case; it's just a very useful visual aid to a question-answer session.
Mongo shell is a lot of fun.
Hotdogging someone's computer by making it easy to lock the screen is acceptable. On OSX, do this by:
System Preferences, desktop/Screensaver/, hot corners, put display to sleep (in one of them). Then, System Preferences, Security, Require password immediately after sleep or screensaver begins.
"Hotdogging" is a colloquial term for "doing something to an unlocked computer to point out to the owner of that computer that they shouldn't leave their computer unlocked"
If you have trouble hearing on the phone, there are several easy partial fixes:
- use Skype (better sound quality)
- email the topics that you heard discussed to someone that was also on the call and ask them to fill in gaps
- get a hearing test
Evernote will take over your life and become your primary external brain storage, but it will make you soooo on top of things. So it might be worth it. I would recommend using the opensource clone Nevernote instead; it has cooler features.
Pre-built secure RPMs exist (you'll probably want to make them yourself?) and you use them for your production machines. To prevent surprises, also use them in advanced testing.
Screenshots are beautiful, essential things when you are working in distributed teams. They reveal communication empty spots which you might have otherwise discovered at a less convenient time. Send them daily. Request them daily. They don't have to be fancy.
Rands in Repose wrote a very excellent book called Managing Humans and as a developer I enjoyed reading it; it discusses some very useful things about communication styles which were directly relevant to things I was having trouble with. (See above re: phone calls and distributed teams)