pandas is the library every data person in Python ends up living in, and it is also the library that people use for years without ever really learning. The usual path is that you pick up enough from tutorials and Stack Overflow to get by, you develop a set of habits that mostly work, and you never find out that half of what you do has a cleaner form. The documentation is right there, it is good, and almost nobody reads it. The user guide is the part worth your attention and it is better written than its reputation suggests.
It is organised by concept rather than by method, so there are chapters on indexing and selection, on merging and joining, on reshaping and pivoting, on group by operations, on time series, on categorical data and on missing data. Each one explains the model underneath before showing the syntax, and that ordering is the correct one for a library where most confusion comes from not understanding what the object actually is. The indexing chapter alone justifies the exercise. Selection in pandas is the single largest source of confusion for new users, because there are several syntaxes with different semantics that look similar and behave differently.
Label based, position based, boolean masks, the plain bracket notation that changes meaning depending on what you pass it. Working through that chapter once, carefully, replaces a lot of guessing with actual understanding, and the difference in how quickly you write correct code afterwards is substantial. The comparison guides are an idea more projects should copy. There are dedicated pages showing how to do things in pandas for people arriving from SQL, from R's data frames, from spreadsheets and from Stata.
If you already think in one of those, this is by a distance the fastest route in, because it maps what you know rather than starting from nothing. The SQL comparison in particular gets people productive in an afternoon. Every API page carries examples with output shown. That sounds basic and a surprising number of libraries do not do it.
Being able to see what a method actually returns, with a small worked example, is the difference between a reference you can learn from and one you can only confirm things in. The group by material deserves specific praise because split apply combine is the concept that separates people who can use pandas from people who can do analysis in it, and the documentation treats it as a concept with a mental model rather than a function with parameters. Now the problems, and the first is scale. This documentation is vast.
Someone arriving without a specific question has no obvious place to start, the ten minute guide is too quick to teach anything durable, and the user guide table of contents is long enough to be discouraging. A curated path through it would help enormously and does not exist. My suggestion is indexing, then group by, then merging, then reshaping, in that order, and ignore everything else until you need it. The library's own history shows through in a way the documentation cannot fix.
There are usually three ways to do anything, some of them are legacy, some are subtly different, and the docs describe them all with roughly equal weight rather than telling you which one to use. A reference is arguably right to do that and it leaves the learner to work out current best practice from somewhere else. The chained assignment situation is the clearest example. The documentation explains views, copies and the warning you will inevitably see, and it explains it accurately, and people still do not come away confident about when an operation modifies the original.
That is partly a library design problem that recent versions have been addressing, and it is the one area where I have watched competent engineers read the explanation twice and still get it wrong. Performance guidance is thin and scattered. There is an enhancing performance section and it does not connect to the rest of the documentation, so a person learning group by operations is not told anywhere nearby that their approach will fall over at scale. Given how often pandas performance is the thing that pushes teams towards other tools, this deserves more prominence than it gets.
The assumed Python level is higher than the audience's actual Python level. A lot of people come to pandas from analytics backgrounds with limited programming experience, and the documentation assumes comfort with Python objects, methods, indexing semantics and error messages. That mismatch is where a lot of the frustration comes from, and it is not really the documentation's fault, and it does mean this is not a first resource for someone whose Python is shaky. My four point two is for a large, well written, genuinely educational reference that most people never open, marked down for a structure that gives a newcomer nowhere obvious to begin, for documenting every option without recommending any, and for a performance story that deserves better than a page tucked away at the back.
Read the four chapters I named. It is a couple of evenings and it will change how you work.