Далее прогер - программист, кодер - так называемый кодировщик (вроде так их называют), прога - программа.

А ты?! Да ты?! Именно! Чуешь разницу меж "кодером/прогером"? Просто многие те, кто пишут проги, думают, что они прогеры, так как программист это типо тот, кто делает программы. А может программы делают программистов? О_о  Всё относительно. Например строителем можно обозвать ребёнка в песочнице который строит замок, однако втоже время, может этот ребёнок в песочнице строит дом О_О. Строителями называют обычно тех, кто имеет хотябы какое-то мастерство в своём деле. Ещё любят такое смачное слово "специалист". Типо "я специалист" ололо. Так вот, кодерами обычно называют тех, кто набирает код программы... Это не означает что код программы неможет набирать прогер. Просто тогда прогер кодит ). Дак в чём же отличие? Кто же тогда прогер? Прогер это тот кто разробатывает архитектуру софта, подбирает алгоритмы, структуры данных, и прочее. Прогеры тоже бывают разными - заразными, злыми - добрыми, флудерами - молчунами, крутыми - ватнегами, задротами - нубами, тру - фэлс, и т.д. Кроме того прогерам платят много больше чем кодерам ).

Теперь два примера, ставящих кодеров и прогеров на свои места.

Пример номер раз (краштест для нубов): часто приходится сортировать списки из элементов, по какому-то "порядку" (линейному, если тут бывают ботаны кроме меня... см. Отношение Порядка) Начнём с кодеров... Кодер-обыкновенный с интузиазмом отнесётся к данной задаче, типа: "сча мы тут всё отсортируем", и начнёт придумывать алгоритмы - оно и правильно. Просто у всех разная думалка, и я считаю велосипеды придумывать полезно: сначала сам изучишь что кчему, попробуешь, попробуешь на вкус, а потом сравнишь, насколько круто кто-то другой решил это, и самое хорошее - тебе будет интересно, почему у него намного круче чем у тебя, короче снова "почуствуй разницу". Дак вот, нуб скорее всего придумает что-то на подобии такого алгоритма, яже тоже был когда-то нубом, я придумал следуйщий алгоритм:

1. Находим "минимум" - минимальный элемент по нашему "порядку". Затем поставим этот элемент на место первого, то есть поменяем местами первый элемент, с "минимальным". Просто вставить в начало - зачастую сложно, т.к. чаще всего прийдётся передвигать все элементы на одну позицию в сторону, такчто лучше просто меняем два элемента местами.
2. Находим "минимум" начиная со второго элемента, и ставим его на второе место.
3. И так далее.

Данный алгоритм отсортирует список. Кому не очевидна "корректность" - "досвидульки и вон отсюдого" (http://mf0.me/wps/2009/10/22/ty-slishkom-blondin-2/) Когда я его придумал, я его обзывал "сортировка паравозом" не помню почему, однако он называется в народе "сортировка выбором". Такой алгоритм работает за O(n²). Оу,  я наверно забежал вперёд. Это короче "сложность" алгоритма, так говорят когда понятно итак о чём речь, а обычно это называется "вычислительная сложность". Для тех кто не знает, что такое "сложность" алгоритма, на пальцах, это типо оцценки времени выполнения алгоритма. Зачастую сложно вычислять "сложность" досконально, до мелочей, да и часто это безсмысленно. Такчто первое с чем соглашаются, это оценивать сложность в "худшем случае", то есть подругому сказать: алгоритм работает не медленнее чем за стока-то. Однако логично что на разных машинах (вычислительных), на разных входных данных, время работы алгоритма может быть разным, то есть нужно как-то оценивать не вдаваясь в мелочи. Поэтому вместо точного времени работы, определяют только динамику роста - как быстро растёт время. Динамику роста относительно чего? Относительно некоторых характеристик входных данных, от которых зависит время работы алгоритма, например для сортировки это n = количество элементов списка. Дак вот, g(x)=O(f(x)) - это понятие вообще из матана, а означает оно то, что можно подобрать такое число C, что для всех x будет C*f(x) больше g(x), то есть как бы f(x) полюбому меньше g(x) при таком C, а значит f(x) растёт не быстрее.  Называется это Ассимптотической сложностью.

Дак вот, судя по алгоритму, можно посчитать, что сравнений делается n+(n-1)+(n-2)+...+2+1=n*(n-1)/2 (арифметическая прогрессия), далее делаем оцценку вверх n*(n-1)/2 < n²/2 = 0.5 * n². Сдесь 0.5 константа, её можно подобрать, поэтому это всё есть O(n²). Прикинем: если у нас 1 000 элементов, то сравнений нужно сделать порядка 1 000*1 000=1 000 000. Фигня, мало. Если например взять комп с процессором 1GHz, а 1GHz это частота, то есть 1 000 000 000 в секунду, а раз это тактовая частота, то значит ровно 1 000 000 000 тактов в секунду. Операции можно считать выполняются не быстрее чем за один такт, значит 1 000 элементов отсортирует минимум за 0.001 секунды. Действительно фигня, с таким процессором ). Теперь пусть у нас 10 000 элементов, то сравнений порядка 100 000 000, а это 0.1 на 1GHz проце, вроде фигня... всего десятая секунды, однако. А если 100 тысячь? то 10 секунд.

Простой пример (это ещё не второй пример, это подпример...) Допустим мы в игре хотим отображать объекты сзадинаперёд, и мы сортируем их для этого, и допустим у нас 25 FPS, это означает что кадр должен обрабатываться за 1/25=0.04 секунды, то есть 10 000 элементов будет лагать это точно ). Но это нужно ещё представить игру в которой столько объектов. Очевидно, что кроме сравнений, во время сортировки ещё другие операции происходят то есть не за 0.1 будет это точно. Но теперь ещё в игре же кроме сортировки ещё много всякой всячины, например видеокарта должна отрисовать, звук должен обновится, может физика, потом ввод с клавы, и т.д. в итоге скорость - очень важная весчь. Есть такая тенденция - сильно не оптимизировать (ускорять алгоритмы), а просто поднимать минимальные требования, и говорить "купи лучше тачку" (комп).