Посоветуйте книжку
чем отличаются хорошие разработчики от обычных
У хороших разработчиков код пизже
рекомендую поручить селекцию разработчиков уже известным хорошим разработчикам. А книжка тебе едва ли поможет
я не собираюсь прочитав книжку тут же заниматься селекцией разработчиков;)
мне не хватает аргументаций в затянувшемся уже на 2 недели споре с одним чуваком, который сейчас набирает разработчиков.
он мне рассказывает, что я книжек не читала - но ни одной назвать сам не может.
мне не хватает аргументаций в затянувшемся уже на 2 недели споре с одним чуваком, который сейчас набирает разработчиков.
он мне рассказывает, что я книжек не читала - но ни одной назвать сам не может.
мне не хватает аргументаций в затянувшемся уже на 2 недели споре с одним чуваком, который сейчас набирает разработчиков.декольте побольше - и аргументов будет предостаточно
За такими советами я бы в ЛиС писала;-)
а тут я про другое спрашиваю:)
а тут я про другое спрашиваю:)
А чувак есть на форуме? Приводи его сюда, мы вас рассудим.
Если чувака нет - примеры кода в студию. Ну или какие там вы им задачки даете.
Если чувака нет - примеры кода в студию. Ну или какие там вы им задачки даете.
не, нету.
Он пытается взять одного хорошо разработчика, который круто мыслит логически.
одного - который будет работать на пару с этим крутым.
и нескольких (трех-четырех) - которые будут тупо задешево писать код.
ну и собсно мне кажется, что это будет ни разу неэффективно.
а споры наши зашли уже просто про работу команды.
Он пытается взять одного хорошо разработчика, который круто мыслит логически.
одного - который будет работать на пару с этим крутым.
и нескольких (трех-четырех) - которые будут тупо задешево писать код.
ну и собсно мне кажется, что это будет ни разу неэффективно.
а споры наши зашли уже просто про работу команды.
но уоговорки по фрейду?
Подбирать разработчиков надо целесообразно задачам.
Набирать народ, как ты описала, можно, если есть задачи посложнее (там навороченный бекенд) и есть попроще (много однообразного фронтенда).
Если же вся система сложная, и расчет на то, что два крутых чувака будут разжевывать задания тупым, а те будут фигачить - то это будет фейл.
Крутые не будут активно передавать знания / разжевывать тупым, в итоге тупые будут фигачить достаточно важный код, крутые будут офигевать от говнокода, тупые будут офигевать от прессинга со стороны крутых, напряженная обстановка, срачи, холивары...
Набирать народ, как ты описала, можно, если есть задачи посложнее (там навороченный бекенд) и есть попроще (много однообразного фронтенда).
Если же вся система сложная, и расчет на то, что два крутых чувака будут разжевывать задания тупым, а те будут фигачить - то это будет фейл.
Крутые не будут активно передавать знания / разжевывать тупым, в итоге тупые будут фигачить достаточно важный код, крутые будут офигевать от говнокода, тупые будут офигевать от прессинга со стороны крутых, напряженная обстановка, срачи, холивары...
Он пытается взять одного хорошо разработчика, который круто мыслит логически.Ну хоть матюгов много новых хороших узнаете.
одного - который будет работать на пару с этим крутым.
и нескольких (трех-четырех) - которые будут тупо задешево писать код.
споре с одним чуваком, который сейчас набирает разработчиков._No_?
он мне рассказывает, что я книжек не читала - но ни одной назвать сам не может.
Passionate programmer — про то, какой должен быть разработчик
Про психологию разработчиков еще Вайнберг много писал
Про психологию разработчиков еще Вайнберг много писал
Задачи-то какие?
ИМХО, если есть много простых скучных растянутых по времени задач - то все правильно. Хорошим разработчикам может быть неинтересно. Придумал клевую архитектуру, написал самые проблемные места,- следующий!
Другое дело, что "исполнители" должны быть, по крайней мере, аккуратными. Пусть неспособными написать разные клевые штуки, но чтобы понимали инструменты, которыми пользуются. Т.е. человек должен четко знать, что он понимает, а что нет, писать так, чтобы уметь самостоятельно исправлять свои ошибки. Не на авось, сработало - и ладно, а если нет, то старший поможет найти баг.
ИМХО, если есть много простых скучных растянутых по времени задач - то все правильно. Хорошим разработчикам может быть неинтересно. Придумал клевую архитектуру, написал самые проблемные места,- следующий!
Другое дело, что "исполнители" должны быть, по крайней мере, аккуратными. Пусть неспособными написать разные клевые штуки, но чтобы понимали инструменты, которыми пользуются. Т.е. человек должен четко знать, что он понимает, а что нет, писать так, чтобы уметь самостоятельно исправлять свои ошибки. Не на авось, сработало - и ладно, а если нет, то старший поможет найти баг.
Рэндел Манро всё правильно написал: http://xkcd.com/844/
Он пытается взять одного хорошо разработчика, который круто мыслит логически.Если чувак круто мыслит логически (и у него есть опыт то он знает, как сделать работу команды эффективной. Вот и пусть первый разработчик и определяет, кого набирать, если хотите эффективную команду.
одного - который будет работать на пару с этим крутым.
и нескольких (трех-четырех) - которые будут тупо задешево писать код.
ну и собсно мне кажется, что это будет ни разу неэффективно.
Своих притащит.
ты не путаешь эффективных программистов с эффективными менеджерами?
Спасибо!
задача вообще - переделать-доделать существующую ERPшку, которая написана весьма замороченно-хитро и на костылях.
А прошлый штат растворился.
Его решение логично - один придумывает что и как менять, другой координирует-соединяет работу говнокодеров, пишущих грубо говоря каждый свой модуль.
Выглядит красиво - но в итоге, как мне кажется, у него получатся не 5-6 разработчиков с разными задачами - а умный тех. дир, умный менеджер проектор и несколько говнокодеров.
и команда будет плохо работать.
А прошлый штат растворился.
Его решение логично - один придумывает что и как менять, другой координирует-соединяет работу говнокодеров, пишущих грубо говоря каждый свой модуль.
Выглядит красиво - но в итоге, как мне кажется, у него получатся не 5-6 разработчиков с разными задачами - а умный тех. дир, умный менеджер проектор и несколько говнокодеров.
и команда будет плохо работать.
Он пытается взять одного хорошо разработчика, который круто мыслит логически.
одного - который будет работать на пару с этим крутым.
и нескольких (трех-четырех) - которые будут тупо задешево писать код.
В программировании работа не делится на возвышенное мышление и низкое кодирование.
> В программировании работа не делится на возвышенное мышление
> и низкое кодирование.
Правильно говорить: русские программисты так считают.
А на самом деле всё, разумеется, иначе.
---
"Прогресс науки обратно пропорционален числу выходящих журналов."
> и низкое кодирование.
Правильно говорить: русские программисты так считают.
А на самом деле всё, разумеется, иначе.
---
"Прогресс науки обратно пропорционален числу выходящих журналов."
Правильно говорить: русские программисты так считают.Можешь привести пару примеров?
А на самом деле всё, разумеется, иначе.
Вот когда тебе спустят неформализованные пожелания заказчика,
которые надо превратить в продукт, тогда ты поймёшь, что нельзя
доверить проработку ТЗ кому попало, даже если он умеет кодить.
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
которые надо превратить в продукт, тогда ты поймёшь, что нельзя
доверить проработку ТЗ кому попало, даже если он умеет кодить.
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
Вот когда тебе спустят неформализованные пожелания заказчика,Это про какие программы речь идет, какая-нибудь автоматизация бизнеса?
которые надо превратить в продукт
Это применимо к любым программам, я такое встречал везде: и в радиосвязи,
и в сетевых коммутаторах, и в массовом обслуживании, и в базах данных,---
везде на каком-то этапе программистам спускают требования в виде каких-то
условий или пожеланий, и кто-то должен из них сформулировать ТЗ в виде,
понятном "кодерам," что именно, какие и как взаимодействующие модули те
должны написать, отладить и испытать. И я несколько раз сталкивался с тем,
что кто-то что-то "написал", а за ним приходилось переделывать.
Хорошо ещё, если неправильные архитектурные решения отлавливаются
на этапе проектирования, а не когда приёмочные испытания через месяц,
и внезапно выясняется, что система ложится через три часа после запуска,
не выходя даже на какую-то малую долю от расчётной нагрузки
(меньше одной двадцатой).
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
и в сетевых коммутаторах, и в массовом обслуживании, и в базах данных,---
везде на каком-то этапе программистам спускают требования в виде каких-то
условий или пожеланий, и кто-то должен из них сформулировать ТЗ в виде,
понятном "кодерам," что именно, какие и как взаимодействующие модули те
должны написать, отладить и испытать. И я несколько раз сталкивался с тем,
что кто-то что-то "написал", а за ним приходилось переделывать.
Хорошо ещё, если неправильные архитектурные решения отлавливаются
на этапе проектирования, а не когда приёмочные испытания через месяц,
и внезапно выясняется, что система ложится через три часа после запуска,
не выходя даже на какую-то малую долю от расчётной нагрузки
(меньше одной двадцатой).
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
В программировании работа не делится на возвышенное мышление и низкое кодирование.Замечательно делится. Просто это разделение проходит не по уровню квалификации.
Вот с этим я совсем не согласна. Или я что-то не поняла.
Речь не о возвышенном мышлении - а о способности придумать крутую штуку, оптимизирующую скорость/трудозатраты/легкость кода/etc
на рынке полно программистов тупо строгающих код - но не способных придумывать хорошие решения.
Речь не о возвышенном мышлении - а о способности придумать крутую штуку, оптимизирующую скорость/трудозатраты/легкость кода/etc
на рынке полно программистов тупо строгающих код - но не способных придумывать хорошие решения.
на рынке полно программистов тупо строгающих код - но не способных придумывать хорошие решенияотрасль взрослеет, и уже обычно заранее понятно, что такое программа и как она устроена
таджики, которые делают ремонт в новой квартире, тоже не придумывают решений - они делают, как в других домах
О_о
Компании, у которых есть сложившийся определенный круг заказчиков нанимают индусов.
Им всё равно, как будет работать их программа - ее все равно купят.
Когда программа ориентирована на то, чтобы заинтересовать клиента своей хорошестью - она должна писаться не индусами. Иногда 100000 строчек кода можно заменить 100ми - и программа только выиграет.
Кроме того, далеко не все делается по шаблону.
Ремонт можно сравнивать с написанием кода, а не с созданием программы. а это не одно и тоже.
Грубо говоря, надо еще проанализировать и решить, в какой комнате делать детскую, как и куда можно переносить стены, и в какую комнату вкладывать больше сил и средств. Таджикам такое не доверишь.
Компании, у которых есть сложившийся определенный круг заказчиков нанимают индусов.
Им всё равно, как будет работать их программа - ее все равно купят.
Когда программа ориентирована на то, чтобы заинтересовать клиента своей хорошестью - она должна писаться не индусами. Иногда 100000 строчек кода можно заменить 100ми - и программа только выиграет.
Кроме того, далеко не все делается по шаблону.
Ремонт можно сравнивать с написанием кода, а не с созданием программы. а это не одно и тоже.
Грубо говоря, надо еще проанализировать и решить, в какой комнате делать детскую, как и куда можно переносить стены, и в какую комнату вкладывать больше сил и средств. Таджикам такое не доверишь.
таджики, которые делают ремонт в новой квартире, тоже не придумывают решений - они делают, как в других домахкак в "других домах" делается простым копированием файлов
как в "других домах" делается простым копированием файловнабором с распечатки.
Когда программа ориентирована на то, чтобы заинтересовать клиента своей хорошестьюто копируют интерфейс с последнего продукта эппл
а дальше интерфейса клиент не успеет разобраться до принятия решения о покупке
то копируют интерфейс с последнего продукта эпплО_о Мне кажется, я вкладываю гораздо более широкое значение в понятие "Разработка ПО".
гораздо более широкое значениевполне может оказаться, что это всё ненужный пользователю ментальный онанизм
вполне может оказаться, что это всё ненужный пользователю ментальный онанизмВот и надо идти от пожеланий пользователя. Вполне нормально, когда формализация требований заказчика идет на этапе написания кода. Для выполнения формализации код лучше подходит, чем естественные (английский, русский) языки.
> Вполне нормально, когда формализация требований заказчика идет на этапе написания кода.
> Для выполнения формализации код лучше подходит, чем естественные (английский, русский) языки.
Опыт показывает, что это не совсем так.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."
> Для выполнения формализации код лучше подходит, чем естественные (английский, русский) языки.
Опыт показывает, что это не совсем так.
---
"И опыт, сын ошибок трудных, и гений, парадоксов друг..."
Опыт показывает, что это не совсем так.А как?
Офигеть, я внезапно дико согласен со всем что КОНТРА написал в этом треде до сих пор. Это всё правда!
Особенно про код как формализацию, ай лолд от оригинального коммента, хотя тут есть нюанс: хороший аналитик должен быть нормальным программистом, как минимум чтобы не писать херни не понимая на глубоком интуитивном уровне разницы между "A && (B || C)" и "(A && B) || C" (многие аналитики сосут).
Я занимаюсь разработкой имплементацией межбанковских интерфейсов, я дико ближе к тому, что собирается сделать топикстартер, чем КОНТРА, и я всеми руками поддерживаю то, что он сказал.
Вам не программисты нужны, программисты сосут в таких вещах обычно, ну или по крайней мере качества "хорошего программиста" весьма слабо пересекаются с качествами "хорошего business analyst". Вам вот эти нужны, и я чота дико сомневаюсь что их можно понанимать по объявлениям, потому что их хорошесть хз как определить посредством интервью, это всё на репутации более или менее. Пойдите в какой-нибудь банк (хотя бы туда, куда сбежали предыдущие кодеры спросите там у кодеров чьи задания им нравится выполнять, предложите этому человеку дофига бабла и разные перспективы.
EDIT: А, ну ещё вам будет нужен опытный программист всё же, который послушает что скажет business analyst почитав оригинальный код и разработает общий API, типа. Как все эти кусочки оригинального кода должны быть переписаны чтобы они делали свои похожие но разные вещи, выделив похожие вещи в общие для всех интерфейсы. Чтобы новый код был менее похож на миску спагетти чем старый (иначе зачем переписывать-то?)
То есть я к тому что, 1) наняв кучу хороших программистов вы не решите проблему с пониманием того, что в оригинальном коде важно, а что там делается именно так, как оно делается там, случайно, потому что кодеры так нафигачили код, чтобы отделить зёрна от плевел вам нужен хороший business analyst. 2) наняв кучу хороших программистов вы не решите проблему с структурированием нового кода чтобы он был лучше чем старый код, для этого вам нужен более чем просто хороший программист, для этого вам нужен чувак который дизайнил АПИ множество раз и множество раз наворотил херни и научился чему-то в процессе.
Особенно про код как формализацию, ай лолд от оригинального коммента, хотя тут есть нюанс: хороший аналитик должен быть нормальным программистом, как минимум чтобы не писать херни не понимая на глубоком интуитивном уровне разницы между "A && (B || C)" и "(A && B) || C" (многие аналитики сосут).
Я занимаюсь разработкой имплементацией межбанковских интерфейсов, я дико ближе к тому, что собирается сделать топикстартер, чем КОНТРА, и я всеми руками поддерживаю то, что он сказал.
Вам не программисты нужны, программисты сосут в таких вещах обычно, ну или по крайней мере качества "хорошего программиста" весьма слабо пересекаются с качествами "хорошего business analyst". Вам вот эти нужны, и я чота дико сомневаюсь что их можно понанимать по объявлениям, потому что их хорошесть хз как определить посредством интервью, это всё на репутации более или менее. Пойдите в какой-нибудь банк (хотя бы туда, куда сбежали предыдущие кодеры спросите там у кодеров чьи задания им нравится выполнять, предложите этому человеку дофига бабла и разные перспективы.
EDIT: А, ну ещё вам будет нужен опытный программист всё же, который послушает что скажет business analyst почитав оригинальный код и разработает общий API, типа. Как все эти кусочки оригинального кода должны быть переписаны чтобы они делали свои похожие но разные вещи, выделив похожие вещи в общие для всех интерфейсы. Чтобы новый код был менее похож на миску спагетти чем старый (иначе зачем переписывать-то?)
То есть я к тому что, 1) наняв кучу хороших программистов вы не решите проблему с пониманием того, что в оригинальном коде важно, а что там делается именно так, как оно делается там, случайно, потому что кодеры так нафигачили код, чтобы отделить зёрна от плевел вам нужен хороший business analyst. 2) наняв кучу хороших программистов вы не решите проблему с структурированием нового кода чтобы он был лучше чем старый код, для этого вам нужен более чем просто хороший программист, для этого вам нужен чувак который дизайнил АПИ множество раз и множество раз наворотил херни и научился чему-то в процессе.
> Офигеть, я внезапно дико согласен со всем что КОНТРА написал
> в этом треде до сих пор. Это всё правда!
Ты тут что-то ответил, потом, пока я думал, ещё что-то поисправлял,
и теперь уже трудно понять, с чем же "всем" ты согласен. Изначально,
я просто возражал на два утверждения: первое, что работа не делится
на "возвышенное" и "приземлённое," и второе, что для формализации
код подходит лучше естественного языка. А ты сразу начал говорить
про то, кто именно нужен.
Я готов согласиться с тем, что _как_правило_ (то есть, это не является
таким уж необходимым) тот, кто знает предметную область, и тот, кто
знает программирование, это два разных человека. Я правда считаю, что
это не обязательно так, существует куча областей, где достаточно
опытный программист способен поставить заказчику осмысленные для обоих
вопросы и получить осмысленные ответы, переводящиеся в требования.
Основным положением в моём возражении является необходимость вот
такого достаточно опытного программиста, способного выступать
проектировщиком. Эта необходимость мной воспринимается именно что
как деление на существование "возвышенного" программирования
и "кодирования."
Требуется ли предметный специалист в конкретной постановке задачи,
этого я вообще не рассматривал. Может быть, и требуется, это надо
смотреть по обстоятельствам.
Далее, по поводу формализации. Я готов согласиться с утверждением,
что формализацию можно выполнять в виде кодирования, но боюсь, что
мы подразумеваем совсем разные подходы к этому кодированию.
То есть, я не готов утверждать, что подобный код можно писать на
т.н. "промышленных" языках программирования. Более того, у меня
был опыт борьбы с горе-проектировщиком, который пытался сразу же
писать такую формализацию на сях. Возможно, что у кого-нибудь
другого, кто смыслит в типизации получше, это бы и получилось,
но в целом ситуация в промышленности такова, что ожидать
грамотной формализации в виде кода, по-моему, не стоит.
По поводу понанимать по объявлениям я не согласен. У любого
толкового программиста есть, в общем-то, своего рода "портфолио:"
в каких проектах он участвовал, что писал, с чем сталкивался.
Репутация же --- это дело куда более тонкое. Я бы на неё не полагался.
Хорошую репутацию можно заслужить нахрапом: взялся за проект,
довёл его до прототипа, но до выпуска ушёл на другой проект,
после повторения такого два-три раза человек внезапно становится
"опытным проектировщиком," хотя он не решил ни одной задачи,
и за ним всегда всё приходилось переделывать. Был такой случай.
Даже не один.
---
"И, как сказал философ Ю. Карякин,
Не разберёшь, где трасса, где объезд..."
> в этом треде до сих пор. Это всё правда!
Ты тут что-то ответил, потом, пока я думал, ещё что-то поисправлял,
и теперь уже трудно понять, с чем же "всем" ты согласен. Изначально,
я просто возражал на два утверждения: первое, что работа не делится
на "возвышенное" и "приземлённое," и второе, что для формализации
код подходит лучше естественного языка. А ты сразу начал говорить
про то, кто именно нужен.
Я готов согласиться с тем, что _как_правило_ (то есть, это не является
таким уж необходимым) тот, кто знает предметную область, и тот, кто
знает программирование, это два разных человека. Я правда считаю, что
это не обязательно так, существует куча областей, где достаточно
опытный программист способен поставить заказчику осмысленные для обоих
вопросы и получить осмысленные ответы, переводящиеся в требования.
Основным положением в моём возражении является необходимость вот
такого достаточно опытного программиста, способного выступать
проектировщиком. Эта необходимость мной воспринимается именно что
как деление на существование "возвышенного" программирования
и "кодирования."
Требуется ли предметный специалист в конкретной постановке задачи,
этого я вообще не рассматривал. Может быть, и требуется, это надо
смотреть по обстоятельствам.
Далее, по поводу формализации. Я готов согласиться с утверждением,
что формализацию можно выполнять в виде кодирования, но боюсь, что
мы подразумеваем совсем разные подходы к этому кодированию.
То есть, я не готов утверждать, что подобный код можно писать на
т.н. "промышленных" языках программирования. Более того, у меня
был опыт борьбы с горе-проектировщиком, который пытался сразу же
писать такую формализацию на сях. Возможно, что у кого-нибудь
другого, кто смыслит в типизации получше, это бы и получилось,
но в целом ситуация в промышленности такова, что ожидать
грамотной формализации в виде кода, по-моему, не стоит.
По поводу понанимать по объявлениям я не согласен. У любого
толкового программиста есть, в общем-то, своего рода "портфолио:"
в каких проектах он участвовал, что писал, с чем сталкивался.
Репутация же --- это дело куда более тонкое. Я бы на неё не полагался.
Хорошую репутацию можно заслужить нахрапом: взялся за проект,
довёл его до прототипа, но до выпуска ушёл на другой проект,
после повторения такого два-три раза человек внезапно становится
"опытным проектировщиком," хотя он не решил ни одной задачи,
и за ним всегда всё приходилось переделывать. Был такой случай.
Даже не один.
---
"И, как сказал философ Ю. Карякин,
Не разберёшь, где трасса, где объезд..."
Оставить комментарий
36219zvi
Про то, чем отличаются хорошие разработчики от обычных, как прикинуть эффективность человека и чем руководствоваться при разделении задачек.Желательно, чтобы на русском и в электронном виде существовала
Гуглить я умею - но хочу с вами посоветоваться, чтобы не читать, чего не следует.
Спасибо.