Glad you got it sorted before I showed up - I read the second sentence and instantly knew what happened
Here's the background of why:
When the USB serial port is opened the DTR line of the serial adapter goes low. This is capacitively coupled (through a 0.1uF cap) to the reset line of the chip, forming an RC-circuit with the 10k pullup on reset, thus pulsing reset low briefly. This has two effects:
- When opening serial monitor, it ensures that your code runs from the beginning with the serial output available (otherwise, setup() would have run as soon as the sketch finished uploading, then you'd open serial port, but setup has already run, so you wouldn't see any output from that in the monitor)
- When you want to upload a sketch, you need to reset the chip so that the bootloader runs (it's active for around half a second IIRC on an Uno); the autoreset circuit achieves this.
But when using Arduino as ISP, this is a problem - avrdude opens the port and starts trying to talk to Arduino as ISP sketch - but the sketch isn't running at this point, the bootloader is. Optiboot runs at a different* baud rate, receives gibberish, and while it tries to jump to the application when it sees wrong-baud-gibberish - but it's too late, characters have been lost, and avrdude reports a sync error.
By putting a 10uF cap between reset and ground, you prevent the pulse on reset (as there is a cap 100x as big as the one between DTR and reset fighting to keep the voltage on reset from changing). This is desirable when using Arduino as ISP - but is bad for most any other purpose.
*On I think the Pro Mini, the bootloader runs at 19200 baud, same as Arduino as ISP. They use the same protocol too; in this case, it proceeds until it reads the signature, and seeing that the signature is that of an atmega328p instead of (for example) an attiny25. Unless you're trying to program a '328p, in which case it tries to write whatever you told it to upload to the pro mini (which will succeed if it's a sketch, and fail if it's the bootloader).