Although I've had my share of fun with microcontrollers over the last few years, all of it was with AVR controllers, and most of that was with the ATMega16.
Almost 3 years ago, when I first joined the Robocon team, SPS had just started using the ATMega controllers, and we never looked back from then. I had heard of PICs, but never got around to using one, although its touted to be one of the easier microcontrollers to use. Some work I'm doing now had relatively strong reasons for using a PIC - a couple of PIC16F877As were already available, and more significantly, there was a programmer with it. The programmer is usually the bottleneck when it comes to first timers to the ATMega, and I figured since I had a commercial programmer at my disposal, it wouldnt be too much of a pain. I was wrong.
To start off with, searching on the internet for PIC related things seems to return results with an abnormally low signal to noise ratio. Even legitimate results are spread over a wide range of PICs, some now obsolete. Tons of pages are from many, many years ago and are no longer accurate. The pages that seem the most promising sometimes turn out to be AVR related pages.
PICs also seem to have massive dependance on various commercial toolchains. For an AVR, the avrgcc-avrdude toolchain is more or less enough to do a lot of things. There's really good documentation, and due to the fact that is open source, it has excellent community support channels.
SDCC is the only open source compiler that seems to support PICs, but its next to impossible to find sample code with explanations, or even halfway decent tutorials. To top it off, it seems SDCC is at best beta-quality when it comes to PICs at the moment. All the other compilers are commercial, and cost a pretty penny. Evaluation versions do exist, but I generally dont like using those unless there is not viable option, especially when they have restricted functionality. Eagle is one software for which I don't mind using the evaluation version (primarily because its way better than most of its competition), and I have on occasion used the CVAVR eval version when the rest of the team was not comfortable with avrgcc and we were on the clock. It would seem, however, that it is next to impossible to do stuff with the PIC without an endless stream of seemingly arbitrary proprietary software. Some of this software does look pretty nice, to be honest, but I'm still extremely pissed about how circuitous the path to get here has been. AVRs also have a lot of 3rd party compilers and IDEs and such available, but somehow avrgcc stands out in the crowd. Avrfreaks and the avr mailing lists seem to do a wonderful job of keeping things together, and there is always a somewhat authentic source to get information. SDCC for PICs still has a long, long way to get there. All of these issues came up on a windows machine. I have no idea how many hoops I'd have to jump through to get this done on a linux machine, considering the proprietary nature of the compiler, the linker, the programmer...
There are programmer circuits in the open domain, but theres a lot of noise there too. Try to search for in-circuit programming on PICs. It wasnt until I was able to track down the manual of my programmer that I was able to determine that it did, indeed, support ICSP. As for software that does the programming, there are tons of those too. If you dont know what programmer you have, you're going to spend a long time trying to figure out which software will do the job. For a person coming from the usual low-voltage ISP of the AVR family, where high voltage programming is something you do on the rare occasion when you need to fix some terrible mistake in fuse bits, the whole LVP disabling thing of the PIC is a little confusing, unless you're lucky enough to find some text describing the situation early on.
PIC programs also seem a little bit screwed up, with the configuration bits described in each program. Why those bits have to be reset on each program is something beyond me - on AVRs, fuse bits are something we change on rare occasion, and with much care. Although I must admit, the HVP on the PICs does make it easier to fix mistakes at that level.
I've also realized that the internal RC oscillator on the AVRs is also something that is often taken for granted. Thanks to the HVP and the way PICs get programmed, the programming works even when the chip isnt getting its clock properly. Again, thats nice to fix mistakes in setting the configuration bits, but somewhat a pain when you arent sure if your crystal is properly working with the capacitors and such.