Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 62
Есть «профессиональные олимпиадники», которые с лёгкостью проходят неадекватные собеседовательные задания, а потом говнокодят до тех пор, пока их не уволят или не повысят. А есть программисты, которые пишут рабочий не-всегда-говнокод, у которых могут быть проблемы с заданиями на собеседованиях, которые не имеют ничего общего с реальными программистскими задачами…
А вообще, я не сильно понял, о чём статья.
А вообще, я не сильно понял, о чём статья.
а так же существуют инженеры, знающие и умеющие программировать, с реальным опытом работы лет в десять, с знаниями хитрых алгоритмов, паттернов и всем прочим.
Но у них настолько тяжёлый характер или делают очевидные вещи настолько «не так», как все привыкли и ожидают. Что от них шарахаются вообще все. И в шоке от них не только коллеги, а даже пользователи их софта.
Но у них настолько тяжёлый характер или делают очевидные вещи настолько «не так», как все привыкли и ожидают. Что от них шарахаются вообще все. И в шоке от них не только коллеги, а даже пользователи их софта.
О том, что в современном программировании алгоритмы не самое важное и так сильно заострять внимание не имеет смысла.
С мнением автора в целом согласен. Зачастую участие «профессиональных олимпиадников» в проекте оборачивается горем команде. У нас используется понятие «одноразовый код» — это код, который сопровождать очень сложно, его проще переписать, чем чем потом сопровождать и отлаживать. С таким кодом я встречался в различных прикладных математических библиотеках. Целью авторов этих приложений было оптимизировать все возможное, хотя реальный эффект был пренебрежимо мал. Обычно такие разработчики не задумываются о том, что алгоритм, помимо быстроты, должен хорошо читаться и анализироваться.
Может быть тут недостаток в менеджменте и проектировании? Олимпиадники куда лучше обучаемы, и при правильном наставничестве не имеют потолка развития, в отличии от людей, говорящих себе — а зачем мне знать как это устроено, все ж уже реализовано. Не свидетельствует ли это об узком мировоззрении, неготовности к саморазвитию?
Может быть отставите в сторонку «Совершенный Код» и почитаете «Алгоритмы — Построение и Анализ» Кормана? Поверьте, научиться написать сопровождаемый код — это дело лишь опыта.
Люди, считающие, что алгоритмы неважны — как люди, севшие за руль, не зная устройства машины.
Да, у «олимпиадников» бывает излишняя самоуверенность, да, с ними бывает сложно, но хороший менеджер сможет спустить такого человека на землю, и получит ценного и надежного сотрудника.
Может быть отставите в сторонку «Совершенный Код» и почитаете «Алгоритмы — Построение и Анализ» Кормана? Поверьте, научиться написать сопровождаемый код — это дело лишь опыта.
Люди, считающие, что алгоритмы неважны — как люди, севшие за руль, не зная устройства машины.
Да, у «олимпиадников» бывает излишняя самоуверенность, да, с ними бывает сложно, но хороший менеджер сможет спустить такого человека на землю, и получит ценного и надежного сотрудника.
Конечно олимпиадник юниор это прекрасно. Я сам такой был в 16 лет… весь такой важный, я ведь уже 5 лет пишу на ассемблере…
Но вот олимпиадник-ПМ или просто мидл/сеньор, это катастрофа.
Пару месяцев назад видел одного мальчика, которого взяли в большую компанию студентом, потому что он прошел собеседование. Ему очень понравились задачки которые ему задавали. Он потом их всем задавал. И удивлялся почему из опытных программистов половина не может их решить лучше него.
Он так и не понял, что задачки где человек пытается подменить собою оптимизатор компилятора это зло. Особенно для юниора работающего в CRUD-проектах на фронтэнде. Не понял он и моего рассказа о том, как долго я заставлял себя прекратить оптимизировать код до тестов.
Мальчик не олимпиадник. И фирма вроде приличная. Надеюсь что эта ересь была только на собесах, а дальше из него таки сделают человека. Потому что посредственный олимпиадник воспитанный олимпиадниками будет потерян для программирования. А так, у него есть шанс дорости до твердого мидла, оставив узкие места профессионалам.
Но вот олимпиадник-ПМ или просто мидл/сеньор, это катастрофа.
Пару месяцев назад видел одного мальчика, которого взяли в большую компанию студентом, потому что он прошел собеседование. Ему очень понравились задачки которые ему задавали. Он потом их всем задавал. И удивлялся почему из опытных программистов половина не может их решить лучше него.
Он так и не понял, что задачки где человек пытается подменить собою оптимизатор компилятора это зло. Особенно для юниора работающего в CRUD-проектах на фронтэнде. Не понял он и моего рассказа о том, как долго я заставлял себя прекратить оптимизировать код до тестов.
Мальчик не олимпиадник. И фирма вроде приличная. Надеюсь что эта ересь была только на собесах, а дальше из него таки сделают человека. Потому что посредственный олимпиадник воспитанный олимпиадниками будет потерян для программирования. А так, у него есть шанс дорости до твердого мидла, оставив узкие места профессионалам.
То есть из первого абзаца можно сделать вывод, что Вы являетесь катастрофой для своей команды, так?
Был бы, если бы меня не макнули носом в то, что хаки на особенностях железа, и хитрые трюки по оптимизации это менее важно чем грамотная структура и чистый читаемый код.
Я против того, чтобы олимпиадники принимали людей на работу по умению решать олимпиадные задачки. Как вспомогательный инструмент это да, но лишь косвенный.
Я против того, чтобы олимпиадники принимали людей на работу по умению решать олимпиадные задачки. Как вспомогательный инструмент это да, но лишь косвенный.
Судя по описанию, вы слабо себе представляете, что такое олимпиадник.
Люди, считающие, что алгоритмы неважны — как люди, севшие за руль, не зная устройства машины.
Вам шашечки или ехать? Вся история технического прогресса — непрерывные попытки стрятать детали реализации под всё более высокоуровневым интерфейсом. Чтобы водить машину, не нужно знать её внутреннего устройства, нужно знать её поведение. Так же как программисту не нужно знать физическую конструкцию «вентелей» в процессоре, чтобы писать код на javascript'e, к примеру.
Или под «водить машину» вы подразумеваете умение разобрать её на составляющие и собрать обратно?
Конечно не нужно. Если надо проехать по прямой в идеальных условиях по идеальной дороге. А внезапное препятствие на дороге — теория по его объезду — и бац, уже надо понимать как устроено рулевое управление, система торможения, как ведет себя движущееся тело согласно законам физики. Т.е. в целом-то знание не нужно (если надо написать лабораторку в универ, где создать окно и две кнопочки), но как только возникает нетривиальная задача (разпознавание номеров в движущемся потоке машин), то сразу нужно понимать подкапотное устройство.
Я пытался донести немного другое. Воспользуюсь вашим же примером: чтобы объехать камень на дороге, нужно знать, как поворачивать, но не нужно знать схему соединения руля с колесами. С другой стороны, если ты уже знаешь внутреннее устройство машины, в которой едешь, это не сделает тебя более плохим водителем. С третьей стороны — если ты потратил полжизни на изучение внутренностей механизмов, но никогда не ремонтируешь самостоятельно и ездишь только до работы и обратно — может, стоило потратить время на изучение чего-то другого?
В точку. Я знаю огромное количество хороших специалистов, в прошлом олимпиадников, и это точно не следствие отбора на собеседованиях. А вот программистов 200k+, разрабатывающих сложные системы, и не знающих основ алгоритмов не знаю ни одного.
Ну строго говоря библиотекам можно.
Если ты не лезешь под капот, то даже 0.01% может вылиться в десятки серверов сэкономленных.
Собственно для этого даже инлайнят ассемблерные вставки в высокоуровневые языки (по крайней мере раньше инлайнили, сам давно до этого не доходил).
Если есть качественный внешний интерфейс, и поддержкой библиотеки занимается только ее разраб, то почему бы и нет?
Инкапусуляция наше всё)
Но да, это редкие частные случаи…
Если ты не лезешь под капот, то даже 0.01% может вылиться в десятки серверов сэкономленных.
Собственно для этого даже инлайнят ассемблерные вставки в высокоуровневые языки (по крайней мере раньше инлайнили, сам давно до этого не доходил).
Если есть качественный внешний интерфейс, и поддержкой библиотеки занимается только ее разраб, то почему бы и нет?
Инкапусуляция наше всё)
Но да, это редкие частные случаи…
А вообще, я не сильно понял, о чём статья.
Примерно об этом:
Controlling complexity is the essence of computer programming. — Brian Kernighan
Странное противопоставление и перевод названия заметки, если он подразумевает общий случай. На этапе проектирования приоритетны Organizational Skill, на этапе оптимизации потребления ресуров (память, время вычислений) приоритетно Algorithmic Wizardry.
Параллельные алгоритмы имеют математическую модель (вводится в нотацию переменная кол-ва процессоров), свои паттерны и рассматриваются вопросы влияния времени синхронизации нитей на время вычисления. Но фактически формальные алгоритмы к которым можно с уверенностью применить математическую модель актуальны для SIMD и GPU, где можно точно распределить на вычислительные единицы какие-то операции и учесть время трансфера данных из хоста в память GPU, на CPU все сложнее, время на нити (легковесные процессы) scheduler операционной системы раздает и решает.
А собеседования разные бывают, все это частные случаи, например на одном я общался в светском формате с человеком за чашечкой чая про ассемблер и теорию конечных автоматов, на другом мы только обсудили объем работ и цену за час работы.
А собеседования разные бывают, все это частные случаи, например на одном я общался в светском формате с человеком за чашечкой чая про ассемблер и теорию конечных автоматов, на другом мы только обсудили объем работ и цену за час работы.
Может и не нужно знать алгоритмы, однако, это серьезное подспорье в работе. И я не видел 200k+ программистов не знающих алгоритмов. Знающих видел.
Программа небольшая – около 1500 строк кода на Erlang и C. Упаковкой изображений в прямоугольник занимается совсем маленький фрагмент кода длиной около 20 строк
По моему все время так — примерно 10% кода — это реальный функционал, а остальные 90% — обертки для красивого вывода данных
Меня тут на хабре в свое время заминусовали страшно, за то, что я на собеседовании прошу нарисовать блок-схему решения квадратного уравнения, и даже разрешаю пользоваться интернетом… Никаких проблем с алгоритмом Никаких проблем со знанием языка. 90% разработчиков, даже самых крутых отсеивается на том, что не понимают, что 90% работы это обертка. Нештатные случаи, работа с ошибками, определение рамок применимости, уточнение ТЗ у заказчика и т.п…
Если задание на собеседовании звучит как
блок-схему решения квадратного уравнениято при чем здесь
Нештатные случаи, работа с ошибками, определение рамок применимости, уточнение ТЗ у заказчика и т.п…
Отрицательный дискриминант? :)
Квадратное уравнение может не иметь корней, может иметь два одинаковых корня (показывать один или оба?), множители при x^2 и свободном члене могут быть равными нулю (оптимизация нарисовалась). По-моему, очень красивый пример. С учетом, что можно юзать инет и если не помнить тот же дискриминант — можно посмотреть в вики, в том числе все частные случаи.
> По-моему, очень красивый пример.
По-моему это задача для совсем совсем джуниора. Неясно что тут проверяется, знает ли человек что такое условные переходы?
Этакая задача на уровне 7 класса средней школы.
По-моему это задача для совсем совсем джуниора. Неясно что тут проверяется, знает ли человек что такое условные переходы?
Этакая задача на уровне 7 класса средней школы.
Проверяется, может ли человек увидеть, разделить и обработать все шесть различных ситуаций. Понимает ли он разницу между x^2+1=0 и 1=0. Можно посмотреть, как «блок-схема» не справится с уравнением x^2-1e20*x+1=0, и сможет ли человек исправить её, чтобы меньший корень показывался с нормальной точностью, а не обращался в нуль. А потом — предложить x^2-1e200*x+1=0… А после того, как он справится и с таким уравнением, сказать «Вам у нас будет неинтересно» и не взять.
Однако это уже совсем другая задача. Все-таки оптимизация, большие числа и тд и тп должны быть обязательно указаны в условях задачи, т.к. требуют дополнительных усилий и времени. И если без их указания человек пытается это делать, для него это совсем не плюс.
Я и не говорю, что он сразу должен написать решение, которое будет работать во всех случаях. Это будет последовательное усложнение задачи для 7 класса.
Усложнением оно становится после вопросов с точностью, потому что это ограничение реализации, а не сферической блоксхемы. Даже комплексные корни это усложнение. Но вывести сообщение «действительных корней нет», равно как и отсутствие корней разработчик обязан. Сегодня он не может квадратное уравнение решить, потому что он «сильно умный для этого», а завтра у него приложение на платежном терминале в консоль вывалится потому что клиент введет неожиданные данные, и вызовет деление на ноль…
Да и потом. Если собеседующий тебя на мидла и уже проверивший твое знание технологий задает тебе задачку для седьмого класса, то ты ДОЛЖЕН предположить, что ты не самый умный на этой планете, и может быть он не идиот, и задача таки имеет смысл. А если ты это предположишь, то когда начнешь рисовать, то сразу поймешь, что некоторые вещи не стоит игнорировать.
И здесь возникнет классическая ситуация из сложных тестов на IQ — «угадай, что имел в виду автор». И непонятно, куда идти. Можно попытаться угадать одну ловушку. Можно предусмотреть штук пять вариантов ситуаций, в которых такая задача окажется не совсем тривиальной, Можно задавать уточняющие вопросы для определённости. А в конце вдруг окажется, что собеседующему было просто интересно, как на блок-схеме будет отображаться Exception :)
а язык человеку на что? Нет, я понимаю что там куча вкусовых окончаний, но всё-же)
Я ничуть не страшнее чем среднестатистический директор, говорящий «сделайте мне сайт, и так чтобы клёво».
Красные линии я не прошу)
Если человек просит нарисовать блок-схему, то ты ее просто рисуешь. Если у тебя возникает в голове вопрос, нужно ли предусмотреть все исключительные случаи, то это естественно должно наложиться на вопрос о том «а нафига собственно он мне сказал рисовать?». Вариант о том, чтобы проверить сможешь ли ты нарисовать логику уже описанного алгоритма из двух действий — сомнителен. Так что остается или спросить у собеседующего, мол вы хотите писать всё? Это будет немного долго, или и так сойдет?
Либо просто тупо рисовать всё… Вариант — не нарисовать и не спросить это большой минус. Меньше чем «даже не подумать об исключительных случаях», но всё равно большой.
Черт, да первые три картинки в гугле даже на «а=0» не проверяют. Тупо делят… Ну как так можно?)
Я ничуть не страшнее чем среднестатистический директор, говорящий «сделайте мне сайт, и так чтобы клёво».
Красные линии я не прошу)
Если человек просит нарисовать блок-схему, то ты ее просто рисуешь. Если у тебя возникает в голове вопрос, нужно ли предусмотреть все исключительные случаи, то это естественно должно наложиться на вопрос о том «а нафига собственно он мне сказал рисовать?». Вариант о том, чтобы проверить сможешь ли ты нарисовать логику уже описанного алгоритма из двух действий — сомнителен. Так что остается или спросить у собеседующего, мол вы хотите писать всё? Это будет немного долго, или и так сойдет?
Либо просто тупо рисовать всё… Вариант — не нарисовать и не спросить это большой минус. Меньше чем «даже не подумать об исключительных случаях», но всё равно большой.
Черт, да первые три картинки в гугле даже на «а=0» не проверяют. Тупо делят… Ну как так можно?)
> Черт, да первые три картинки в гугле даже на «а=0» не проверяют. Тупо делят… Ну как так можно?)
Мне кажется это и есть классическое «угадай, что имел в виду автор».
Если а==0, то уравнение перестает быть квадратным по формальному определению (см. en.wikipedia.org/wiki/Quadratic_equation), а следовательно либо Вы до конца не понимаете того, что спрашиваете, либо Вам на самом деле нужно, чтобы блок-схема решала уравнения первой и второй степеней и именно этот факт требуется угадать человеку, а не нарисовать блок-схему решения квадратного уравнения.
Либо, Вам дополнительно нужно, чтобы соискатель догадался и уточнил реально ли заданное Вами формальное ограничение на входные данные будет выполняться в тестовом наборе или нужно дополнительно проверять его выполнение, а это уже очень плохо говорит о процессе разработки в компании, так как появляются основания предполагать, что ТЗ там никогда не было или, что они никогда не исполнялись…
Мне кажется это и есть классическое «угадай, что имел в виду автор».
Если а==0, то уравнение перестает быть квадратным по формальному определению (см. en.wikipedia.org/wiki/Quadratic_equation), а следовательно либо Вы до конца не понимаете того, что спрашиваете, либо Вам на самом деле нужно, чтобы блок-схема решала уравнения первой и второй степеней и именно этот факт требуется угадать человеку, а не нарисовать блок-схему решения квадратного уравнения.
Либо, Вам дополнительно нужно, чтобы соискатель догадался и уточнил реально ли заданное Вами формальное ограничение на входные данные будет выполняться в тестовом наборе или нужно дополнительно проверять его выполнение, а это уже очень плохо говорит о процессе разработки в компании, так как появляются основания предполагать, что ТЗ там никогда не было или, что они никогда не исполнялись…
Ваш комментарий напомнил мне статью Что бы сделал мистер Фейнман?
Квадратное уравнение — это не абстрактное понятие допускающее многозначность толкования, а вполне определенный вид уравнений, так что необходимость уточнять факты, в данном случае противоречащие постановке задачи — это скорее к позиции господина Mendel.
Моя позиция в том, что программа написанная программистом не должна падать от неожиданного ввода пользователя. И моя позиция в том, что в мире всегда есть умолчания, и если у тебя есть сомнения в уместности умолчаний, то ты должен об этом сказать вслух.
А еще моя позиция заключается в том, что если я должен говорить разработчику о том, что «мне бы хотелось, чтобы твоя программа работала без ошибок, и не содержала глюков», а иначе он посчитает, что это не особо то и важно, то мне такой разработчик не нужен. Ну вот такой вот я закомплексованный и ограниченный тип. Пусть идет в более продвинутые и гибкие команды :)
А еще моя позиция заключается в том, что если я должен говорить разработчику о том, что «мне бы хотелось, чтобы твоя программа работала без ошибок, и не содержала глюков», а иначе он посчитает, что это не особо то и важно, то мне такой разработчик не нужен. Ну вот такой вот я закомплексованный и ограниченный тип. Пусть идет в более продвинутые и гибкие команды :)
Я бы не взял такого человека программистом. Аналитиком да, но не программистом.
Человек который не проверяет входные данные, не узнает о том, являются ли данные отфильтрованными и т.п., и при этом на самом видном месте его решения находится деление на ноль, это не очень полноценный программист. Мягко так скажем.
Когда ты пишешь код, ты всегда его проверяешь. Если не вживую, то хоть немного тестов гоняешь виртуально в голове. Это не копипаст, это программирование. Я не требую комплексные корни. Написал «действительных нет» — отлично. Написал «корней нет» — тоже прекрасно, я не буду придираться что упустил слово «действительных». Нет, я это скажу вслух, но скорее чтобы посмотреть на его реакцию. Чисто в рамках блока психологии, не профессионализма.
Я даже спокойно отношусь к ситуации когда человек изначально нарисовал что-то, из того что предлагает гугл, но после уточняющего вопроса «вы уверенны что это всё?» исправился. Однако падение от того, что кто-то понадеялся на «правильность» пользователя — говнокод.
ПС: Мне это напомнило как один интернет-провайдер на своем сайте ограничивал регистрацию некоторых тарифов по регионам — условие стояло в жаваскрипте. Три минуты манипуляции с браузером, и у тебя уже акционный тариф… Они еще похожие ляпы делали с пополнениями. Без проверок подписей и т.п…
Когда ты пишешь код, ты всегда его проверяешь. Если не вживую, то хоть немного тестов гоняешь виртуально в голове. Это не копипаст, это программирование. Я не требую комплексные корни. Написал «действительных нет» — отлично. Написал «корней нет» — тоже прекрасно, я не буду придираться что упустил слово «действительных». Нет, я это скажу вслух, но скорее чтобы посмотреть на его реакцию. Чисто в рамках блока психологии, не профессионализма.
Я даже спокойно отношусь к ситуации когда человек изначально нарисовал что-то, из того что предлагает гугл, но после уточняющего вопроса «вы уверенны что это всё?» исправился. Однако падение от того, что кто-то понадеялся на «правильность» пользователя — говнокод.
ПС: Мне это напомнило как один интернет-провайдер на своем сайте ограничивал регистрацию некоторых тарифов по регионам — условие стояло в жаваскрипте. Три минуты манипуляции с браузером, и у тебя уже акционный тариф… Они еще похожие ляпы делали с пополнениями. Без проверок подписей и т.п…
Хорошо. Напишите, пожалуйста, корректную и работающую проверку на равенство действительного числа нулю.
А после того, как у Вас не получится этого сделать, подумайте, где должна проходить проверка входных данных, там, где нет явного контракта на входные данные или там, где область допустимых входных данных однозначна определена в ТЗ — постановке задачи.
Формулировкой про квадратное уравнение Вы задали ограничение на множество значений входных данных и если в решении Вы хотите проверки этого контракта, то надо явно говорить о ненадежности источника входных данных иначе мы приходим к проблеме угадывания истинных намерений.
P.S. Кстати, многие математические библиотеки не проверяют корректность входных данных в каждом методе, так как такие проверки серьезно замедлят их работу.
А после того, как у Вас не получится этого сделать, подумайте, где должна проходить проверка входных данных, там, где нет явного контракта на входные данные или там, где область допустимых входных данных однозначна определена в ТЗ — постановке задачи.
Формулировкой про квадратное уравнение Вы задали ограничение на множество значений входных данных и если в решении Вы хотите проверки этого контракта, то надо явно говорить о ненадежности источника входных данных иначе мы приходим к проблеме угадывания истинных намерений.
P.S. Кстати, многие математические библиотеки не проверяют корректность входных данных в каждом методе, так как такие проверки серьезно замедлят их работу.
Хорошо. Напишите, пожалуйста, корректную и работающую проверку на равенство действительного числа нулю.
Корректная и работающая проверка будет выглядеть как простое сравнение с нулем.
Всё остальное домыслы, поскольку мы говорим именно о блок-схеме.
И да, именно проблемы с точностями и прочие тонкости реализации являются причиной использования именно блок-схем. Это упрощение.
Это уже на этапе конкретной реализации появляются +0, -0, и куча других особенностей.
Большинство проваливших этот тест таки не способны вот так вот отмазываться как вы.
Но специально для вас, я введу на будущее в условие задачи подсказку, о том, что программа написанная по искомой блок-схеме должна работать без ошибок.
> Большинство проваливших этот тест таки не способны вот так вот отмазываться как вы.
А я не отмазываюсь. Я сталкивался с тем, какой уровень проверки данных бывает во внутреннем коде, который непосредственно считает математику в различных приложениях и библиотеках. Обычно, предполагается, что в этот код передаются корректные данные, чтобы на выходе получился корректный результат, или, если программист передал фигню, то код имеет право выдать аналогичный результат. А проверки должны быть снаружи, чтобы не вносить лишние тормоза в итак ресурсоемкие операции.
> Но специально для вас, я введу на будущее в условие задачи подсказку, о том, что программа написанная по искомой блок-схеме должна работать без ошибок.
Кажется, Вы так и не поняли, почему Ваше дополнение ничего не поменяет. Вы все так же задаете задачу с формальным ограничением на входные параметры и ожидаете, что ему будут не доверять.
А вот подсказка о том, что входные данные могут быть получены из ненадежного источника была бы вполне соответствующей Вашему истинному желанию.
А я не отмазываюсь. Я сталкивался с тем, какой уровень проверки данных бывает во внутреннем коде, который непосредственно считает математику в различных приложениях и библиотеках. Обычно, предполагается, что в этот код передаются корректные данные, чтобы на выходе получился корректный результат, или, если программист передал фигню, то код имеет право выдать аналогичный результат. А проверки должны быть снаружи, чтобы не вносить лишние тормоза в итак ресурсоемкие операции.
> Но специально для вас, я введу на будущее в условие задачи подсказку, о том, что программа написанная по искомой блок-схеме должна работать без ошибок.
Кажется, Вы так и не поняли, почему Ваше дополнение ничего не поменяет. Вы все так же задаете задачу с формальным ограничением на входные параметры и ожидаете, что ему будут не доверять.
А вот подсказка о том, что входные данные могут быть получены из ненадежного источника была бы вполне соответствующей Вашему истинному желанию.
В начале блок-схемы идет блок ввода данных. В подсказке речь идет о «программе» а не «вспомогательной библиотеке». Если человек подумал о небезопасных данных, но решил что фильтрацию за него сделает кто-то другой, то он это скажет вслух. Если он на нервах забыл, то он поймет ошибку после вопроса. Если человек не спросил и не сделал проверку, то ему нужно разжевывать каждый чих. Сферические разрабы мне не нужны.
Понимает ли он разницу между x^2+1=0 и 1=0
Вы про обработку старшего коэффициента или про решение над комплексным полем?
«блок-схема» не справится с уравнением x^2-1e20*x+1=0
А как его решать? Интервальной арифметикой? Вообще, казалось бы, достаточно только считать в числах удвоенной точности, если бы не последний коэффициент.
Квадратное уравнение всегда имеет корни, просто при D < 0 они находятся в плоскости комплексных чисел.
В вашей фирме решение квадратного уравнения это выдуманная задача или реальная?
Это «дополнительный вопрос», когда собеседование не позволило однозначно понять «здравый смысл» соискателя.
Посмотрите что вам выдаст поиск по картинкам на запрос «блок-схема решения квадратного уравнения». Первые пять вариантов это работа кодера а не программиста. Если человек нарисует вот такое вот, и после наводящих вопросов типа «Вы уверенны? Хорошо подумайте...» не изменит своего решения, то у меня он получит максимум функции верстальщика.
Посмотрите что вам выдаст поиск по картинкам на запрос «блок-схема решения квадратного уравнения». Первые пять вариантов это работа кодера а не программиста. Если человек нарисует вот такое вот, и после наводящих вопросов типа «Вы уверенны? Хорошо подумайте...» не изменит своего решения, то у меня он получит максимум функции верстальщика.
На нормальных собеседованиях обычно не заставляют за минуту придумать сложный алгоритм и написать правильно работающую реализацию.
Обычно смотрят на ход мыслей, на то что человек вообще способен думать.
Т.е. в большинстве случаев обычно достаточно «ну наверное я бы начал думать вон в ту сторону и попробовал бы вот так»
А вот люди которые не знают даже примерно, как работают базовые вещи, ну например, сортировка — это как бы не программисты.
Обычно смотрят на ход мыслей, на то что человек вообще способен думать.
Т.е. в большинстве случаев обычно достаточно «ну наверное я бы начал думать вон в ту сторону и попробовал бы вот так»
А вот люди которые не знают даже примерно, как работают базовые вещи, ну например, сортировка — это как бы не программисты.
Вы не правы. Эти люди, именно, что «как бы» программисты.
Вообщем изза всяких таких как бы людей я решил называться инженером :)
:-) Знаете, называться инженером — значит взять на себя ответственность за работу системы.
В этом случае любая ошибка в ее работе указывает на некомпетентность. И никакие сроки в данном случае не могут являться оправданием. Инженер обеспечивает полноту анализа и учет всех возможных вариантов, без исключений. IMHO, реальных инженеров в IT очень мало.
В этом случае любая ошибка в ее работе указывает на некомпетентность. И никакие сроки в данном случае не могут являться оправданием. Инженер обеспечивает полноту анализа и учет всех возможных вариантов, без исключений. IMHO, реальных инженеров в IT очень мало.
>Знаете, называться инженером — значит взять на себя ответственность за работу системы.
Вообще брать ответственность это отличительная особенность взрослых людей, а не только инженеров.
Не все работают над такими простыми системами, где один челоек может взять полною отвественность над всей работой.
>В этом случае любая ошибка в ее работе указывает на некомпетентность.
Есть ошибки критичные, а есть не очень.
>И никакие сроки в данном случае не могут являться оправданием.
Как раз опыт и профессионализм позволяет объяснить руководителям какая будет вероятность проблем при каких сроках.
>Инженер обеспечивает полноту анализа и учет всех возможных вариантов, без исключений.
В своей зоне ответственности.
>IMHO, реальных инженеров в IT очень мало.
Мало, много — инженеры так не говорят :D
Вообще брать ответственность это отличительная особенность взрослых людей, а не только инженеров.
Не все работают над такими простыми системами, где один челоек может взять полною отвественность над всей работой.
>В этом случае любая ошибка в ее работе указывает на некомпетентность.
Есть ошибки критичные, а есть не очень.
>И никакие сроки в данном случае не могут являться оправданием.
Как раз опыт и профессионализм позволяет объяснить руководителям какая будет вероятность проблем при каких сроках.
>Инженер обеспечивает полноту анализа и учет всех возможных вариантов, без исключений.
В своей зоне ответственности.
>IMHO, реальных инженеров в IT очень мало.
Мало, много — инженеры так не говорят :D
Я решил для себя проблему целостности и читабельности кода более 3х лет назад тем, что начал разработку собственного проекта на основе подпроекта из Chromium'а с более чем 2500 .cc компилируемых файлов. Когда за несколько лет разобрался, как оно работает, и оптимизировал все это дело до конкурентных показателей, вопрос поддержания 'больших' проектов отпал.
Топик интересный, есть разумное зерно.
И почитать холивар на тему — белое лучше черного или мягче чем синее.
И почитать холивар на тему — белое лучше черного или мягче чем синее.
осмелюсь перефразировать статью и от себя добавить немного:
чтоб программист был хорошим достаточно чтобы он был немножко:
— алгоритмистом: достаточно знать самую базу, и знать что существует более лучше алгоритмы и уметь их искать.
— лингвистом: не всё и не всегда написано на «родном» языке и его диалекте, и часто что написано на чужом нужно чуток подправить.
— счетоводом: чтоб умел считать сложность хотя-бы на пальцах, вёл учёт ресурсов, не забывал про сроки
— политиком-переговорщиком: мы работаем для людей, в людском коллективе, инструментами и с кодом созданными другими людьми.
— инженером: имел понятие о запасе прочности, знал что не всё в мире совершенно, даже среда и компилятор, устранял причину, а не следствие
— технологом: чтобы наработки можно было хотя-бы поправить а лучше оформить потом в библиотеку и больше это никогда не писать.
— строителем: порой нужно просто класть, просто керпичи, просто в стену. долго, упорно, старательно.
— стратегом: редко когда код пишется одноразовым, обычно надо сопровождать годами или даже десятилетиями — надо учитывать будущее.
— И… просто в меру активным и в меру ленивым человеком с хорошим чувством баланса всех пунктов что я выше описал
чтоб программист был хорошим достаточно чтобы он был немножко:
— алгоритмистом: достаточно знать самую базу, и знать что существует более лучше алгоритмы и уметь их искать.
— лингвистом: не всё и не всегда написано на «родном» языке и его диалекте, и часто что написано на чужом нужно чуток подправить.
— счетоводом: чтоб умел считать сложность хотя-бы на пальцах, вёл учёт ресурсов, не забывал про сроки
— политиком-переговорщиком: мы работаем для людей, в людском коллективе, инструментами и с кодом созданными другими людьми.
— инженером: имел понятие о запасе прочности, знал что не всё в мире совершенно, даже среда и компилятор, устранял причину, а не следствие
— технологом: чтобы наработки можно было хотя-бы поправить а лучше оформить потом в библиотеку и больше это никогда не писать.
— строителем: порой нужно просто класть, просто керпичи, просто в стену. долго, упорно, старательно.
— стратегом: редко когда код пишется одноразовым, обычно надо сопровождать годами или даже десятилетиями — надо учитывать будущее.
— И… просто в меру активным и в меру ленивым человеком с хорошим чувством баланса всех пунктов что я выше описал
Я бы выразился проще — разработчик должен уметь мыслить системно и быть гибким. :-)
Умение адаптироваться под изменяющиеся условия — одно из главных умений.
Нужно придумать алгоритм — раскопал аналоги, скрутил решение, проверил на примерах и на краевых условиях.
Нужно настроить сервер — полез в доки, мануалы, нашел примеры, подкрутил под свой случай.
Нужно довести «хотелку» до тех. задания — договорился с заказчиком, детализировал сценарии, согласовал дизайн.
Но!
Все компании работают по-разному, и в обязанности разработчика вменяют самые разные вещи. Где-то специализация более узкая, где-то менее. Иметь широту обзора и умений полезно, но не всегда необходимо.
А вот умение обнаружить причину какого-либо поведения системы, имея на руках только частичные данные, и восстановить все возможные варианты развития событий, не пропустив ни одного — без этого просто нельзя. Если разработчик не способен обеспечить полноту анализа, или хотя бы обозначить границы этой полноты — это серьезный минус. Для нашего брата «не могу», «не хочу», «не умею» — не позволительная роскошь. Да, бывают ошибки, куда без них. Но бросить систему на произвол судьбы — это непрофессионализм.
Как-то так.
Умение адаптироваться под изменяющиеся условия — одно из главных умений.
Нужно придумать алгоритм — раскопал аналоги, скрутил решение, проверил на примерах и на краевых условиях.
Нужно настроить сервер — полез в доки, мануалы, нашел примеры, подкрутил под свой случай.
Нужно довести «хотелку» до тех. задания — договорился с заказчиком, детализировал сценарии, согласовал дизайн.
Но!
Все компании работают по-разному, и в обязанности разработчика вменяют самые разные вещи. Где-то специализация более узкая, где-то менее. Иметь широту обзора и умений полезно, но не всегда необходимо.
А вот умение обнаружить причину какого-либо поведения системы, имея на руках только частичные данные, и восстановить все возможные варианты развития событий, не пропустив ни одного — без этого просто нельзя. Если разработчик не способен обеспечить полноту анализа, или хотя бы обозначить границы этой полноты — это серьезный минус. Для нашего брата «не могу», «не хочу», «не умею» — не позволительная роскошь. Да, бывают ошибки, куда без них. Но бросить систему на произвол судьбы — это непрофессионализм.
Как-то так.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Здравый смысл важнее алгоритмического мастерства