Projectile ships with sensible defaults for switching projects and listing files, and most of my config leaves packages at their defaults unless something specific needed to change. Two lines inside use-package projectile deliberately override Projectile's own choices, and both are small enough that it's worth being precise about what each one actually does, since "I changed the default" only tells you half of anything.
Landing in a file listing, not the last buffer
core/project.el sets this in the package's :init section:
(setq projectile-switch-project-action #'projectile-dired)
Projectile's own default for this variable is projectile-find-file — switch to a project, and you're immediately dropped into a fuzzy file finder for it. This config overrides that to projectile-dired instead: switching projects lands you in a Dired buffer at the project root, a plain file listing, rather than a prompt expecting you to already know or start typing the name of the file you want. The practical difference is what the first moment after switching actually assumes about you — a file finder assumes you know roughly what you're looking for and just need to jump to it fast; a directory listing assumes you might be re-orienting yourself in a project you haven't touched in a while and want to see the shape of it before doing anything else.
Recently-touched files first
The second override sits right below it:
(setq projectile-sort-order 'access-time)
Projectile's default sort order is alphabetical. This switches file listings — inside a project, wherever Projectile is doing the sorting — to order by access time instead, so whatever was opened or touched most recently floats to the top. Paired with landing in a Dired listing on project switch, the two settings compose into a specific, coherent behavior: switch projects, see a plain file listing, and the files you were most recently working with in that project are the first ones you see, rather than whatever happens to sort first alphabetically.
Why both being intentional matters more than either one alone
Either setting on its own would just be a minor preference. Together, they're a specific bet about what "returning to a project" actually feels like day to day: not "I remember exactly which file I want, get me there fast," but "remind me what I was doing last, and let me see it in context rather than jump straight into the middle of one file." That's a real, opinionated choice about workflow, not a default left unexamined — Projectile's out-of-the-box behavior optimizes for the first case, and both of these overrides push in the same direction toward the second, which is exactly the kind of pattern that's easy to miss if you read either line in isolation instead of noticing they're solving the same problem from two different angles.
The same use-package block has two other customizations worth distinguishing from these: projectile-completion-system is set to ivy, and projectile-project-search-path is conditionally set to ("~/src") when that directory exists. Both are real settings, but they're a different category from the two above — one just points Projectile at whichever completion framework this config already uses everywhere else, and the other tells it where to look for projects in the first place. Neither one expresses an opinion about what happens the moment you land in a project; they're plumbing, not workflow. The switch-action and sort-order pair is the part of the block that's actually about how re-entering a project should feel, which is why those two, and not all four, are the interesting ones to read together.
The generalizable point isn't about Projectile specifically. Two related settings changed together, sitting a line apart in the same :init block, are worth reading as a pair before assuming either one is arbitrary. A single overridden default can be a whim or a one-off annoyance fix. Two overridden defaults that only make full sense in combination with each other are usually evidence of an actual opinion about how the tool should behave — and the opinion is more visible in what the two settings do together than in what either one does read on its own.