я лишь сказал, что «не кодом единым»… а мне уже приписали бог знает что: растрату времени команды, сначала оратор, затем программист, опасность в плане конкуренции и прочая и прочая :)
гениальный код — не самоцель. он не должен обязательно быть гениальным, он должен быть «достаточно хорош»
Ну немного категоричности не помешает, для придания живости обсуждению (см. комментарий ниже ) :)
На собеседовании мы сидим в нашем опенспейсе, все сотрудники видят кандидата и могут составть о нем представление. Если с технической точки зрения он нам подходит — второй вопрос — он сможет стать частью команды?
На моей памяти никто не спрашивал «зачем нам это?», все как-то сами понимали. И чьи-то кандидатуры мы после коллективного обсуждения отклонили, что поделать. Ну не хотят люди работать с этим человеком, зачем их заставлять, будем искать дальше. Плюс не факт, что самим кандидатам было бы у нас комфортно, так что эта палка о двух концах.
Программисты не только пишут код. Они общаются с другими программистами. Они — часть команды. И если с человеком трудно общаться — то пусть его код будет трижды гениален — я этого никогда не узнаю, потому что не возьму его на работу.
ну это возможно, если цель прототипа — показать заказчику, как это будет выглядеть на экране. кнопочки, окошечки.
а в наше неспокойное время частенько компании хватаются за проекты, в которых требуется использовать неизвестные им технологии (но кто ж в этом признается, когда вот они, деньги!) и тут уже прототип больше нужен самим программистам, чтоб опробовать новый стек, слепить из 10 туториалов и заметок на стековерфлоу нечто, напоминающее систему.
Как тот самурай, который, просыпаясь каждое утро, должен быть готов к смерти, руководитель должен каждый день начинать с мысли — а что, если я приду в офис, а там никого нет?
Я сейчас не говорю о паранойе и навязчивой идее. Я говорю о риске. Одном из многих рисков, которыми руководитель должен уметь управлять.
Нужно защищать свои инвестиции: мониторить обстановку, следить за настроениями, снижать зависимость от конкретных персоналий, автоматизировать процессы, готовить резерв и т.д. и т.п.
вагоны соединены кольцом, в каждом вагоне лампочка, которую можно включить или выключить. по составу можно ходить в любую сторону. нужно определить кол-во вагонов.
… кто-то вспоминал о совершенно незаметной но категорически нужной фиче.
нередко сталкивался с такой ситуацией: код написан как попало, но что-то делает. Проблема, что никто точно не знает, что точно он делает, по какому алгоритму и на основании каких требований. Если иметь в комментариях или ТЗ это описание — можно просто выкинуть его и переписать заново, сохранив интерфейс и ключевое поведение. Но как правило комментариев нет, ТЗ устарело, а распутывать эту магию нет ни времени ни особого желания, все равно что-то да упустишь.
То есть весьма желательно иметь комментарий, что же именно хотел добиться разработчик.
habrahabr.ru/post/145158/
habrahabr.ru/post/171911
habrahabr.ru/post/171911
а вот например книжка есть «про Это»
гениальный код — не самоцель. он не должен обязательно быть гениальным, он должен быть «достаточно хорош»
и «умение играть в команде» не менее важно
вот и все, что я хотел сказать
На собеседовании мы сидим в нашем опенспейсе, все сотрудники видят кандидата и могут составть о нем представление. Если с технической точки зрения он нам подходит — второй вопрос — он сможет стать частью команды?
На моей памяти никто не спрашивал «зачем нам это?», все как-то сами понимали. И чьи-то кандидатуры мы после коллективного обсуждения отклонили, что поделать. Ну не хотят люди работать с этим человеком, зачем их заставлять, будем искать дальше. Плюс не факт, что самим кандидатам было бы у нас комфортно, так что эта палка о двух концах.
а в наше неспокойное время частенько компании хватаются за проекты, в которых требуется использовать неизвестные им технологии (но кто ж в этом признается, когда вот они, деньги!) и тут уже прототип больше нужен самим программистам, чтоб опробовать новый стек, слепить из 10 туториалов и заметок на стековерфлоу нечто, напоминающее систему.
Я сейчас не говорю о паранойе и навязчивой идее. Я говорю о риске. Одном из многих рисков, которыми руководитель должен уметь управлять.
Нужно защищать свои инвестиции: мониторить обстановку, следить за настроениями, снижать зависимость от конкретных персоналий, автоматизировать процессы, готовить резерв и т.д. и т.п.
Чтобы потом не было мучительно больно.
структура, которая требует каждодневного «ручного» управления со стороны менеджера, вряд ли имеет право называться «налаженной»
либо директор подпишется на заведомо нереальный срок выполнения проекта и тут уже не спасет никакое качество работы.
нередко сталкивался с такой ситуацией: код написан как попало, но что-то делает. Проблема, что никто точно не знает, что точно он делает, по какому алгоритму и на основании каких требований. Если иметь в комментариях или ТЗ это описание — можно просто выкинуть его и переписать заново, сохранив интерфейс и ключевое поведение. Но как правило комментариев нет, ТЗ устарело, а распутывать эту магию нет ни времени ни особого желания, все равно что-то да упустишь.
То есть весьма желательно иметь комментарий, что же именно хотел добиться разработчик.