Ну так и причем тут поиск по чатам? У вас нет культуы, что если одна и та же проблема возникает более одного раза, то её надо документировать? Старожил может и словами сказать, устно, чат в этом примере совершенно не при чем.
Это если сокращения какие то точечные и/или набор людей проблематичный, что явно не про Твиттер. Лично я наблюдал как без зазрений закрывали бранчи (центры разработки), разгоняли команды, да даже вот недавно в компании, где я работаю, уволили 18 тыс человек, включая как и совсем новичков, так и ветеранов с многолетним стажем. Потому не стройте иллюзий, если бизнесу надо будет - он разгонит и/или перенаберет людей, так как в компании, типа Твиттера, очередь за забором стоит постоянно.
Я не понял примера. Лично мне кажется странным пример, когда формат передачи строк между сервисами оговорен только где то в чатах. Возможно, вы встречали компании, которые хранят спецрфикации API в личных переписках, я такого не встречал и не считаю это нормальным.
При сокращениях выставляют на мороз всех подряд. Лучшие или худшие или «ключевые сотрудники» - это все булшит от журналистов. Каждый себя мнит лучшим и незаменимым, а на самом деле заменимы все. Уволят слишком много - наберут ещё людей и все дела. Какое то развитие где то будет медленней, какие то баги будут дольше закрываться, где то систему полихорадит и отпустит, но в целом это ожидаемо при сокращениях.
Зачем документировать то, что уже есть в документации? Тут другой пример уместен. Джуну дали задачу обновить библиотеку с версии Х до версии У. Если это же самое надо сделать для других 100500 сервисов и процесс многоступенчатый, то это явно должно быть документировано джуном где то в общих документах.
Я ничего не предлагаю, говорю чисто из своего опыта. Спрашивать коллег можно где угодно, фиксировать решение критической проблемы конечно надо в соответсвующих документах.
Если мне память не изменяет, в слаке есть retention policy, там через некоторое время вся история очищается. Также, обычно в компаниях требуют всю документацию и важную инфу вести в каком то внутреннем инструменте, а не в инструменте, который может быть заменен в любое время. Вообще, итория в слаке - это, наверное, последнее место, где бы я искал ответы на вопросы.
Твиттер перестраивается довольно сильно, увольнение 75% персонала не может не сказаться на работоспособности - по моему, это должно быть ожидаемо. Хотя, с другой стороны, что же там такого в твиттере, для чего надо 10 000 человек? Даже 3.5 тысячи инженеров выглядит как оверкилл.
Во первых, какие то яркие примеры программистов-самоучек вполне может быть ошибкой выжившего, ведь статистики того, сколько самоучек бросило обучение нет, а таких, я предполагаю, на порядки больше тех, кто имеет академ образование.
Во вторых, нам показывают график и уверяют, что 69% разработчиков - самоучки. Но на том же графике если сложить всех, кто имеет какую то степень в CS или хотя бы колледж, получим чуть ли не 80%. Вероятно, многие, у кого есть степень, точно также считают себя самоучками.
Мы изучаем алгоритмы и структуры данных, и даже умеем обойти двоичное дерево.
Так себе достижение, если честно. Обход деревьев - это рутина, а не какой то вызов в профессии.
Программисты-самоучки – это сообщество, в котором все до одного имеют дело с компьютерами, коммуникацией и данными, а не обязательно хотят работать программистами на полную ставку.
Как и любые другие программисты.
у вас, как у самоучки, есть своя фишка. Вы читаете эту книгу не потому, что вам ее задали, а из желания учиться, и такое желание – наибольшее из всех возможных преимуществ
Как будто у программистов с дипломом этого желания нет. Какой популизм.
Не в обиду самоучкам, но из статьи выходит ощущение, что вот сейчас "докурю и изучу вашу программирование". А на деле получается, что самоучка сначала тратит массу времени, чтобы дорасти до формошлепа, а потом еще больше, чтобы хотя бы какой то уровень подтянуть и не застрять на уровне веб-макаки.
Для работодателя вообще не принципиально, самоучка ты или нет, потому у самоучек нет преимуществ для работодателя. Единственный плюс для самоучек - это то, что для начала работы и получения зарплаты им не надо проводить годы в универе, изучать темы, многие из которых тебе никогда не понадобятся, можно вместо этого потратить 6-12 месяцев на плотную нацеленную учебу и после идти клепать формы и добирать остальные знания на ходу. Наличие же качественного (ключевое слово - качественного) образования позаоляет залетать в компании с мировым именем сразу после универа, минуя годы формашлепства и гонку среди таких же самоучек.
Означает ли, что самоучкой быть плохо? Конечно нет! Но надо понимать, что научиться программировать и строить системы за месяц не получится. Придется долго и усердно учиться уже на работе, восполнять пробелы в основах CS, которых у выпускников с образованием уже давно нет.
Есть много факторов. Если ты пишешь только круды в базу, то знать алгоритмы возможно и не придется. Но это очень простая работа - писать только круды и больше ни о чем не думать. Ну и долго так не каждый сможет работать.
По поводу финтеха - примеры с блоттером и формами как раз были для финтеха, я тогда работал разрабом настольных приложений. Там знания алгоритмов и структур данных были нужны может не каждый день, но весьма регулярно.
Бекендщик бекендщику тоже рознь. Можно и беком просто джейсоны перекладывать, но у меня есть примеры, когда алгоритмы понадобились и при реализации фич на беке, так и при проектировании бека. Так что тут не все так однозначно. Как тут уже писали, даже при проектировании микросервисов и их композиции требуется знание алгоритмов.
По сути - это как ООП. Кто то может сказать, что он просто лепит дтошки и рад этому - в таком случае не надо обладать хоть какими то знаниями ОПП для такой работы. Но если ты хочешь быть реально профессионалом, то тебе надо и ООП знать, и про паттерны, и подходы всякие, и про солиды/граспы и прочее.
Вот в этом и мысль. Жить как программист без знания алгоритмов ты можешь и даже что то делать полезное при этом. Но ты будешь всегда ограничен в своих возможностях, если ты не открывешь области, непосредственно связанные с выполнением своих обязанностей. Если ты пишешь код и не знаешь, быстрый он или медленный, то есть не можешь просто проанализировать эффективность своего кода или обосновать выбор своих структур данных и даже не знаешь, что это проблема - вот это самое печальное.
Я же не говорю про изобретение каких то своих алгоритмов, я говорю про самые основы, просто уметь и применять анализ того кода, что пишешь. Просто уметь обосновать выбор той или иной структуры данных для своей задачи. И применять это постоянно. Даже это повысит качество твоего кода.
Лично для меня освоение этой темы было как вот ощущение, что до этого я ползал по земле на корачках, а потом встал в полный рост и ходить лушче стал, и видеть дальше стал. Я не знаю, как это более доходчиво описать.
Все верно, в программировнии должны быть компромиссы. То же самое про что угодно можно сказать: "с одной стороны - учите солиды\паттерны, с другой - hello, world: enterprise edition".
Я думаю, знание о сбалансированных деревьях поиска тоже полезны. Не обязательно все это уметь кодить самому, но хотя бы знать разницу между сортированным ассоциативным массивом (aka TreeSet\TreeMap) и простым несортированным (например, хешсеты\хешмапы) уже помогают выбрать что больше подходит под задачу.
Про устройство хешсета\хешмапы я вообще молчу, это же основы. Как, например, можно понять зачем перегружать equals и hashcode - если не знаешь зачем этот hashcode - я таких проблем на stack overflow видел не один десяток.
Потому вы правильно говорите, алгоритм - это термин широкий. И без знания основ алгоритмов и структур данных я не представляю, как можно разбираться хотя бы в тех структурах данных, которые сам же используешь в своем же коде.
Да и базовые вещи для многих уже проблема, по моему опыту, чуть меньше трети программистов просто не ориентируются даже в анализе алгоритмов. То есть пишут код и не понимают, быстрый этот код или медленный и каковы последствия роста входных данных. Понимаете, в чем проблема? Одно дело, когда программист пишет медленный код там, где это оправдано. Но другое дело, если программист пишет неэффективный код и даже не знает об этом.
Вот про это и есть курс. Там нет хитрых алгоритмов балансировки деревьев, но я поясняю, что это за зверь такой - двоичное дерево поиска и зачем его балансировать. Или например я покажываю самую простую реализацию хештаблицы и рассказываю, как качество хеш функции влияет на производительность и вообще корректность работы структуры данных. То есть примеры и теория максимально приближены к практике, но не перегружены деталями. Я не стал, например, рассказывать про Кнутта-Морриса-Пратта или Белмана-Форда (а вы как часто это используете?), но рассказал самые основы теории графов и самые популярные обходы (bfs\dfs) с конкретно практическим примером, который встречался мне именно на работе.
К тому же, как вы пишете, бизнес требует навыков в алгоритмах - но бизнес не требует чего то сверхсложного. У меня целый модуль в курсе про собеседования, что просит бизнес и почему он это просит (с моей точки зрения).
Вот такой получился курс, там нет никакого rocket science, но есть конкретные примеры из конкретно моей практики и теория привязана именно к ним.
Я не мог ничего нарушить, ведь я создал свое ПО со своим алгоритмом и приложение, которым пользовались до этого, даже в глаза не видел. Да и посчитайте сами, старое приложение работало минуту, а мое обрабатывало в 450 раз больше данных за 7 секунд - если бы старое и могло столько данных обработать, то по времени это было бы явно сильно долго.
Смотря что подразумевать под "алгоритмами". Знание алгоритмов и структур данных помогает не только писать какие то хитрые алгоритмы. Это также требуется при, например, выборе правильной структуры данных для работы. Или при разделении между алгоритмами и доменной логикой. Чтобы просто пройтись нужным способом по дереву, надо какое то минимальное знание алгоритмов. Да даже если вы проектируете систему (проектируете, не кодите), можно использовать анализ алгоритмов, чтобы примерно представлять возможности масштабирования системы.
Потому ваши 1% ну сильно приуменьшены. По моему опыту процент будет в десятки раз больше. Наверное вы имеете ввиду случаи, когда надо реально какой то свой алгоритм изобретать - это да, это редко.
Я не уточнял, если честно. Я помню, что ограничение лицензии не позволяло переносить ПО на другую машину. Предположу, что ограничили из за скорости работы, чтобы пользователь ждал ответа разумные минуты, а не часы.
Большие формы - это было частью бизнес процессов, типичная вещь в той доменной области, где я тогда работал.
С точки зрения программирования, скорость работы с такими формами решалась виртуализацией. Но это не отменяет модели с кучей полей. Кнонечно, это не означает 10к+ полей в DTO, так как у нас были составные поля (например, в гриде каждая ячейка считалась отдельным полем, значит грид 10х10 = 100 полей).
Конечно, это не есть хорошо и с точки зрения UI/UX, с этим борятся другими методами, не связанными с алгоритмами.
Курс действительно хороший, я бы всем рекомендовал. Он из двух частей состоит. Мне запомнилось что там клёвые практические задания, то картинку пережать, то расстояние между словами найти. В общем топ курс как по мне, хотя емнип охватывает не всю теорию из книги.
e-maxx хороший ресурс, если знаешь конкретно какие тебе надо алгоритмы знать заранее. Если же у тебя программы нет, то подборка от профессионалов будет хорошим выбором. В книге, что я посоветовал, как раз про это - самая важная инфа для разработчиков, без перемудреных алгоритмов. Ну по крайней мере мне было очень это доступно и интересно изучить.
Ну так и причем тут поиск по чатам? У вас нет культуы, что если одна и та же проблема возникает более одного раза, то её надо документировать? Старожил может и словами сказать, устно, чат в этом примере совершенно не при чем.
Это если сокращения какие то точечные и/или набор людей проблематичный, что явно не про Твиттер. Лично я наблюдал как без зазрений закрывали бранчи (центры разработки), разгоняли команды, да даже вот недавно в компании, где я работаю, уволили 18 тыс человек, включая как и совсем новичков, так и ветеранов с многолетним стажем. Потому не стройте иллюзий, если бизнесу надо будет - он разгонит и/или перенаберет людей, так как в компании, типа Твиттера, очередь за забором стоит постоянно.
Я не понял примера. Лично мне кажется странным пример, когда формат передачи строк между сервисами оговорен только где то в чатах. Возможно, вы встречали компании, которые хранят спецрфикации API в личных переписках, я такого не встречал и не считаю это нормальным.
При сокращениях выставляют на мороз всех подряд. Лучшие или худшие или «ключевые сотрудники» - это все булшит от журналистов. Каждый себя мнит лучшим и незаменимым, а на самом деле заменимы все. Уволят слишком много - наберут ещё людей и все дела. Какое то развитие где то будет медленней, какие то баги будут дольше закрываться, где то систему полихорадит и отпустит, но в целом это ожидаемо при сокращениях.
Зачем документировать то, что уже есть в документации? Тут другой пример уместен. Джуну дали задачу обновить библиотеку с версии Х до версии У. Если это же самое надо сделать для других 100500 сервисов и процесс многоступенчатый, то это явно должно быть документировано джуном где то в общих документах.
Я ничего не предлагаю, говорю чисто из своего опыта. Спрашивать коллег можно где угодно, фиксировать решение критической проблемы конечно надо в соответсвующих документах.
Если так, то это жесть конечно, уровень оверинжиниринга зашкаливает.
Потому чат мессенджеры и ненадежны для базы знаний. Для этого есть разные дизайн доки, ранбуки, вики, заметки и прочее. Даже внутренние q&a сервисы.
Если мне память не изменяет, в слаке есть retention policy, там через некоторое время вся история очищается. Также, обычно в компаниях требуют всю документацию и важную инфу вести в каком то внутреннем инструменте, а не в инструменте, который может быть заменен в любое время. Вообще, итория в слаке - это, наверное, последнее место, где бы я искал ответы на вопросы.
Твиттер перестраивается довольно сильно, увольнение 75% персонала не может не сказаться на работоспособности - по моему, это должно быть ожидаемо. Хотя, с другой стороны, что же там такого в твиттере, для чего надо 10 000 человек? Даже 3.5 тысячи инженеров выглядит как оверкилл.
Какая то популистская статья.
Во первых, какие то яркие примеры программистов-самоучек вполне может быть ошибкой выжившего, ведь статистики того, сколько самоучек бросило обучение нет, а таких, я предполагаю, на порядки больше тех, кто имеет академ образование.
Во вторых, нам показывают график и уверяют, что 69% разработчиков - самоучки. Но на том же графике если сложить всех, кто имеет какую то степень в CS или хотя бы колледж, получим чуть ли не 80%. Вероятно, многие, у кого есть степень, точно также считают себя самоучками.
Так себе достижение, если честно. Обход деревьев - это рутина, а не какой то вызов в профессии.
Как и любые другие программисты.
Как будто у программистов с дипломом этого желания нет. Какой популизм.
Не в обиду самоучкам, но из статьи выходит ощущение, что вот сейчас "докурю и изучу вашу программирование". А на деле получается, что самоучка сначала тратит массу времени, чтобы дорасти до формошлепа, а потом еще больше, чтобы хотя бы какой то уровень подтянуть и не застрять на уровне веб-макаки.
Для работодателя вообще не принципиально, самоучка ты или нет, потому у самоучек нет преимуществ для работодателя. Единственный плюс для самоучек - это то, что для начала работы и получения зарплаты им не надо проводить годы в универе, изучать темы, многие из которых тебе никогда не понадобятся, можно вместо этого потратить 6-12 месяцев на плотную нацеленную учебу и после идти клепать формы и добирать остальные знания на ходу. Наличие же качественного (ключевое слово - качественного) образования позаоляет залетать в компании с мировым именем сразу после универа, минуя годы формашлепства и гонку среди таких же самоучек.
Означает ли, что самоучкой быть плохо? Конечно нет! Но надо понимать, что научиться программировать и строить системы за месяц не получится. Придется долго и усердно учиться уже на работе, восполнять пробелы в основах CS, которых у выпускников с образованием уже давно нет.
Есть много факторов. Если ты пишешь только круды в базу, то знать алгоритмы возможно и не придется. Но это очень простая работа - писать только круды и больше ни о чем не думать. Ну и долго так не каждый сможет работать.
По поводу финтеха - примеры с блоттером и формами как раз были для финтеха, я тогда работал разрабом настольных приложений. Там знания алгоритмов и структур данных были нужны может не каждый день, но весьма регулярно.
Бекендщик бекендщику тоже рознь. Можно и беком просто джейсоны перекладывать, но у меня есть примеры, когда алгоритмы понадобились и при реализации фич на беке, так и при проектировании бека. Так что тут не все так однозначно. Как тут уже писали, даже при проектировании микросервисов и их композиции требуется знание алгоритмов.
По сути - это как ООП. Кто то может сказать, что он просто лепит дтошки и рад этому - в таком случае не надо обладать хоть какими то знаниями ОПП для такой работы. Но если ты хочешь быть реально профессионалом, то тебе надо и ООП знать, и про паттерны, и подходы всякие, и про солиды/граспы и прочее.
Вот в этом и мысль. Жить как программист без знания алгоритмов ты можешь и даже что то делать полезное при этом. Но ты будешь всегда ограничен в своих возможностях, если ты не открывешь области, непосредственно связанные с выполнением своих обязанностей. Если ты пишешь код и не знаешь, быстрый он или медленный, то есть не можешь просто проанализировать эффективность своего кода или обосновать выбор своих структур данных и даже не знаешь, что это проблема - вот это самое печальное.
Я же не говорю про изобретение каких то своих алгоритмов, я говорю про самые основы, просто уметь и применять анализ того кода, что пишешь. Просто уметь обосновать выбор той или иной структуры данных для своей задачи. И применять это постоянно. Даже это повысит качество твоего кода.
Лично для меня освоение этой темы было как вот ощущение, что до этого я ползал по земле на корачках, а потом встал в полный рост и ходить лушче стал, и видеть дальше стал. Я не знаю, как это более доходчиво описать.
Все верно, в программировнии должны быть компромиссы. То же самое про что угодно можно сказать: "с одной стороны - учите солиды\паттерны, с другой - hello, world: enterprise edition".
Я думаю, знание о сбалансированных деревьях поиска тоже полезны. Не обязательно все это уметь кодить самому, но хотя бы знать разницу между сортированным ассоциативным массивом (aka TreeSet\TreeMap) и простым несортированным (например, хешсеты\хешмапы) уже помогают выбрать что больше подходит под задачу.
Про устройство хешсета\хешмапы я вообще молчу, это же основы. Как, например, можно понять зачем перегружать equals и hashcode - если не знаешь зачем этот hashcode - я таких проблем на stack overflow видел не один десяток.
Потому вы правильно говорите, алгоритм - это термин широкий. И без знания основ алгоритмов и структур данных я не представляю, как можно разбираться хотя бы в тех структурах данных, которые сам же используешь в своем же коде.
Да и базовые вещи для многих уже проблема, по моему опыту, чуть меньше трети программистов просто не ориентируются даже в анализе алгоритмов. То есть пишут код и не понимают, быстрый этот код или медленный и каковы последствия роста входных данных. Понимаете, в чем проблема? Одно дело, когда программист пишет медленный код там, где это оправдано. Но другое дело, если программист пишет неэффективный код и даже не знает об этом.
Вот про это и есть курс. Там нет хитрых алгоритмов балансировки деревьев, но я поясняю, что это за зверь такой - двоичное дерево поиска и зачем его балансировать. Или например я покажываю самую простую реализацию хештаблицы и рассказываю, как качество хеш функции влияет на производительность и вообще корректность работы структуры данных. То есть примеры и теория максимально приближены к практике, но не перегружены деталями. Я не стал, например, рассказывать про Кнутта-Морриса-Пратта или Белмана-Форда (а вы как часто это используете?), но рассказал самые основы теории графов и самые популярные обходы (bfs\dfs) с конкретно практическим примером, который встречался мне именно на работе.
К тому же, как вы пишете, бизнес требует навыков в алгоритмах - но бизнес не требует чего то сверхсложного. У меня целый модуль в курсе про собеседования, что просит бизнес и почему он это просит (с моей точки зрения).
Вот такой получился курс, там нет никакого rocket science, но есть конкретные примеры из конкретно моей практики и теория привязана именно к ним.
Я не мог ничего нарушить, ведь я создал свое ПО со своим алгоритмом и приложение, которым пользовались до этого, даже в глаза не видел. Да и посчитайте сами, старое приложение работало минуту, а мое обрабатывало в 450 раз больше данных за 7 секунд - если бы старое и могло столько данных обработать, то по времени это было бы явно сильно долго.
Смотря что подразумевать под "алгоритмами". Знание алгоритмов и структур данных помогает не только писать какие то хитрые алгоритмы. Это также требуется при, например, выборе правильной структуры данных для работы. Или при разделении между алгоритмами и доменной логикой. Чтобы просто пройтись нужным способом по дереву, надо какое то минимальное знание алгоритмов. Да даже если вы проектируете систему (проектируете, не кодите), можно использовать анализ алгоритмов, чтобы примерно представлять возможности масштабирования системы.
Потому ваши 1% ну сильно приуменьшены. По моему опыту процент будет в десятки раз больше. Наверное вы имеете ввиду случаи, когда надо реально какой то свой алгоритм изобретать - это да, это редко.
Я не уточнял, если честно. Я помню, что ограничение лицензии не позволяло переносить ПО на другую машину. Предположу, что ограничили из за скорости работы, чтобы пользователь ждал ответа разумные минуты, а не часы.
Большие формы - это было частью бизнес процессов, типичная вещь в той доменной области, где я тогда работал.
С точки зрения программирования, скорость работы с такими формами решалась виртуализацией. Но это не отменяет модели с кучей полей. Кнонечно, это не означает 10к+ полей в DTO, так как у нас были составные поля (например, в гриде каждая ячейка считалась отдельным полем, значит грид 10х10 = 100 полей).
Конечно, это не есть хорошо и с точки зрения UI/UX, с этим борятся другими методами, не связанными с алгоритмами.
Курс действительно хороший, я бы всем рекомендовал. Он из двух частей состоит. Мне запомнилось что там клёвые практические задания, то картинку пережать, то расстояние между словами найти. В общем топ курс как по мне, хотя емнип охватывает не всю теорию из книги.
e-maxx хороший ресурс, если знаешь конкретно какие тебе надо алгоритмы знать заранее. Если же у тебя программы нет, то подборка от профессионалов будет хорошим выбором. В книге, что я посоветовал, как раз про это - самая важная инфа для разработчиков, без перемудреных алгоритмов. Ну по крайней мере мне было очень это доступно и интересно изучить.