Когда человек симулирует размышления, часто возникает такое интересное смещение: поскольку ты сам ухватываешь свою несуществующую идею целиком (вовсе и не идею, а смутное ощущение), то тебе кажется, что стоит только её изложить, разбив на главки, а в главках разбить всё на списки - то все сразу поймут твою гениальную (несуществующую) задумку.
Вот этой переоценкой структуры изложения в основном страдают разработчики. Но разработчикам можно, у них другие доблести, а аналитикам - нельзя. Такая структурированность не скрывает пустоту, а кричит о ней. Статья претендует на "полноценный туториал для подготовки к прохождению технического собеседования". Ну мы все в курсе, что такое туториал. Прочитал, ухватил, повторил. Пытаемся прочитать туториал.
Первая главка - вода (структурированная). Вторая главка - вода (структурированная). Третья главка - вода (с оценочным суждениями, без фактов). Четвёртая главка - вода (хаотичные банальности). Пятая главка - вода (структурированные банальности). Шестая главка - три круга из мемасиков. Структурированная пустота, маскирующаяся под содержание. Седьмая главка - "Софты должны быть на достаточно высоком уровне". Вода, даже не пытающаяся казаться полезной. Туториал! ... Заключение.
Кман, если это аналитика на 400к, то я порнозвезда африканского кинорынка.
Этот комментарий не имел бы смысла, если бы перед нами был рядовой корпоративный булшит. Но автор вовлечена, отвечает на комментарии, радеет за своё дело, и можно ожидать, что ей станет стыдно.
Ну тут подмена понятий. Сотрудник заботится не о "благосостоянии компании", а о результатах своего труда (кман, я провожу на работе половину жизни, было бы странно, если бы мне было наплевать на результаты), а благосостояние компании это побочный эффект. Но таким вот транзитивным образом получается, что и о нём тоже сотрудник заботится, просто не это его цель.
Ну и плюс к тому если человек компетентный и ответственный работник - он как раз и не зависит ни от кого, кроме себя самого. По крайней мере в условиях нынешнего рынка труда в нашем айти.
Тут нет никаких противопоставлений, откуда вы их берёте.
Безотносительно всех прочих достоинств вашего, безусловно, поучительного комментария, скажите: как вы умудряетесь в соседних абзацах писать "Хватит поучать" и "Подскажите в чем проблема?".
А по-вашему мультипликаторы 300 растут на деревьях, что ли? Значит, либо настолько высоки были риски, либо такова была его проницательность. Чего же тут несправедливого, если проницательный человек, готовый на риск и рискующий собственными деньгами, получит награду?
Разумеется, за таких людей надо радоваться.
Только, во-первых, таких дядь, сорвавших куш х300 очень мало.
А во-вторых, один такой человек спровоцирует ещё триста предпринимателей вкладываться в рискованные предприятия. Что-то из них выстрелит (большинство - с очень умеренным мультипликатором), что-то нет. Продвижение вперёд методом проверки рискованных гипотез за счёт предпринимателей даёт нам не только зарплаты, но и общий прогресс.
Исследование (рисёч) всегда с неизвестным исходом, в этом его смысл. Но вообще говоря, мысль о том, что исследование нельзя спланировать и декомпозировать, это большое преувеличение.
В начале исследования программист вполне может сформулировать, как он планирует исследовать: - ознакомиться с такими-то материалами - если узнает то-то, то проверить такую-то гипотезу - если это работает, написать прототип - если нет, то поставить более конкретные задачи на другие исследования Это уже декомпозиция, которую можно оценивать. Хоть целиком, хоть по отдельности. Если человек говорит что он хочет "просто посмотреть такую-то тему" без понимания, что и как он будет исследовать, это уже плохой звоночек.
И если этого не делать, человек может месяцами даже не замечать, что занимается ненужной фигнёй. А декомпозиция и оценка (если остальные не понимают в теме - ну ок, не будут ставить оценку, но даже блин кошке полезно объяснить, что ты собираешься делать) спасёт его же самого от непродуктивной траты времени.
Чтобы не заниматься goto и не вносить новых рисков, давно придуманы scope guard и во множестве есть готовые реализации. В том числе и в бусте.
Глобальные переменные убивают тестируемость кода, а также потенциальную возможность параллельного выполнения, необходимость в которой всплывёт именно в тот момент, когда ваша глобальная переменная расползётся по всему коду
ну и так далее
Можно, конечно, и зайца научить курить, но зачем? Люди сорок лет решали проблемы, чтобы взять и в 2024 году от рождества Христова взять и снова приняться за goto.
Это же сравнения на релизной сборке? Ну которые в 180 раз быстрее? Было бы неплохо Бобу пробежаться с профайлером и понять, откуда такая чудовищная разница, для одних только аллокаций что-то многовато.
Скажем так - стиль требует полировки, если мы говорим о С++. Хаотичная и не идиоматичная обработка ошибок, отказ от raii, приведения типов в стиле Си, какие-то избыточные алиасы, пропавшие конструкторы и много такой фигни.
Если говорить о дизайне, по существу буфер и ридер надо разделять, иначе нулевая гибкость.
Два поразительных в своей глубине наблюдения, руководствуясь которыми так легко выстраивать коммуникацию (волшебная пилюля! Работает куда лучше красного капслока и начальства в копии. Держите эти два факта в голове и взаимодействовать становится легче в сто раз. Учёные до сих пор не понимают, как это работает) :
У вас почему-то время интервьюера на собесе ценится, а время ментора на онбординге не ценится
Во время испытательного срока кандидат тоже пожирает время действующих работников, и оно несравнимо с полутора часами, у примеру, двух собеседующих. Да плюс к тому ещё и свою зарплату.
И во многих проектах за две недели испытательного срока вы ничего не поймёте в новичке, потому что в это время новый работник будет вкатываться да набивать шишки на маленьких задачах. А какой-нибудь более-менее показательный перфоманс вы от него увидите через месяц-полтора (вполне типичный испытательный срок)
Обстоятельное собеседованием - это очень большая экономия времени и денег, даже если отбрасывать 95 процентов кандидатов.
Ситуация действительно как с лгбт-повесточкой, а именно: в оьоих случаях противники путают информацию с агитацией. Каким образом статья на хабре может заставить вас писать иначе? Это же просто информация.
Вы имеете в виду, что в природе не существует активных проектов 10+ лет? Это, мягко говоря, не так. Десять лет назад был уже 2014-й год и мир айти уже тогда был довольно большой и значительная часть этих проектов живёт и развивается до сих пор.
Прямо сейчас мы с вами общаемся на сайте 10+ лет, используя броузеры 10+ лет под операционными системами 10+лет, отвлекаясь на месседжеры 10+ лет. Над всеми ними прямо сейчас работают заметное количество программистов.
Не очень понятно, о чем речь. Простые вещи надо делать просто, в этом посыл? Ну да.
А сложные вещи надо проектировать с учётом сложностей, и это может быть сложно. Сложность же невозможно убить. Если у вас проект на годы и с запланированными тысячами точек расширения, то вы не можете сделать просто, иначе вам всю жизнь придётся переписывать всё с нуля.
Когда человек симулирует размышления, часто возникает такое интересное смещение: поскольку ты сам ухватываешь свою несуществующую идею целиком (вовсе и не идею, а смутное ощущение), то тебе кажется, что стоит только её изложить, разбив на главки, а в главках разбить всё на списки - то все сразу поймут твою гениальную (несуществующую) задумку.
Вот этой переоценкой структуры изложения в основном страдают разработчики. Но разработчикам можно, у них другие доблести, а аналитикам - нельзя. Такая структурированность не скрывает пустоту, а кричит о ней. Статья претендует на "полноценный туториал для подготовки к прохождению технического собеседования". Ну мы все в курсе, что такое туториал. Прочитал, ухватил, повторил. Пытаемся прочитать туториал.
Первая главка - вода (структурированная).
Вторая главка - вода (структурированная).
Третья главка - вода (с оценочным суждениями, без фактов).
Четвёртая главка - вода (хаотичные банальности).
Пятая главка - вода (структурированные банальности).
Шестая главка - три круга из мемасиков. Структурированная пустота, маскирующаяся под содержание.
Седьмая главка - "Софты должны быть на достаточно высоком уровне". Вода, даже не пытающаяся казаться полезной. Туториал!
...
Заключение.
Кман, если это аналитика на 400к, то я порнозвезда африканского кинорынка.
Этот комментарий не имел бы смысла, если бы перед нами был рядовой корпоративный булшит. Но автор вовлечена, отвечает на комментарии, радеет за своё дело, и можно ожидать, что ей станет стыдно.
Да, это бывает. Главное не путать такую ситуацию с первым пунктом)
Комментарий это экзоскелет. Здоровому человеку в обычной жизни он не нужен.
Он нужен, если человек (или код) нездоров
Он нужен, если нагрузка (или когнитивная нагрузка) чрезмерна и это принципиально невозможно устранить. Нечастая ситуация.
Во всех остальных (то есть во всех нормальных) случаях он не нужен
(ну правда бывает ещё автогенерируемая документация, тут метафора ломается)
Ну тут подмена понятий. Сотрудник заботится не о "благосостоянии компании", а о результатах своего труда (кман, я провожу на работе половину жизни, было бы странно, если бы мне было наплевать на результаты), а благосостояние компании это побочный эффект. Но таким вот транзитивным образом получается, что и о нём тоже сотрудник заботится, просто не это его цель.
Ну и плюс к тому если человек компетентный и ответственный работник - он как раз и не зависит ни от кого, кроме себя самого. По крайней мере в условиях нынешнего рынка труда в нашем айти.
Тут нет никаких противопоставлений, откуда вы их берёте.
Скажите, а ум в вашем мире - это такой способ заставить других быть глупее, да?
Безотносительно всех прочих достоинств вашего, безусловно, поучительного комментария, скажите: как вы умудряетесь в соседних абзацах писать "Хватит поучать" и "Подскажите в чем проблема?".
А по-вашему мультипликаторы 300 растут на деревьях, что ли? Значит, либо настолько высоки были риски, либо такова была его проницательность. Чего же тут несправедливого, если проницательный человек, готовый на риск и рискующий собственными деньгами, получит награду?
Разумеется, за таких людей надо радоваться.
Только, во-первых, таких дядь, сорвавших куш х300 очень мало.
А во-вторых, один такой человек спровоцирует ещё триста предпринимателей вкладываться в рискованные предприятия. Что-то из них выстрелит (большинство - с очень умеренным мультипликатором), что-то нет. Продвижение вперёд методом проверки рискованных гипотез за счёт предпринимателей даёт нам не только зарплаты, но и общий прогресс.
Исследование (рисёч) всегда с неизвестным исходом, в этом его смысл. Но вообще говоря, мысль о том, что исследование нельзя спланировать и декомпозировать, это большое преувеличение.
В начале исследования программист вполне может сформулировать, как он планирует исследовать:
- ознакомиться с такими-то материалами
- если узнает то-то, то проверить такую-то гипотезу
- если это работает, написать прототип
- если нет, то поставить более конкретные задачи на другие исследования
Это уже декомпозиция, которую можно оценивать. Хоть целиком, хоть по отдельности.
Если человек говорит что он хочет "просто посмотреть такую-то тему" без понимания, что и как он будет исследовать, это уже плохой звоночек.
И если этого не делать, человек может месяцами даже не замечать, что занимается ненужной фигнёй. А декомпозиция и оценка (если остальные не понимают в теме - ну ок, не будут ставить оценку, но даже блин кошке полезно объяснить, что ты собираешься делать) спасёт его же самого от непродуктивной траты времени.
Про проблемы многопоточности, изложенные в этой статье, можно почитать отличные труды Даннинга и Крюгера.
Какое-то адское велосипедирование
Чтобы не заниматься goto и не вносить новых рисков, давно придуманы scope guard и во множестве есть готовые реализации. В том числе и в бусте.
Глобальные переменные убивают тестируемость кода, а также потенциальную возможность параллельного выполнения, необходимость в которой всплывёт именно в тот момент, когда ваша глобальная переменная расползётся по всему коду
ну и так далее
Можно, конечно, и зайца научить курить, но зачем? Люди сорок лет решали проблемы, чтобы взять и в 2024 году от рождества Христова взять и снова приняться за goto.
Это же сравнения на релизной сборке? Ну которые в 180 раз быстрее? Было бы неплохо Бобу пробежаться с профайлером и понять, откуда такая чудовищная разница, для одних только аллокаций что-то многовато.
Скажем так - стиль требует полировки, если мы говорим о С++. Хаотичная и не идиоматичная обработка ошибок, отказ от raii, приведения типов в стиле Си, какие-то избыточные алиасы, пропавшие конструкторы и много такой фигни.
Если говорить о дизайне, по существу буфер и ридер надо разделять, иначе нулевая гибкость.
А так отличное упражнение для Боба, удачи ему.
А какую пользу? Польза от кочевника в деньгах, которые он тратит. Нет денег - нет пользы.
Два поразительных в своей глубине наблюдения, руководствуясь которыми так легко выстраивать коммуникацию (волшебная пилюля! Работает куда лучше красного капслока и начальства в копии. Держите эти два факта в голове и взаимодействовать становится легче в сто раз. Учёные до сих пор не понимают, как это работает) :
Люди не любят, когда им создают проблемы
Люди любят, когда решают их проблемы
У вас почему-то время интервьюера на собесе ценится, а время ментора на онбординге не ценится
Во время испытательного срока кандидат тоже пожирает время действующих работников, и оно несравнимо с полутора часами, у примеру, двух собеседующих. Да плюс к тому ещё и свою зарплату.
И во многих проектах за две недели испытательного срока вы ничего не поймёте в новичке, потому что в это время новый работник будет вкатываться да набивать шишки на маленьких задачах. А какой-нибудь более-менее показательный перфоманс вы от него увидите через месяц-полтора (вполне типичный испытательный срок)
Обстоятельное собеседованием - это очень большая экономия времени и денег, даже если отбрасывать 95 процентов кандидатов.
Потому что термины library, package, module заняты в расте. К примеру, крейт вообще не обязан быть библиотекой.
Ситуация действительно как с лгбт-повесточкой, а именно: в оьоих случаях противники путают информацию с агитацией. Каким образом статья на хабре может заставить вас писать иначе? Это же просто информация.
Вы имеете в виду, что в природе не существует активных проектов 10+ лет? Это, мягко говоря, не так. Десять лет назад был уже 2014-й год и мир айти уже тогда был довольно большой и значительная часть этих проектов живёт и развивается до сих пор.
Прямо сейчас мы с вами общаемся на сайте 10+ лет, используя броузеры 10+ лет под операционными системами 10+лет, отвлекаясь на месседжеры 10+ лет. Над всеми ними прямо сейчас работают заметное количество программистов.
Не очень понятно, о чем речь. Простые вещи надо делать просто, в этом посыл? Ну да.
А сложные вещи надо проектировать с учётом сложностей, и это может быть сложно. Сложность же невозможно убить. Если у вас проект на годы и с запланированными тысячами точек расширения, то вы не можете сделать просто, иначе вам всю жизнь придётся переписывать всё с нуля.
"Таки никому это ощутимо не навредило."
Эмм.. Это ощутимо навредило людям, погибшим в авариях, в которых могли спасти ремни и подушки, нет? Это не слишком смелое допущение?
"Правильно я понял, что без этого принципа невозможно писать гибкий, масштабируемый и поддерживаемый код?"
Претензия уровня "автомобиль позволяет быстро передвигаться? Враньё: быстро передвигаться можно и без автомобиля!"