Неустаревающие знания в IT  Публичный пост

По следам дискуссии в Вастрик.Вайтборд возник вопрос что вы такого выучили за последние 10-15 лет, что вам пригодилось не раз и чем вы пользуетесь до сих пор? Неважно на каком языке, на каком фреймворке. Просто хочется нащупать то самое вечное, неизменно сияющее знание. Которое раз и навсегда.

Поделитесь также болью. Что вы такого крутого учили в расчете что это на века, а оно оказалось совсем ненужным и бесполезным.

Пригодилось:

  1. SQL - Стандарт постоянно меняется, новые фишки растут в базе как грибы. Но SQL везде, он по-прежнему нужен, люди по-прежнему не хотят учить какой-то новый другой модный подход (Привет, MongoDB). Хаки и трюки, конечно, меняются - 7-8 лет назад можно было выучить хинты в Оракле и получать в некоторых компаниях свои 300 кк/наносек, сейчас такое уже не прокатит.

  2. Азы чтения sql-планов. Базы данных все сложнее и сложнее, но если вы хоть раз оптимизировали запрос и оптимизировали его, этот скилл никогда не уйдет. Да, конечно, придется пробежаться по мануалу, почитать что там в 12 версии Postgres или что у вас там. По-прежнему многие перформанс-проблемы упираются в ту же злополучную базу данных.

  3. Базовые регулярных выражений. Читать регулярные выражения, я так и не научился, но кое-как научился писать. По возможности стараюсь никогда их не писать в коде, но часто приходится выгрузить какие-нибудь данные и быстренько пробежаться регуляркой - ничего лучше не знаю.

  4. Книга "Java concurrency in Practice" - она по-прежнему хороша и актуальна, описывающая concurrency-модель в Java. Примеры с сервлетами из 2006 года сейчас кажутся смешными, но основные примитивы, теория и проблемы, там есть. Эта книга выдержала тест временем. Аналогов за 15 лет не написали.

Не пригодилось:

  1. GOF-Паттерны - большинство паттернов возникло из проблем строго-ООП языков. Языки изменились, функции теперь летают туда-сюда и с ними сменились и паттерны. Только новые паттерным никто в явном виде в одной книге не описал (зато есть 100500 статей паттерны в языке N). Сейчас код пишут по-другому, книга совершенно бесполезная. Нет, ну где-то там в недрах Spring'а есть все эти паттерны, но пишешь в конце-концов на Spring'е, и все равно надо идти в свой фреймворк и смотреть как типовые задачи решаются на нем.

  2. Книга "Рефакторинг" Фаулера - опять же набор рефакторингов включили в IDE, и где-то интуитивно понимаешь как рефакторинг делать. И 90% рефакторингов - это метод правильно назвать. Большую часть своей карьеры я пишу код "рест - stateless бизнес логика - база" или там "взяли из кафки сообщение - сервис - сервис - положили в базу сообщения - отправили в кафку ответ", это сильно облегчает проблему рефакторинга.

  3. SOLID - сами по себе принципы адекватны и разумны, но это часто в свое время спрашивали на интервью, но я лично ни разу не писал код, задумываясь о том "сколько же responsiblity у класса", как-то может это и ловишь но интуитивно ("что-то дохрена этот класс делает, надо разбить" или наоборот). Также ни разу не приходилось осознанно использовать Liskov Substitution Principle, хотя интуитивно опять же скорее всего сталкивался с его нарушениями "какой-то этот наследник кривой и совсем неправильно себя ведет". Делать из этих принципов культ мне кажется, было совершенно излишне.

Связанные посты
30 комментариев 👇
Siarhei Krukau, Бэкендщик 21 мая 2020

Английский.

Если нужно указать один навык, то это определённо и стопроцентно английский язык. Не устаревает никогда, развивать можно и нужно постоянно. Это ключ ко всему остальному.

  Развернуть 1 комментарий

ну я бы сказал, что потихоньку устаревает все-таки

  Развернуть 1 комментарий

@ganqqwerty, да? В угоду чему? Китайскому?

  Развернуть 1 комментарий

@ganqqwerty, как человек, разговаривающий с клиентами исключительно на английском, категорически не согласен =)

  Развернуть 1 комментарий

@madhead, ну да

  Развернуть 1 комментарий

@ganqqwerty, ну, возможно-возможно. Но, думаю, на наш век ещё хватит :)

  Развернуть 1 комментарий
Andrey Kucherov, Руковожу проектным офисом 21 мая 2020

Базовое знание по сетям. Модель OSI, топологии сетей, TCP и UDP, чтение вывода ping & tracert. Прошёл этом сам и предлагаю проходить другим в курсе Cisco CCNA.

  Развернуть 1 комментарий

Модель OSI

Знание всех семи уровней мне как-то ни разу не пригодились в жизни, даже на собеседованиях не спрашивали. Достаточно было понимания принципов работы протокола TCP/IP и Ethernet/ARP.

  Развернуть 1 комментарий
Maxim Syabro, Стартапы, вебдев, фото, техно 21 мая 2020

