Да, ваша формулировка гораздо точнее описывает то, что я хотел сказать.
Тогда и вопросы на собеседовании и можно разделить на в. про "знать решения" и в. про "уметь находить решения". Первое, по-идее, требуется компании для получения краткосрочных выгод в ущерб долгосрочным, второе — наоборот.
Я про то, способен ли человек, встретив новую для себя задачу, самостоятельно разобраться в ее предметной области и выбрать подходящее решение. Гуглеж здесь — только инструмент для получения информации. Вопрос еще и в том, сможет ли человек эту информацию грамотно использовать, а также сможет ли заглянуть "за рамки" задачи, чтобы решение было гибким и устойчивым, а не "в лоб".
А то бывают люди с отличной теоретической базой, но как доходит до чего-то нестандартного, так сразу ступор и "нас этому не учили".
это два ортогональных навыка: абстракции программирования и математическая подготовка
Зависит от задач, вестимо. Если векторная алгебра и есть предметная область вашей программы, то наверное разработчику будет неплохо ее знать. Уж точно это не будет минусом.
А в приведенном вами примере это именно отсутствие умения получать знания, о чем я писал выше. Встретив непонятную задачу, человек поленился разобраться в предметной области, а написал велосипед на основе того, как понял. Даже знай он ответ именно на этот вопрос, накосячил бы в другом месте так же.
А в этом случае даже беглое гугление дало бы ответ, как это сделать правильно. То есть, как правильно умножать матрицы, или какую либу для этого использовать.
Зависит от задачи, никто не спорит. Речь шла про проект, где такие задачи возникают раз в месяц… а может вообще никогда. А вы приводите пример про обработку изображений. Понятно, что если ты каждый день работаешь с двумерными массивами, то подобные знания реально нужны.
И опять же, говоря про либы, я, конечно не говорил про OpenCV, драйверы и прочую "низкоуровщину". Умение сделать элегантный костыль или построить эффективный велосипед одинаково поощряется на низком уровне (абстракции) и порицается на высоком.
Или высшее математическое без умения перемножить две матрицы на доске
А либы, либы то на что?
Как по мне, так более важной проблемой является как раз незнание/непонимание более абстрактных сущностей (специфичных для программирования), как принципы и подходы (GRASP/SOLID/<подставьте нужное>), зачем нужен рефакторинг, зачем бить проект на модули и пр.
Потому как если нужно перемножить матрицы, человек может почитать вики и научиться этому за час (а лучше подключить либу). А если нужно понимание, зачем нужна высокая модульность и почему не нужно всю логику лепить в один объект, то на это может уйти год и более.
Для программиста на первом месте не знания, а умение эти знания получать.
Наверно удобная тема чтобы, например, поговорить с ребенком удаленно, например, находясь на работе.
Но вот следить за ребенком, будь то браслет с трекером вроде https://vc.ru/p/wochi-geoplaner, либо скрытая камера — это стремно и стыдно. Нет, я понимаю, когда к грудному ребенку камеру приставляют. Но этот девайс на другой возрас рассчитан. А с детства приучать ребенка к тому, что ему настолько не доверяют, то цепляют датчики либо снимают камерой как пса в клетке, это, имхо, так себе.
К девайсу претензий нет, претензии к тем, кто использует подобное для слежки за своими же детьми.
Если бритва Оккама позволяет отсечь эту функцию, то вполне норм от нее избавиться, считаю.
Имеет смысл запаковывать логику в методы, когда это действительно имеет смысл (вот такая тавтология) — то есть, если там предполагаются изменения, либо она относится к какой-либо отличной зоне ответственности, нежели вызывающий метод, либо имеет место DRY, либо еще что.
Если там дествительно три строки, да и еще название не соответствует, возможно, там когда-то раньше было больше, а потом разработчик это убрал, да поленился остатки перенести назад или переименовать нормально. Избавление от старого хлама есть часть рефакторинга.
Ну а золотая середина (имхо) в том, чтобы придерживаться четких принципов и методологий ака SOLID, GRASP и прочих, которые как раз помогают четко детерминировать границы когда "так" делать, и когда "так" не делать.
Нет, я не об этом. Просто скромно добавленное "И выполнять обратное преобразование для записи данных в мозг" сразу возникла такая картинка в воображении :)
И выполнять обратное преобразование для записи данных в мозг
Сразу представилось, как сидят заказчики над ТЗ, и обсуждают: "а давайте и обратное преобразование с записью добавим, просто ценник за преобразование и запись надвое умножим"
При взгляде на фото невольно напрашивается вопрос — а те конструкции, которые остаются в контакте с воздухом, так и остаются ржавыми, ничем не покрываются после сборки?
Кто-то под GPL, а кто-то под WTFPL, вы об этом? :)
Да, ваша формулировка гораздо точнее описывает то, что я хотел сказать.
Тогда и вопросы на собеседовании и можно разделить на в. про "знать решения" и в. про "уметь находить решения". Первое, по-идее, требуется компании для получения краткосрочных выгод в ущерб долгосрочным, второе — наоборот.
Зависит от контекста
Не совсем про гуглеж, но отчасти и про него.
Я про то, способен ли человек, встретив новую для себя задачу, самостоятельно разобраться в ее предметной области и выбрать подходящее решение. Гуглеж здесь — только инструмент для получения информации. Вопрос еще и в том, сможет ли человек эту информацию грамотно использовать, а также сможет ли заглянуть "за рамки" задачи, чтобы решение было гибким и устойчивым, а не "в лоб".
А то бывают люди с отличной теоретической базой, но как доходит до чего-то нестандартного, так сразу ступор и "нас этому не учили".
Зависит от задач, вестимо. Если векторная алгебра и есть предметная область вашей программы, то наверное разработчику будет неплохо ее знать. Уж точно это не будет минусом.
А в приведенном вами примере это именно отсутствие умения получать знания, о чем я писал выше. Встретив непонятную задачу, человек поленился разобраться в предметной области, а написал велосипед на основе того, как понял. Даже знай он ответ именно на этот вопрос, накосячил бы в другом месте так же.
А в этом случае даже беглое гугление дало бы ответ, как это сделать правильно. То есть, как правильно умножать матрицы, или какую либу для этого использовать.
Я про это и написал же
Зависит от задачи, никто не спорит. Речь шла про проект, где такие задачи возникают раз в месяц… а может вообще никогда. А вы приводите пример про обработку изображений. Понятно, что если ты каждый день работаешь с двумерными массивами, то подобные знания реально нужны.
И опять же, говоря про либы, я, конечно не говорил про OpenCV, драйверы и прочую "низкоуровщину". Умение сделать элегантный костыль или построить эффективный велосипед одинаково поощряется на низком уровне (абстракции) и порицается на высоком.
А либы, либы то на что?
Как по мне, так более важной проблемой является как раз незнание/непонимание более абстрактных сущностей (специфичных для программирования), как принципы и подходы (GRASP/SOLID/<подставьте нужное>), зачем нужен рефакторинг, зачем бить проект на модули и пр.
Потому как если нужно перемножить матрицы, человек может почитать вики и научиться этому за час (а лучше подключить либу). А если нужно понимание, зачем нужна высокая модульность и почему не нужно всю логику лепить в один объект, то на это может уйти год и более.
Для программиста на первом месте не знания, а умение эти знания получать.
никак, вестимо
Новый символ после прочтения статьи выглядит как отпечатки птиц на стекле
Эпично. Люди, как всегда, обвиняют инструмент в собственных пороках
Так он же без веревки лазает — вот уже и позабыл как веревкой пользоваться
закройте
чертову
скобку!
Наверно удобная тема чтобы, например, поговорить с ребенком удаленно, например, находясь на работе.
Но вот следить за ребенком, будь то браслет с трекером вроде https://vc.ru/p/wochi-geoplaner, либо скрытая камера — это стремно и стыдно. Нет, я понимаю, когда к грудному ребенку камеру приставляют. Но этот девайс на другой возрас рассчитан. А с детства приучать ребенка к тому, что ему настолько не доверяют, то цепляют датчики либо снимают камерой как пса в клетке, это, имхо, так себе.
К девайсу претензий нет, претензии к тем, кто использует подобное для слежки за своими же детьми.
Если бритва Оккама позволяет отсечь эту функцию, то вполне норм от нее избавиться, считаю.
Имеет смысл запаковывать логику в методы, когда это действительно имеет смысл (вот такая тавтология) — то есть, если там предполагаются изменения, либо она относится к какой-либо отличной зоне ответственности, нежели вызывающий метод, либо имеет место DRY, либо еще что.
Если там дествительно три строки, да и еще название не соответствует, возможно, там когда-то раньше было больше, а потом разработчик это убрал, да поленился остатки перенести назад или переименовать нормально. Избавление от старого хлама есть часть рефакторинга.
Ну а золотая середина (имхо) в том, чтобы придерживаться четких принципов и методологий ака SOLID, GRASP и прочих, которые как раз помогают четко детерминировать границы когда "так" делать, и когда "так" не делать.
да и на гироскутере везти неудобно
да вроде бы не… oh shi~
Нет, я не об этом. Просто скромно добавленное "И выполнять обратное преобразование для записи данных в мозг" сразу возникла такая картинка в воображении :)
Сразу представилось, как сидят заказчики над ТЗ, и обсуждают: "а давайте и обратное преобразование с записью добавим, просто ценник за преобразование и запись надвое умножим"
При взгляде на фото невольно напрашивается вопрос — а те конструкции, которые остаются в контакте с воздухом, так и остаются ржавыми, ничем не покрываются после сборки?