Ну не совсем правильная аналогия, но даже если ее придерживаться, то вот купить айфон, не вставая из-за компа, я вполне могу. Т.е. интернет-магазин проще, чем «отжать в подворотне».
Да не обязательно даже «гуру». Мы в Питере искали себе среднестатистического разработчика — уровнем чуть выше джуниора, просто с небольшим уровнем опыта и с адекватными запросами. В итоге нашли только в Ростове-на-Дону, который хотел переехать в Питер :)
Ну ок. Тогда это «доказательство Шредингера» (по аналогии с котом): пока кто-то не докажет или не опровергнет его, неизвестно, доказательство это или нет. При желании подобную ситуацию можно назвать «парадоксом».
Говорю за себя: попробовал лет в 18 несколько разных алкогольных напитков. На вкус не понравилось, платить столько денег за невкусную фигню не понравилось еще больше. Больше не пью.
За других не буду.
Как человек из мира ERP, имею сказать :)
У нас в компании аналитик обследует все бизнес процессы компании, после чего оптимизирует их и пишет ТЗ. Так вот, когда заказчик видит это ТЗ, он делает огромные глаза и говорит, что у них так не работают, а надо вот так. И после этих слов выдается поток бреда, который приходится записывать и реализовывать, иначе не подпишут ТЗ, а потом и акт.
На все объяснения, что подобный бред делать нельзя и не надо, заказчик плюет. А после опытной эксплуатации и полугодового использования, заказчик заказывает второй проект, в рамках которого система допиливается до первого предложенного аналитиком варианта.
Хочу прокомментировать пункт с тестовыми заданиями на дом.
Я участвовал в приеме на работу стажеров-разработчиков (это чуть ниже уровень, чем junior). Так вот проверяя задание, я обращаю внимание не на качество написания кода, а на «думалку» разработчика. Сколько банальных ошибок он мог предупредить, как хорошо умеет пользоваться гуглом. И очень многие кандидаты показывали умение пользоваться языком программирования, но полнейшее не умение пользоваться логикой.
А писать код красиво, хорошо и правильно должны уже мы его научить.
Добавлю к остальным комментаторам: заказчику всегда надо оставить % для торговли. Причем опытный продавец может определить по разговору, насколько надо завысить цену, чтобы после скидки она составляла требуемую сумму.
Для этого как раз и нужны архитекторы и менеджеры по развитию, которые определят, какая фича может потребоваться в будущем и станет конкурентным преимуществом, а какая сожрет кучу времени на разработке, но станет «приятным дополнением».
Если сходу, то можно придумать несколько версий:
1. Интересные технологии или проект. Допустим, когда появились IPad, то человек мог уйти в контору, пишущую для них софт на те же деньги, что у него есть сейчас просто потому, что интересно писать под IPad, а не Windows/Linux etc.
2. Работа ближе к дому. Как пример: болезненный ребенок и его надо по часам водить в больницу. С другого конца города не накатаешься. Ну или в принципе лень кататься.
3. Имя компании. Ну хочется кому-то в трудовой книжке иметь запись «Microsoft» или «DrWeb».
И эти причины вполне можно озвучить.
Спасибо за статью. Получилась: «Бэкапы для самых маленьких» :)
P. S. у нас используется, обычно, такая схема: бэкап лога раз в час, инкрементал раз в день (ночью, когда никто не работает), фулл — по выходным. Пока, вроде, никто не жаловался.
За других не буду.
У нас в компании аналитик обследует все бизнес процессы компании, после чего оптимизирует их и пишет ТЗ. Так вот, когда заказчик видит это ТЗ, он делает огромные глаза и говорит, что у них так не работают, а надо вот так. И после этих слов выдается поток бреда, который приходится записывать и реализовывать, иначе не подпишут ТЗ, а потом и акт.
На все объяснения, что подобный бред делать нельзя и не надо, заказчик плюет. А после опытной эксплуатации и полугодового использования, заказчик заказывает второй проект, в рамках которого система допиливается до первого предложенного аналитиком варианта.
Я участвовал в приеме на работу стажеров-разработчиков (это чуть ниже уровень, чем junior). Так вот проверяя задание, я обращаю внимание не на качество написания кода, а на «думалку» разработчика. Сколько банальных ошибок он мог предупредить, как хорошо умеет пользоваться гуглом. И очень многие кандидаты показывали умение пользоваться языком программирования, но полнейшее не умение пользоваться логикой.
А писать код красиво, хорошо и правильно должны уже мы его научить.
1. Интересные технологии или проект. Допустим, когда появились IPad, то человек мог уйти в контору, пишущую для них софт на те же деньги, что у него есть сейчас просто потому, что интересно писать под IPad, а не Windows/Linux etc.
2. Работа ближе к дому. Как пример: болезненный ребенок и его надо по часам водить в больницу. С другого конца города не накатаешься. Ну или в принципе лень кататься.
3. Имя компании. Ну хочется кому-то в трудовой книжке иметь запись «Microsoft» или «DrWeb».
И эти причины вполне можно озвучить.
P. S. у нас используется, обычно, такая схема: бэкап лога раз в час, инкрементал раз в день (ночью, когда никто не работает), фулл — по выходным. Пока, вроде, никто не жаловался.