Прочитал весьма занимательную статью про важность алгоритмов, вывод из которой показался мне весьма спорным
Для начала — тезис. Я утверждаю, что знание алгоритмов и даже наличие системного образования не делает вас хорошим разработчиком. Можно сказать жестче — для большинства задач вы будете профнепригодны, даже владея теорией графов, зная вычислительные сложности алгоритмов и прочитав всего Кнута.
Все дело в том, что разработка ПО — это не просто алгоритмы или языки.
1. Во-первых, сводить все к знанию только одних алгоритмов — это дохлая затея. Если программист не разбирается, к примеру, в сетевых технологиях, не понимает, как работает операционная система и тд — ему не поможет знание quicksort и всех структур данных.
Так, если программист не владеет пониманием доступных ему в *nix среде готовых инструментов и пишет свой (для запуска джобов — свой крон изобретает, условно) — то это труба. Или человек не понимает устройства сетей, и даже не может предположить, что у него в веб-приложении не грузится определенная часть данных из-за неверно прописанных роутов или лагающего DNS-сервера.
2. Во-вторых, без опыта использования реальных стэков технологий (как ПО, так и осей/железа) программист с крутыми теоретическими знаниями может блистать на топкодере, но залажает примитивнейшую задачу по созданию масштабируемого приложения.
Про нюансы, как ведет себя Java / различные компиляторы/интерпретаторы, можно прочитать десятки тысяч статей.
3. Без глобального , понимания работы приложения в целом на всех уровнях (не только в своей песочнице, но и в рамках оси/железа/сетевой инфраструктуры) программист не может называть себя программистом. Условно говоря, если веб-программист думает только о том, как поставить новую либу на сервер, но вовсе не озадачен тем, как админы потом будут обновлять ее на 200+ серверах (и что будет, если она станет критичной для приложения, а после очередного обновления ОСИ окажется, что она не компиляется вообще).
4. Безопасность. Только с опытом приходит, на лаборатных или олимпиадах этому не натренируют.
5. Архитектура.
Я радостно смотрю, как выходит очередной язык/фреймворк, и тут же толпа бросается его вкручивать себе. Или — еще лучше — брать для своих стартапов.
Не понимая ни как поддерживать потом зоопарки из 5+ технологий (особенно когда их не будут поддерживать — привет GWT и сотням других), ни как масштабировать новомодную хрень на несколько серверов, ни как решать проблемы в отсутствии комьюнити.
Что стоит применять? Зависит от каждого конкретного случая, но нередко инструмент более обкатанный и распространенный предпочтительнее, чем только что появившийся свежий. Могу привести такой немодный язык Pure C, на котором написаны драйвера, системы, Постгрес, и еще миллион других вещей, который людям не нравится в силу негламурности (и сложных указателей, с кучей мест где можно выстрелить себе в ногу, признаем честно — что налагает дополнительные требования к разрабочтику), зато имеющего долгую историю и накопленный опыт использования.
6. Проектирование баз данных и оптимизация запросов. Всякие там нормальные формы проходят все, а опыт выбора СУБД и создания масштабируемой структуры под реальные данные с последующей оптимизацией работы приходит только с практикой. Но мы же не будем называть неполноценным знающего красно-черные деревья и решающего олимпиадные задачи программиста неполноценным просто потому, что он не имеет опыта и понимания, как работает оптимизатор запросов в PostgreSQL, почему лучше поставить такой составной индекс, а не сякой, и почему нужно тонко настроить параметры сервера для текущей нагрузки чтения/записи.
7. Наконец, мы не можем просто не учитывать общего уровня интеллекта людей и soft skills, EQ/эмпатия.
К примеру, если человек умный и обладает здравым смыслом, то он понимает, что язык — это инструмент. И он не будет писать в реальной работе на Джаве то, что отлично пишется на плюсах и работает без тормозов и бубна (а также жирных серверов и дорогих коллег).
При этом он с радостью возьмет Джаву и весь стэк, если там уже есть готовый фреймворк, библиотеки и опен-сорс софтина, которая решает задачи. А навыки общения с руководителем позволят ему проработать требования и выбрать всю инфраструтуру, разработать архитектуру и тд с учетом возможных изменений и требований бизнеса (а не только интересов типа саморазвития или вечного кайфа от ковыряния новых игрушек типа Scala).
Поэтому, уважаемые коллеги, я бы все-таки более осторожно относился к окружающим и с меньшим количеством пафоса и эмоций. Быть может, кто-то забыл когда-то прочитанные базовые алгоритмы или структуры данных, но его компетенции в той же архитектуре или безопасности настолько превосходят ваши, что смотреть свысока он может и на вас.
Желаю нам всем побольшее эмпатии, и чаще делиться с коллегами интересными ссылками (в том числе показывая выгоду от владения новыми знаниями и навыками), нежели чем делить на своих и чужих.
Live long and prosper.
Автор: Cord
