Спасибо за интересное и хорошее замечание. Главное, чтобы собеседования проводил тот самый специалист, который сможет всё правильно различить. Правда, у меня у самого десять томов теоретической физики на данный момент больше предметом интерьера служат, надеюсь, когда-нибудь все же смогу осилить.
Если в компании не используют X, в этой компании не надо работать;
Если в компании разработчик решает, какой цвет тени будет смотреться лучше, в этой компании не надо работать. Серьезно, эти вещи либо должен решать специально обученный дизайнер, либо все должно быть заранее решено и браться из дизайн-бука.
Если же он может донести глубокую мысль понятным образом в несколько слов, то и в коде он будет прост и нагляден.
Хорошая мысль, но несколько однобокая. Фейнман понятным образом изложил КЭД, но серьезно учат её все-таки больше по непонятному изложению Фейнмана или книгам Ландау-Лифшица. Сложность многих моделей ограничена снизу и серьезно упростить ее с получением на выходе эквивалентного результата может оказаться невозможно. Некоторые мысли при изложении в несколько слов существенно теряют в глубине. Другое дело, что от по-настоящему умного человека, который не ставит первоочередной целью произвести впечатление, ты практически никогда не услышишь слов, значения которых не знаешь.
«сильный» разработчик поинтересуется у менеджера или заказчика, насколько это важно делать прямо сейчас, и реальна ли вообще проблема, прежде чем ее решать.
Ну да, ну да. Заказчик скажет, что такая проблема не реальна. А когда вся система ляжет на проде из-за того, что два запроса от разных пользователей конкурируют за общий слот, заказчик скажет, что это его вина и никаких претензий к разработчику он не имеет. Именно так это и работает.
— Задачи такого рода нужно всегда решать именно так;
Разработчик, решая задачу, которая уже неоднократно решена в проекте, подключает для этого стороннюю библиотеку, потому что она решает эту задачу лучше (как ему кажется), или ему просто хочется ее попробовать.
Это может быть случаем «синдрома утенка», когда разработчик просто «прикипает» к подходу, который он применил для решения аналогичных задач в первый раз, романтизирует его и с тех пор продолжает пользоваться только им.
М-м-м, вкуснота, взаимопротиворечащие параграфы подвезли! А что, если сторонняя библиотека и правда решает эту задачу лучше? Вот только этого не удастся узнать, пока не попробуешь. Чтобы развиваться профессионально, нужно много узнать, а для этого надо постоянно интересоваться чем-то новым.
то скорее всего получите ответ типа: «8-10 часов, но в выходные и отпуске, возможно, чуть меньше»
Не баян, а классика
Время — 18. 00, все сотрудники сидят трудятся. Один из сотрудников выключает компьютер, одевает пиджак, берет портфель и уходит. Все провожают его неодобрительным взглядом.
Следующий день. В 18. 00 тот же сотрудник выключает компьютер, одевает пиджак, берет портфель и уходит. Все продолжают работать и начинают недовольно шептаться.
Следующий день. В 18. 00 тот же сотрудник выключает компьютер, одевает пиджак, берет портфель и тут к нему подлетает коллега. — Вася, как тебе не стыдно, мы сидим работаем, конец квартала, столько работы, нам тоже хочется вовремя домой а ты такой единоличник... — Ребята, да я вообще в ОТПУСКЕ!!!
Сначала подумал, что какая-то опечатка, но если автор искренне считает, что насыщенная прочими интересами жизнь не совместима с программированием, то, видимо, нет.
Насчет честности согласен, в идеальном мире так и должно быть. Единственное, насколько понимаю, есть нюанс: поправьте, если я ошибаюсь, но согласно трудовому законодательству работодатель как раз не может в любой момент указать на дверь. Уволить сотрудника, который прошел испытательный срок и не имеет совсем явных косяков типа прогулов — это очень нетривиальный квест для работодателя. И вот тут да, срочные контракты — это крайне удобный инструмент, который гарантирует и некий минимальный срок работ и возможность относительно безболезненно расстаться, если что-то не устроило.
Например, мы берем верстальщика, а он рассказывает, что мечтает стать фотографом.
Что-то призадумался. Скорее всего, в эту игру можно играть вдвоем. Наверняка соискатель может выполнить такую же последовательность логических шагов и понять, что не стоит откровенно палиться на предмет проходной работы, а надо сидеть и с честными глазами говорить о том, что верстальщик -- это работа мечты всей его жизни. Интересно, в реальной жизни часто встречаются описанные случаи?
У вас была какая-то тактика и вы ее придерживались?
У вас была какая-то тактика и вы ее придерживались? – Нет, у нас не было конкретной защиты, мы просто не давали им нападать на нас. Но мы, по сути, защищали своих же. Их было немного. И когда я получил травму, а потом опять же получил повреждение наш товарищ, то мы не могли играть в полную силу. Мы играли очень самоотверженно и старались играть только на победу. Именно на это я рассчитывал после этого матча. Да, были ошибки, но нам надо было выиграть.
По поводу рассмотрения состава среднего пороха до появления всяческих бездымных смесей.
В какой-то момент, вероятно, еще до конца XV века, пороховых дел мастера начали испытывать новый способ перетирания пороха — именно благодаря этому уже в следующем столетии удалось устранить и угрозу взрыва, и опасность отсыревания. А заодно чрезвычайно увеличить взрывную силу и практичность порошка. Чтобы уменьшить опасность взрыва, мастера стали добавлять в ступу небольшое количество жидкости. Иногда использовались очищенные винные спирты, которые, как полагали, способны вытягивать загрязнения. В почете была также человеческая моча, особенно моча пьяницы, а лучше всего — пьющего епископа. В результате увлажнения пыли стало меньше — значит, уменьшился риск случайного взрыва. Вместо рыхлого порошка получалась влажная паста, которую, правда, еще нужно было просушить, но конечный продукт вполне стоил дополнительных усилий.
Вопрос долговечности хранения сам по себе не исчерпывающий. Допустим, мы лет через десять нашли дискетку, пролежавшую в конверте, в сейфе, экранированном, сухом и вообще всячески защищенном. Задача найти где-нибудь работающий считыватель будет решаемой, но не самой тривиальной.
Ну тогда для полноты картины давайте уже разделим честность монеты от честности бросающего. Насколько мне известно, было теоретически, а затем и экспериментально доказано, что можно подбросить монету так, что она не перевернётся, причем внешне бросок будет выглядеть честным. Этим могут овладеть иллюзионисты, и при некоторой ловкости рук давать любую наперед заданную последовательность. Ну и для общего развития хотелось бы еще услышать комментарий от знатоков лагранжевой механики, насколько технически легко сделать нечестную монетку, в отличие от тех же костей. Понимаю, что она должна быть несимметричной или с хитрым гуртом, но интересно, как конкретно это реализуется.
Тут выше был задан очень хороший вопрос, можно ли считать 10 достаточно большим числом. И да, всегда есть математическая логика и бытовая интуиция. С точки зрения математической логики вероятность выпадений «решка» ничуть не подозрительней варианта каждое нечетное падение «решка», каждое четное — «орел».
Само собой, для такой тривиальной логики должно подразумеваться, что монетка «честная» (она симметрична, при броске придается случайная сила, эта сила варьируется достаточно хорошо и количество оборотов до падения распределяется равномерно). А дальше уже да, начинается частично статистика, частично физика, частично ловкость рук бросающего.
Все так. Хрестоматийный пример: допустим, вы подбросили монетку десять раз — и все десять раз выпала «решка». Вы бросаете еще раз. Вопрос: какова вероятность, что выпадет снова «решка»? И сколько людей ответят 0,5?
Любопытства ради -- под классикой имеется в виду, что "В космосе никто не услышит твой крик"?
Статья в первую очередь вокруг ООП, поэтому я бы добавил Бертран Мейер. Объектно-ориентированное конструирование программных систем.
Сначала немножко дернулся глаз, потом понял, что это перевод статьи от октября прошлого года.
Спасибо за интересное и хорошее замечание. Главное, чтобы собеседования проводил тот самый специалист, который сможет всё правильно различить. Правда, у меня у самого десять томов теоретической физики на данный момент больше предметом интерьера служат, надеюсь, когда-нибудь все же смогу осилить.
Как плохой разработчик, скажу
Если в компании разработчик решает, какой цвет тени будет смотреться лучше, в этой компании не надо работать. Серьезно, эти вещи либо должен решать специально обученный дизайнер, либо все должно быть заранее решено и браться из дизайн-бука.
Хорошая мысль, но несколько однобокая. Фейнман понятным образом изложил КЭД, но серьезно учат её все-таки больше по непонятному изложению Фейнмана или книгам Ландау-Лифшица. Сложность многих моделей ограничена снизу и серьезно упростить ее с получением на выходе эквивалентного результата может оказаться невозможно. Некоторые мысли при изложении в несколько слов существенно теряют в глубине. Другое дело, что от по-настоящему умного человека, который не ставит первоочередной целью произвести впечатление, ты практически никогда не услышишь слов, значения которых не знаешь.
Ну да, ну да. Заказчик скажет, что такая проблема не реальна. А когда вся система ляжет на проде из-за того, что два запроса от разных пользователей конкурируют за общий слот, заказчик скажет, что это его вина и никаких претензий к разработчику он не имеет. Именно так это и работает.
М-м-м, вкуснота, взаимопротиворечащие параграфы подвезли! А что, если сторонняя библиотека и правда решает эту задачу лучше? Вот только этого не удастся узнать, пока не попробуешь. Чтобы развиваться профессионально, нужно много узнать, а для этого надо постоянно интересоваться чем-то новым.
Спасибо за уточнение, так намного понятнее.
Вот да, если злоупотреблять такими словечками, можно вообще скатиться в "Бревно на спутнике макаку чешет".
Не баян, а классика
Время — 18. 00, все сотрудники сидят трудятся. Один из сотрудников выключает компьютер, одевает пиджак, берет портфель и уходит. Все провожают его неодобрительным взглядом.
Следующий день. В 18. 00 тот же сотрудник выключает компьютер, одевает пиджак, берет портфель и уходит. Все продолжают работать и начинают недовольно шептаться.
Следующий день. В 18. 00 тот же сотрудник выключает компьютер, одевает пиджак, берет портфель и тут к нему подлетает коллега. — Вася, как тебе не стыдно, мы сидим работаем, конец квартала, столько работы, нам тоже хочется вовремя домой а ты такой единоличник... — Ребята, да я вообще в ОТПУСКЕ!!!
Сначала подумал, что какая-то опечатка, но если автор искренне считает, что насыщенная прочими интересами жизнь не совместима с программированием, то, видимо, нет.
Видимо, отметили юбилей Кличко, только что опоздали малость.
Навеяло
Насчет честности согласен, в идеальном мире так и должно быть. Единственное, насколько понимаю, есть нюанс: поправьте, если я ошибаюсь, но согласно трудовому законодательству работодатель как раз не может в любой момент указать на дверь. Уволить сотрудника, который прошел испытательный срок и не имеет совсем явных косяков типа прогулов — это очень нетривиальный квест для работодателя. И вот тут да, срочные контракты — это крайне удобный инструмент, который гарантирует и некий минимальный срок работ и возможность относительно безболезненно расстаться, если что-то не устроило.
Что-то призадумался. Скорее всего, в эту игру можно играть вдвоем. Наверняка соискатель может выполнить такую же последовательность логических шагов и понять, что не стоит откровенно палиться на предмет проходной работы, а надо сидеть и с честными глазами говорить о том, что верстальщик -- это работа мечты всей его жизни. Интересно, в реальной жизни часто встречаются описанные случаи?
Лучшую систему раннего реагирования описал Сергей Довлатов.
У вас была какая-то тактика и вы ее придерживались?
У вас была какая-то тактика и вы ее придерживались? – Нет, у нас не было конкретной защиты, мы просто не давали им нападать на нас. Но мы, по сути, защищали своих же. Их было немного. И когда я получил травму, а потом опять же получил повреждение наш товарищ, то мы не могли играть в полную силу. Мы играли очень самоотверженно и старались играть только на победу. Именно на это я рассчитывал после этого матча. Да, были ошибки, но нам надо было выиграть.
Келли Дж. Порох. От алхимии до артиллерии.