Неустаревающие знания это софтскиллы.
Технологии меняются, люди нет.
Умение договариваться, эмпатия, понимание как принимаются решения и почему будут актуальны всегда.

  Развернуть 1 комментарий

Оу оу. А что вы используете вместо quick sort можно узнать? Техологии то меняются.

  Развернуть 1 комментарий

@norguhtar, нанимаю группу консультантов которая решает оптимален ли квиксорт или можно быстрее по времени сделать пузырьком. Также необходимо уточнить - возможен ли вариант когда сортировать может краудсорсинг типа Толоки или Amazon Mechanical Turk. Потом создается проектная группа и достаточно быстро за пару недель она пишет ТЗ и спецификацию. Думаю страниц на 40 хватит. С ТЗ уже можно идти к инвесторам получать деньги. Ну и в конце с тз пара HR нанимает лида с группой программистов которые умеют в квиксорт, но не умеют смотреть шире.

  Развернуть 1 комментарий

@syabro, одна из причин почему я ушел из большой компании :) Когда я шел срезать углы мне рассказывали, что так не надо. Сначала надо показать что мы "преодолевали" :))

  Развернуть 1 комментарий

@norguhtar, да я сам по стартапам по этой же причине :)

Если серьезно - то квиксорт это как типы данных или основы логики. Либо ты работаешь программистом и знаешь это все либо не работаешь программистом и это допзнания которые не уверен что нужны.
Софтскиллы же я уверен нужны абсолютно всем :)

  Развернуть 1 комментарий
Gleb Reys, Автор и технический консультант 21 мая 2020

Для администрирования Unix/Linux

Пригодилось :

  • базовые команды Unix/Linux для работы с файловой системой и редактированием текстовых файлов

-понимание того, как работает загрузка компьютера (особенно в свете UEFI)

  • понимание, как запускаются файлы (и что такое shared библиотеки или DLL)
  • знание, что есть реестр Windows и глобальные настройки в Linux/macOS (sysctl, defaults)
  • основы работы с сетями - адресация, пинги, статическая маршрутизация
  • элементы Internet - есть сервисы, они работают на стандартных TCP портах, есть HTTPS/SSL и зачем всем нужен DNS
  • основы сетевых файловых систем NFS/CIFS
  • работа с паролями и ключами SSH

Не особо пригодилось (или вышло из моды)

  • компиляция адра Linux/FreeBSD
  • всякие досконально заучиваемые параметры командной строки
  • названия опций в разных конфигах
  • глубокое знание структур данных типа inode/vnode
  • глубокое знание работы с памятью и её адресацией (на уровне TLB)
  • понимание paging/swapping - в облаках и вовсе swap отключают нынче
  • глубокое знание линковки файлов и работы с выполняемыми программами в операционке
  • глубокое понимание топологий сети и протоколов передачи данных (если не занимаешься сетевым администированием)
  • знание сигналов, семафоров и shared memory (если только не поддерживаешь Oracle базы данных)
  Развернуть 1 комментарий
Yury Katkov, миддл формошлёп 21 мая 2020

Все, что не касается конкретных технологий и библиотек.

  • Как надо было в 75-м читать Брукса, так и сегодня надо его читать.
  • Как надо было в 2006 читать Джоэла - так и сегодня надо.
  • Кнут, Кормэн, Сэджвик - никуда не денутся еще лет сто.
  • Ассемблер как изучали на 8086, так и сегодня можно изучать.
  • Вирт, Керниган и Ритчи.
  • Книжка с драконом по компиляторам,
  • Другая книжка по нормальным формам и ER-диаграммам.
  • "Структура и интерпретация"
  • Паттерны проектирования, Рефакторинг, Энтерпрайзные архитектурные паттерны
  • Три книжки по DDD
  • Чего-нить по процессам, тут общепринятой классики я не знаю. Я по RUP'у узнавал о процессных штуках.
  • Про протоколы сетевые тоже одна и та же книжка. Ну HTTP2 туда добавится, и парочка новых вайфаев.

Вот этот набор даете своему бухгалтеру в фирмеи пусть покупает. В ближайшие лет 10-15 не устареет. А разраб будет проходить мимо библиотеки, достанет книжечку, нехотя прочтет пару страниц - и хренак, месяц работы сэкономился.

  Развернуть 1 комментарий

Странно, постоянно SOLID юзаю.

Single responsibility — чтобы спагетти не писать
Open\closed — чтобы делать инкапсулированные решения без кишок наружу
Liskov — тут сложнее, глубже 2 уровней наследования не заходил очень давно
Interface Segregration — опять же, чтобы не было одного гигантского модуля, который делает все-все-все
Dependency Inversion — а без этого то же API невозможно протестить (если провайдер не подменять на фейковый, то придется на лайв сервер кидать запросы, что долго)

Топикстартер, это как раз-таки неустаревающий принцип разработки.

  Развернуть 1 комментарий

Ну то есть ты прям думаешь в терминах SOLID? У меня тезис что где-то наверное, использую, но осознанно нет. Т.е. нет смысла выделять это в отдельную единицу знания, какие-то осколки СОЛИДа разбросаны "так пишем" и "так не пишут", которое дается в ощущениях. Но это мой экспериенс, мне интересно как у других.

  Развернуть 1 комментарий

