Ну профессиональные программисты, на то и профессиональные, что знают много алгоритмов и как те себя ведут в тех или иных задачах, условиях операционных систем и наборах предполагаемых данных.
Именно быстро:
Есть разные задачи, в большинстве своём они не требуют очень высокой эффективности и достаточно выбрать просто приемлемый не самый плохой алгоритм расписанный ещё Кнутом и Ахо.
Если же разговор о высокоэффективных алгоритмах, то никакого "быстро" тут нет, да и чисто аналитически, без натурного эксперимента, не обойтись, Есть много нюансов по которым отдельные операции могут выполняться дольше или быстрее предполагаемого программистом.
Программисты сидят в профилировщиках, читают статьи по подобным вопросам, проводят множество сравнительных экспериментов на разных наборах данных.
Иногда(часто) использование более эффективного с т.з. времени алгоритма требует больше оперативной памяти, которой может быть недостаточно, или задача работает в связке с другими, потому нужно минимизировать обращения к жёсткому диску(и наоборот ряд улучшений для hdd, компенсирующих его долгое время доступа, сегодня не актуальны и могут замедлять работу относительно других алгоритмов при работе с ssd, есть и нюансы оптимизации для разных файловых систем. Помнится мне однажды пришлось промежуточные данные писать на физическую флешь мимо файловой системы, так как работа через ос и файловую систему снижала скорость в несколько раз.).
Сегодня задачу часто можно распараллелить, но с распараллеливанием тоже надо быть осторожней, это требует и памяти и переключение контекста с синхронизацией данных имеет большие накладные расходы(да и само создание треда достаточно ресурсоёмкий системный вызов), всё это нужно учитывать(есть базовые подходы позволяющие получить результаты более-менее, но если разговор о высоконагруженном сервере, то там идёт битва на не жизнь, так как "количество переходит в качество").
Есть особенности работы аппаратуры, предварительной выборки данных, спаривания инструкций, возможности использования дополнительной оперативной памяти и т.д. (да и банально при работе с большими файлами, самописная библиотека буферизации может в конкретно вашей задаче дать прирост в несколько раз относительно базовых возможностей языка/интерпретатора/ос)
Выбирая алгоритмы часто можно отбросить заведомо неподходящие алгоритмы, но и тут может быть подвох. я помню когда в сортировке м-деревьями для начальной фазы применили улучшение внутреннего порядка, добавляя не по одному элементу. а предварительно отсортированными группами примерно по 10. которые сортировали (как всем известно малоэффективным и требующем автоматического отбрасывания) пузырьком, который из-за простоты и лёгкого предсказывания переходов в микроархитектуре процессора, на малых массивах оказывался эффективнее более сложных алгоритмов с лучшими асимптотическими характеристиками.
Наверно слишком сумбурно получилось, но надеюсь, что смог донести что разработка эффективного алгоритма - это штука достаточно сложная и совсем не быстрая.