действительно, ведь ИТ - это сайты и дашборды. Ну ещё игры!
А не ваш компьютер, на котором вы пишите это сообщение, сервера мобильной связи, диспетчеризация всего транспорта в мире, кроме частного, смартфоны у всего платежеспособного населения планеты, медицинское оборудование чуть сложнее чем стетоскопа. За пивом вышел, расплатился карточкой, опять влип в ИТ. При этом жена позвонила чипсов захватить, ну вы поняли.
Что такое ИТ? Ну сайтикы и дашборды, а что ещё, действительно?!.. Надстройка, ничем не подкреплённая!
(какое количество т.н. "реального" сектора в 21-м веке без ИТ превращается в тыкву? В денежном выражении - почти весь, если отбросить пошив трусов и распил брёвен, да и тут сомнения, все "заводы и СХ" плотно зависят от ИТ, потому что экономика, доставка, связь и проч.)
"он заставлял их сталкиваться с вопросами более высокого уровня сложности"
Нисколько не противореча основному пафосу статьи, хочется отметить: казалось бы, вся статья ведёт к строго противоположному выводу по поводу сложности? Как только иишечка забрала у студентов необходимость возиться с технической стороной вопроса, как стартапы посыпались как из ведра буквально за считанные недели?
Ну и какие же тогда вопросы более высокого уровня сложности? Из эксперимента получается строго наоборот: техническая сторона вопроса это бутылочное горлышко, а вот здравый смысл и правильные акценты при продумывании продукта - элементарный навык (ведь этому, как мы видим из статьи, научиться сравнительно легко, не более восьми недель. Попробуй роди фулстек-программиста за два месяца).
Любая борьба за метрики вместо качества даёт очевидный результат: улучшение метрик вместо качества. Теперь, если у разработки появилось понимание, что определённый класс багов следует из неудачного архитектурного решения, у них есть два выхода:
исправление проблемы, регулярная работа над техдолгом, это долго и сложно, зато решает проблему по-настоящему
заткнуть пальцем плотину, вставить костыль и поднять метрику за счёт починки багов, но оставить техдолг, который отстрелит гораздо большие трудозатраты через год или два.
В результате компанейщины будет выбрано второе решение. Метрики подняты, премии получены, скорость разработки и перспективы развития ухудшены.
Инженерная работа вообще часто сводится к поиску компромисса (без учёта пет-проектов). Напишешь что-то обобщённное - будет труднее поддерживать, но легче расширять функциональность. Мало тестов - ненадёжно, много тестов - хрупко. Монолит - быстро, микросервисы - масштабируемо. Ну и так далее, все здесь знают.
Поэтому автор любой статьи, который криком кричит в пользу одной из крайностей, каждый раз вызывает изумление: как он вообще работает-то? Он же должен с ума сойти от несоответствия природных наклонностей выбранной профессии.
Ну да, избыточный техдолг это опасно, нельзя допускать, и вообще бывают технические работы, которые трудно объяснить заказчику. Каким образом отсюда следует, что у бизнеса нет сроков и потребностей, совершенно невозможно догадаться, если только не прийти к выводу, что заметка написана ради срача.
Березовский и Дерипаска спокойно судились в Высоком суде Лондона по поводу российских активов. Именно по поводу соответствия сделок по ним российским же законам.
Если у вас есть активы в Великобритании и у Apple есть, видимо, принципиально идея рабочая. Но на практике, предположительно, множество сложностей.
И что? Вы сами подтверждаете, что у частей номера есть семантическое значение. Допустим, меня интересует обработка "регионов, в которых напечатан паспорт", что дальше? Хранить их в переводе на немецкий? В римских цифрах?
Таким образом, способ хранения опять зависит от решаемых задач. Если честно, это настолько очевидное утверждение, что я не понимаю, о чем тут можно спорить,если не задаться целью спорить.
Претензии же к "теоретичности" в контексте собеседования (а статья про собеседование) вообще вызывают недоумение. Разумеется, это теоретический пример, а что же это ещё можно обсуждать на собеседовании, продуктовое решение?
Не "опровергли", а "отвергли". Эти слова имеют разное значение и разную эмоциональную окраску.
Отвергли: возразили, что на самом деле изображения недоступны. Например: сторонники плоской земли отвергли утверждения, что она имеет какую-то другую форму.
Опровергли: предоставили доказательства, что на самом деле изображения недоступны. Например: сторонники неплоской земли с помощью фотографий опровергли утверждения, что она плоская.
PS: И да, "ссылку невозможно сгенерировать" не означает, что "изображения недоступны", это два разных утверждения. Изображения недоступны, если их невозможно получить, вне зависимости от способа утечки ссылки.
Мусор на входе - мусор на выходе (и прочие грубые выражения про тз и хз)
Я спрашиваю: на чём рисовать будем? Она: «Matplotlib, так как там проще всего реализовать предложенную задумку». И я поверил...
А не надо верить, это же не волшебство. Надо не полениться и написать два абзаца текста "надо нарисовать такую-то вещь в таких-то условиях с такими-то ограничениями, предложи варианты решений и обрисуй плюсы и минусы". Потом прочитать и сказать: ок, я выбираю такую-то библиотеку по такой-то причине, провалидируй моё решение. Потом прочитать и сказать: по итогам нашего обсуждения сформулируй тз на реализацию этой фичи. Потом прочитать и снова сказать, если есть замечания к этому тз. И только потом уже, с хорошими формулировками тз и готовым контекстом, пусть пишет (по хорошему, ещё описать свои приблизительные ожидания от реализации, но тут важно не переборщить, если сам не знаешь область). После чего снова надо заставлять писать тесты, проводить код-ревью и все хорошие практики.
То есть всё как с программистом-исполнителем невысокого уровня! А если "поверил", то и с человеком-исполнителем такой же результат будет, только с итерациями не в десятки минут, а в дни.
Это если задаться целью получить результат, а не уесть тупую железяку, конечно.
Если происходит что-то важное и неожиданное, нужно ли ждать дейли, чтобы об этом рассказать?
А человек может и не знать, что у него проблема. Что он решает промежуточную проблему, которую уже позавчера решили в соседней команде. Или что эту проблему год назад решал другой человек и признал её заградительно дорогой. Или что ваши работы случайно пересеклись и вы на мёрже друг другу помешаете. Или что сосед знает более эффективное решение. Разработчик, например, может не отдавать себе отчёта в том, что фичу лучше урезать, если она растягивается, но решить в срок. И так далее, много может что быть.
И дейли тут выступает в роли милиционера на лошади - одна голова хорошо, а две лучше.
В простых потоковых задачах это, может быть, и не нужно, а в сложных проектах с большим количеством контрибьюторов без постоянной коммуникации постоянно кто-нибудь будет забредать не туда, не по злобе, а просто ну потому что разработчик заведомо знает меньше, чем пять разработчиков.
А всё потому что, оказывается, созвониться на 15 минут в день придумал злой лид от безделья.
Интересно, а на каком-нибудь юридическом форуме сотрудники этой фирмы, наверное, спрашивают совета по поводу тонкостей маршрутизации или там виртуализации, да?
Это ответ на другой вопрос. У многих государств есть способы влияния (и даже радикального влияния) на другие государства. Это не значит, что само понятие "разные государства" не существует. И вся эта риторика "по любому чиху" в этом контексте очень пахнет демагогией. По любому чиху из Америке полмира на уши встаёт, но это не значит, что нет других государств, кроме США.
Исходный тезис "ещё не заграница" вовсе не апеллирует к большим возможностям России давить на соседей. Это выражение означает, что соседей вовсе не существует, они не заграница, они по сю сторону границы. Это глупость и, если так можно выразиться, геополитический нарциссизм. Казахстан и Кыргызстан во-первых, существуют, а во-вторых, строят политику на постоянном балансировании между Россией и Китаем, то есть очень сильно заграница для России.
А что такое Казахстан и Кыргызстан, если не заграница? Другие законы, другой государственный аппарат, другой визовый режим с разными странами, другие экономика и налоговый режим, другие интересы и возможности. Единственно что - много говорят по-русски, но и это в историческом мастшабе довольно быстро изменяется. Ну и автократии тоже, но свои собственные автократии.
Да, много культурной общности, оставшейся в наследство от советского времени, ну и что? Полмира осколки каких-нибудь империй и имеют их остаточное влияние, но никто не говорит глупостей вроде "Индия это не заграница" или там "Алжир это не заграница". 35 лет государствам уже, а они всё "не заграница". Попробовали бы в 1950-е поутверждать, что СССР не существует.
Для 95 процентов нотбуков/десктопов никаких танцев, бубнов и терминалов давно не нужно, всё то же самое: установил установщиком, пользуешься руками. Через полчаса уже и забыл, какая там у тебя операционная система.
Но вопрос вообще не в этом, а в общем тоне статьи: что это за "вам следует перейти", "вам стоит приступить"... Я что, спрашивал совета, что ли, как мне следует поступить? В мире восемь миллиардов людей и у каждого своя причина использовать свою ОС: с какого перепуга какой-то автор решает, что кому следует и стоит?
Если бы автор не покидал таким образом зону своей ответственности, то статья была бы просто неким выражением восторга неофита: глупо, но объяснимо. Но вот этот настырный прозелитизм выглядит уже значительно хуже чем просто "глупо".
(при этом сам я всю жизнь сижу под линуксом, а винда мне непривычна и неудобна, но статья от этого не меньше раздражает)
Всегда есть самый компетентный, и если он не боится принимать решения — то ему не до́лжно бояться и признавать ошибки. Иначе грош ему цена.
Да можно хоть обпризнаваться, можно лоб разбить в монастыре от покаяния, но если в промышленной разработке на любом уровне бас фактор равен единице, то проблема не в самом распрекрасном суперстаре, как бы он ни был готов принимать на себя горы ответственности, а именно в процессе. Т.е. в менеджменте.
"А Basho взяли и разорились" - это не факап, а естественный риск, заложенный в саму природу принятия такого рода решений. Он сыграл, бывает.
Но, допустим, проблема бы была не конкретно в разорении вендора (называть его разорение собственным факапом это кокетство), а произошла бы действителньо ошибка ведущего специалиста, ошибка инженерного плана, выбрали неподходящее 3рд-пати решение, что это означает?
Судя по вашему "смог убедить" - решение принимал не один человек, а некий синклит (и это правильно). А значит, проблема была бы не в одном человеке, а в том, что его предложение неверно рассматривалось. Допустим, вместо полноценного ревью его предложений, с вниканием и собственным исследованием, просто послушали, махнули рукой и согласились. Ну так это опять-таки ошибка не разработчика, а организации процесса. Ч. и т.д.
Если ошибка разработчика становится проблемой для бизнеса - это не ошибка разработчика.
У такого разработчика зона ответственности не меньше, а часто — больше, ибо от его факапов может пострадать весь бизнес.
Не может.
Если от факапов разработчика может пострадать весь бизнес, значит, неправильно поставлены планирование и тестирование. И, возможно, найм.
Если от факапа разработчика внезапно пострадал весь бизнес, то это факап не разработчика, а его менеджмента (лида, инжиниринг-менеджера или кого бы то ни было)
Это так не работает. Недостаточно просто быть умным джуном.
Знания получаются разными путями, в том числе активным и пассивным. Когда вы читаете на новом языке, вы не учитесь на нём говорить, даже если вы читаете очень много - это просто разные навыки. Потому что когда вы читаете, вам не надо принимать решения (выбор правильных выражений), и при чтении навык этого принятия решения не вырабатывается, вырабатывается другой навык. Вот и получается - человек нормально читает, а сказать ни бэ ни мэ.
Если джун не будет принимать большое, очень большое количество правильных и неправильных решений на мелком уровне (из чего и складывается кодирование), ему будет трудно прогрессировать. Есть, конечно, всякие гении, но вайбкодинг попросту отнимает у среднестатистического джуна опыт, и далеко не всякий ум может скомпенсировать отсутствие опыта.
действительно, ведь ИТ - это сайты и дашборды. Ну ещё игры!
А не ваш компьютер, на котором вы пишите это сообщение, сервера мобильной связи, диспетчеризация всего транспорта в мире, кроме частного, смартфоны у всего платежеспособного населения планеты, медицинское оборудование чуть сложнее чем стетоскопа. За пивом вышел, расплатился карточкой, опять влип в ИТ. При этом жена позвонила чипсов захватить, ну вы поняли.
Что такое ИТ? Ну сайтикы и дашборды, а что ещё, действительно?!.. Надстройка, ничем не подкреплённая!
(какое количество т.н. "реального" сектора в 21-м веке без ИТ превращается в тыкву? В денежном выражении - почти весь, если отбросить пошив трусов и распил брёвен, да и тут сомнения, все "заводы и СХ" плотно зависят от ИТ, потому что экономика, доставка, связь и проч.)
Нисколько не противореча основному пафосу статьи, хочется отметить: казалось бы, вся статья ведёт к строго противоположному выводу по поводу сложности? Как только иишечка забрала у студентов необходимость возиться с технической стороной вопроса, как стартапы посыпались как из ведра буквально за считанные недели?
Ну и какие же тогда вопросы более высокого уровня сложности? Из эксперимента получается строго наоборот: техническая сторона вопроса это бутылочное горлышко, а вот здравый смысл и правильные акценты при продумывании продукта - элементарный навык (ведь этому, как мы видим из статьи, научиться сравнительно легко, не более восьми недель. Попробуй роди фулстек-программиста за два месяца).
Любая борьба за метрики вместо качества даёт очевидный результат: улучшение метрик вместо качества. Теперь, если у разработки появилось понимание, что определённый класс багов следует из неудачного архитектурного решения, у них есть два выхода:
исправление проблемы, регулярная работа над техдолгом, это долго и сложно, зато решает проблему по-настоящему
заткнуть пальцем плотину, вставить костыль и поднять метрику за счёт починки багов, но оставить техдолг, который отстрелит гораздо большие трудозатраты через год или два.
В результате компанейщины будет выбрано второе решение. Метрики подняты, премии получены, скорость разработки и перспективы развития ухудшены.
Инженерная работа вообще часто сводится к поиску компромисса (без учёта пет-проектов). Напишешь что-то обобщённное - будет труднее поддерживать, но легче расширять функциональность. Мало тестов - ненадёжно, много тестов - хрупко. Монолит - быстро, микросервисы - масштабируемо. Ну и так далее, все здесь знают.
Поэтому автор любой статьи, который криком кричит в пользу одной из крайностей, каждый раз вызывает изумление: как он вообще работает-то? Он же должен с ума сойти от несоответствия природных наклонностей выбранной профессии.
Ну да, избыточный техдолг это опасно, нельзя допускать, и вообще бывают технические работы, которые трудно объяснить заказчику. Каким образом отсюда следует, что у бизнеса нет сроков и потребностей, совершенно невозможно догадаться, если только не прийти к выводу, что заметка написана ради срача.
Березовский и Дерипаска спокойно судились в Высоком суде Лондона по поводу российских активов. Именно по поводу соответствия сделок по ним российским же законам.
Если у вас есть активы в Великобритании и у Apple есть, видимо, принципиально идея рабочая. Но на практике, предположительно, множество сложностей.
И что? Вы сами подтверждаете, что у частей номера есть семантическое значение. Допустим, меня интересует обработка "регионов, в которых напечатан паспорт", что дальше? Хранить их в переводе на немецкий? В римских цифрах?
Таким образом, способ хранения опять зависит от решаемых задач. Если честно, это настолько очевидное утверждение, что я не понимаю, о чем тут можно спорить,если не задаться целью спорить.
Претензии же к "теоретичности" в контексте собеседования (а статья про собеседование) вообще вызывают недоумение. Разумеется, это теоретический пример, а что же это ещё можно обсуждать на собеседовании, продуктовое решение?
У чисел в паспорте есть семантика, и вы вполне можете её использовать. Сортировать по региону, по году выпуска, к примеру.
Правильный ответ: зависит от целей и способа использования этих данных, в задаче это не описано.
Статья глупая.
Моя твоя русского языка не понимай.
Не "опровергли", а "отвергли". Эти слова имеют разное значение и разную эмоциональную окраску.
Отвергли: возразили, что на самом деле изображения недоступны. Например: сторонники плоской земли отвергли утверждения, что она имеет какую-то другую форму.
Опровергли: предоставили доказательства, что на самом деле изображения недоступны. Например: сторонники неплоской земли с помощью фотографий опровергли утверждения, что она плоская.
PS: И да, "ссылку невозможно сгенерировать" не означает, что "изображения недоступны", это два разных утверждения. Изображения недоступны, если их невозможно получить, вне зависимости от способа утечки ссылки.
Мусор на входе - мусор на выходе (и прочие грубые выражения про тз и хз)
А не надо верить, это же не волшебство. Надо не полениться и написать два абзаца текста "надо нарисовать такую-то вещь в таких-то условиях с такими-то ограничениями, предложи варианты решений и обрисуй плюсы и минусы". Потом прочитать и сказать: ок, я выбираю такую-то библиотеку по такой-то причине, провалидируй моё решение. Потом прочитать и сказать: по итогам нашего обсуждения сформулируй тз на реализацию этой фичи. Потом прочитать и снова сказать, если есть замечания к этому тз. И только потом уже, с хорошими формулировками тз и готовым контекстом, пусть пишет (по хорошему, ещё описать свои приблизительные ожидания от реализации, но тут важно не переборщить, если сам не знаешь область). После чего снова надо заставлять писать тесты, проводить код-ревью и все хорошие практики.
То есть всё как с программистом-исполнителем невысокого уровня! А если "поверил", то и с человеком-исполнителем такой же результат будет, только с итерациями не в десятки минут, а в дни.
Это если задаться целью получить результат, а не уесть тупую железяку, конечно.
А человек может и не знать, что у него проблема. Что он решает промежуточную проблему, которую уже позавчера решили в соседней команде. Или что эту проблему год назад решал другой человек и признал её заградительно дорогой. Или что ваши работы случайно пересеклись и вы на мёрже друг другу помешаете. Или что сосед знает более эффективное решение. Разработчик, например, может не отдавать себе отчёта в том, что фичу лучше урезать, если она растягивается, но решить в срок. И так далее, много может что быть.
И дейли тут выступает в роли милиционера на лошади - одна голова хорошо, а две лучше.
В простых потоковых задачах это, может быть, и не нужно, а в сложных проектах с большим количеством контрибьюторов без постоянной коммуникации постоянно кто-нибудь будет забредать не туда, не по злобе, а просто ну потому что разработчик заведомо знает меньше, чем пять разработчиков.
А всё потому что, оказывается, созвониться на 15 минут в день придумал злой лид от безделья.
Интересно, а на каком-нибудь юридическом форуме сотрудники этой фирмы, наверное, спрашивают совета по поводу тонкостей маршрутизации или там виртуализации, да?
Это ответ на другой вопрос. У многих государств есть способы влияния (и даже радикального влияния) на другие государства. Это не значит, что само понятие "разные государства" не существует. И вся эта риторика "по любому чиху" в этом контексте очень пахнет демагогией. По любому чиху из Америке полмира на уши встаёт, но это не значит, что нет других государств, кроме США.
Исходный тезис "ещё не заграница" вовсе не апеллирует к большим возможностям России давить на соседей. Это выражение означает, что соседей вовсе не существует, они не заграница, они по сю сторону границы. Это глупость и, если так можно выразиться, геополитический нарциссизм. Казахстан и Кыргызстан во-первых, существуют, а во-вторых, строят политику на постоянном балансировании между Россией и Китаем, то есть очень сильно заграница для России.
"Вот за это нас и не любят" (с)
А что такое Казахстан и Кыргызстан, если не заграница? Другие законы, другой государственный аппарат, другой визовый режим с разными странами, другие экономика и налоговый режим, другие интересы и возможности. Единственно что - много говорят по-русски, но и это в историческом мастшабе довольно быстро изменяется. Ну и автократии тоже, но свои собственные автократии.
Да, много культурной общности, оставшейся в наследство от советского времени, ну и что? Полмира осколки каких-нибудь империй и имеют их остаточное влияние, но никто не говорит глупостей вроде "Индия это не заграница" или там "Алжир это не заграница". 35 лет государствам уже, а они всё "не заграница". Попробовали бы в 1950-е поутверждать, что СССР не существует.
Лечиться надо от этого гонора.
Для 95 процентов нотбуков/десктопов никаких танцев, бубнов и терминалов давно не нужно, всё то же самое: установил установщиком, пользуешься руками. Через полчаса уже и забыл, какая там у тебя операционная система.
Но вопрос вообще не в этом, а в общем тоне статьи: что это за "вам следует перейти", "вам стоит приступить"... Я что, спрашивал совета, что ли, как мне следует поступить? В мире восемь миллиардов людей и у каждого своя причина использовать свою ОС: с какого перепуга какой-то автор решает, что кому следует и стоит?
Если бы автор не покидал таким образом зону своей ответственности, то статья была бы просто неким выражением восторга неофита: глупо, но объяснимо. Но вот этот настырный прозелитизм выглядит уже значительно хуже чем просто "глупо".
(при этом сам я всю жизнь сижу под линуксом, а винда мне непривычна и неудобна, но статья от этого не меньше раздражает)
Помер и точка
Да можно хоть обпризнаваться, можно лоб разбить в монастыре от покаяния, но если в промышленной разработке на любом уровне бас фактор равен единице, то проблема не в самом распрекрасном суперстаре, как бы он ни был готов принимать на себя горы ответственности, а именно в процессе. Т.е. в менеджменте.
"А Basho взяли и разорились" - это не факап, а естественный риск, заложенный в саму природу принятия такого рода решений. Он сыграл, бывает.
Но, допустим, проблема бы была не конкретно в разорении вендора (называть его разорение собственным факапом это кокетство), а произошла бы действителньо ошибка ведущего специалиста, ошибка инженерного плана, выбрали неподходящее 3рд-пати решение, что это означает?
Судя по вашему "смог убедить" - решение принимал не один человек, а некий синклит (и это правильно). А значит, проблема была бы не в одном человеке, а в том, что его предложение неверно рассматривалось. Допустим, вместо полноценного ревью его предложений, с вниканием и собственным исследованием, просто послушали, махнули рукой и согласились. Ну так это опять-таки ошибка не разработчика, а организации процесса. Ч. и т.д.
Если ошибка разработчика становится проблемой для бизнеса - это не ошибка разработчика.
Не может.
Если от факапов разработчика может пострадать весь бизнес, значит, неправильно поставлены планирование и тестирование. И, возможно, найм.
Если от факапа разработчика внезапно пострадал весь бизнес, то это факап не разработчика, а его менеджмента (лида, инжиниринг-менеджера или кого бы то ни было)
Эмм... А что такого специфически русского в слове "тренер"? Чем он, собственно, лучше коуча? То же самое происхождение, только попривычнее.
Так о том и речь, что нужность слова определяет практика применения, а не этимология.
Это так не работает. Недостаточно просто быть умным джуном.
Знания получаются разными путями, в том числе активным и пассивным. Когда вы читаете на новом языке, вы не учитесь на нём говорить, даже если вы читаете очень много - это просто разные навыки. Потому что когда вы читаете, вам не надо принимать решения (выбор правильных выражений), и при чтении навык этого принятия решения не вырабатывается, вырабатывается другой навык. Вот и получается - человек нормально читает, а сказать ни бэ ни мэ.
Если джун не будет принимать большое, очень большое количество правильных и неправильных решений на мелком уровне (из чего и складывается кодирование), ему будет трудно прогрессировать. Есть, конечно, всякие гении, но вайбкодинг попросту отнимает у среднестатистического джуна опыт, и далеко не всякий ум может скомпенсировать отсутствие опыта.