@IgorKustov, когда понимание SOLID есть, его не замечаете. Когда понимания SOLID нет, пишется дикий говнокод. Уверен, вы видели такой код :)

  Развернуть 1 комментарий

@XcNih4ZNxLNhGduD, каждый раз, когда при мне поминают паттерны или принципы, значит хотят выпендриться и докопаться. Как правило соблюдение принципов интуитивно, а отступление так же интуитивно обосновано. Но найдётся умник, который испортит код ради "так правильно"

  Развернуть 1 комментарий

@DmitryPopov, вы меня, похоже, не поняли. Топикстартер определил SOLID в категорию "не пригодились", при том, сам признал, что сам их интуитивно соблюдает (как и вы тоже).

Я не говорю, что этим принципам всегда нужно следовать, я говорю, что не стоит говорить "не пригодилось" про то, что пригождается при написании каждой строчки кода на практике, хоть и интуитивно.

Это сейчас нам с вами SOLID интуитивен, а начинаюющим программистам просто необходимо начать понимать эти принципы. Да и, в конце концов, понять их можно за 15 минут чтения на википедии.

Лучше чтобы человек знал SOLID и иногда не применял, чем не знал и не применял никогда.

  Развернуть 1 комментарий
Andrew, Мечтатель кинжалов 22 мая 2020

То, что выучилось и никак не может устареть:

  • Консольные команды. Натурально, все что делается в любой nix системе делается через консоль. От установки библиотек в маке, до запуска серверочка в малине.
  • Понимание азов безопасности личных данных (неожиданно не технический, а поведенческий принцип). Даже базовое понимание помогает при наличии утечек паролей не потерять ничего ценного. Устареть не может, могут только расшириться знания
  Развернуть 1 комментарий
Мишаня, у мамы киберсек инженер и местами SOC аналитик 21 мая 2020

Не пригодилось:

Я бы еще сюда сразу сраного Кнута добавил с его "Искусством программирования" (Да и "конкретная математика" тоже на любителя). Книга-боль, книга-гной. 6(!) битов в байте в его маня-контупере, упоротый ассемблер, странный матан, короче вообще читать никому не стоит имхо. Особенно в в2к20.

  Развернуть 1 комментарий

Пригодилось

Ванильный JS.

Вроде и ушла из вебни сто лет назад, но обнаружила, что во многих BI-инструментах встроен его интерпретатор, часто сильно урезанный, но им бывает гораздо удобнее пользоваться, чем некоторым нативным функционалом.

  Развернуть 1 комментарий

Сюда же знание селекторов - меня часто выручает, когда пользуюсь AdBlock - приходится вручную ему прописывать селектор, т.к. сам он предлагает не то, что нужно.

  Развернуть 1 комментарий
Anatoly Shipitsin, Специалист по НЕХ 21 мая 2020

большинство паттернов возникло из проблем строго-ООП языков. Языки изменились, функции теперь летают туда-сюда и с ними сменились и паттерны.

А вот и нет. Мне недавно потребовалось написать ORM и да представьте себе я надергал паттернов оттуда.

Не устаревает алгоритмическая база. А так же парадигмы программирования. Сейчас вот история делает спираль и мы опять начинаем писать в функциональном стиле. Если до этого писали потому что так получалось жрет меньше ресурсов, то сейчас потому что это внезапно имеет меньше проблем при параллельных вычислениях.

  Развернуть 1 комментарий
Daniel Bilyk, Werkstudent-автоматизатор сервисного маркетинга БМВ. 22 мая 2020

Я буду здесь немного мимо кассы, но, кажется, это хорошее место, чтобы попросить помощи. Будет Вастрик.Стековерфлоу на минималках.

Я захотел научиться в баш. Мне кажется, обзавестись базовыми знаниями в обращении с командной строкой совершенно не лишне, тем более, что через неё можно в одну строчку делать простейшие вещи, для которых не нужно знать и уметь практически ничего (youtube-dl тому отличный пример).

Нашёл классный курс от MIT и пока что мне идёт очень тяжело, но от этого ещё интереснее. Тут есть кто-то, к кому можно было бы обратиться со стыдными вопросами, которые всегда стеснялся спросить? «Почему так?», «Почему вот так работает, а если сделать иначе — не работает?», вот в таком ключе.

Чтобы вы понимали уровень: вчера у меня ушло 3 часа, чтобы создать две функции. Функция Х показывает мне current directory и сохраняет этот путь, функция Y cd-шит меня в путь из функции Х где бы я её не запустил.

Мне сложна, нипанятна, но жутко интересно. Кого-то можно раз в никогда позадрачивать вопросами, если гугл не помогает или я даже не понимаю, как свою проблему гуглить?

  Развернуть 1 комментарий

Ох. man bash.

На самом деле могу вам сказать что большая часть этого не потребуется. Чистые sh сценарии пишут все меньше и меньше. Проще взять доступный из коробки python и не страдать :)

Из всего bash надо умение создавать функции и умение в if. Остальное делается через всякие grep awk и прочие консольные утилиты.

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб