Comments 81
Знаете, в наше время анализировать надо еще уметь\хотеть. А что б правильно или даже честно проанализировать ситуацию, нужно уметь признавать свои ошибки, а как известно многие этого не любят (тут кстати еще и религия приходит на помощь ).
Ага. Я испытываю сейчас существенные проблемы с программистом, который каждый багрепорт воспринимает в штыки, почти как наезд. Из-за этого пачка спорных багов так и висит, потому что иногда проще стерпеть баг, чем в очередной раз воевать, доказывая, что весь цивилизованный мир делает так, и нет ни одной разумной причины делать по-другому.
Безотносительно к багрепортам и чему-либо.
Аргумент «весь цивилизованный мир делает так» — сродни фразе — миллионы мух не могут ошибаться. Я бы тоже упирался если бы меня заставляли переделывать под предлогом — «ну все так делают».
История человечества ( а особенно IT-индустрии) показывает, что количество тупых решений, которые способны придумать люди, не ограничивается фантазиями каждого человека — синергетический эффект дает потрясающий прирост спискам идиотских, тупых и неудобных решений, а также архитектурных и технологических уродцев.
Аргумент «весь цивилизованный мир делает так» — сродни фразе — миллионы мух не могут ошибаться. Я бы тоже упирался если бы меня заставляли переделывать под предлогом — «ну все так делают».
История человечества ( а особенно IT-индустрии) показывает, что количество тупых решений, которые способны придумать люди, не ограничивается фантазиями каждого человека — синергетический эффект дает потрясающий прирост спискам идиотских, тупых и неудобных решений, а также архитектурных и технологических уродцев.
Если продукт для миллионов мух, то с этим фактором обязательно надо считаться)))
Ну, например, весь цивилизованный мир называет логи application.log, а при ротации делает .log.0, .log.1 и т.д. Нет ни одной причины писать лог в application.log.1 и ротировать его .2, 3 и т.д. Весь цивилизованный мир привык к debian policy и к тому, что демон должен останавливаться по /etc/init.d/app stop, а не с помощью специальных манипуляций и т.д.
Это соглашение, а не стандарт. Вменяемый человек следует соглашениям ровно до тех пор, пока не возникнет обоснованного аргумента от них отойти и сделать по-другому.
Было время когда цивилизованный мир «жил без мышки», или мышка была без колесика. Сейчас уже никто на эту тему не парится особо и априори у мышки есть 3 кнопки+колесико.
В общем все такие привычки и соглашения — очень частный случай, человечество не обязано следовать привычкам. просто если следовать разным привычкам\соглашениям — всем будет удобнее, но не более.
Это вопрос философский, поэтому вам не удастся навязать следование соглашениям, ее можно только привить объясняя человеку откуда это взялось и почему это всем удобно.
Ну или закрепите соглашения на уровне внутренних приказов и стандартов — так тоже можно =), только это перестанет быть соглашением =).
Было время когда цивилизованный мир «жил без мышки», или мышка была без колесика. Сейчас уже никто на эту тему не парится особо и априори у мышки есть 3 кнопки+колесико.
В общем все такие привычки и соглашения — очень частный случай, человечество не обязано следовать привычкам. просто если следовать разным привычкам\соглашениям — всем будет удобнее, но не более.
Это вопрос философский, поэтому вам не удастся навязать следование соглашениям, ее можно только привить объясняя человеку откуда это взялось и почему это всем удобно.
Ну или закрепите соглашения на уровне внутренних приказов и стандартов — так тоже можно =), только это перестанет быть соглашением =).
Я тоже часто багрепорты воспринимаю в штыки :) Но оправдываю себя тем, как их формулируют и преподносят
спросите его как решить эту проблему, может он и сам предложит что-то конструктивное
На эту тему был отличный рассказ на ConfeT&QA:
«Я не буду это фиксить – это не баг!, или особенности юзабилити-багопроизводства» от Андрея Мясникова
Материалы просили не заливать никуда, попробуйте поспрашивать знакомых — может у кого-то осталась запись.
Там подробно описывается как найти подход к такого рода программистам, какие уловки для этого существуют.
«Я не буду это фиксить – это не баг!, или особенности юзабилити-багопроизводства» от Андрея Мясникова
Материалы просили не заливать никуда, попробуйте поспрашивать знакомых — может у кого-то осталась запись.
Там подробно описывается как найти подход к такого рода программистам, какие уловки для этого существуют.
У меня тоже были проблемы с программистом, который воспринимал любую критику негативно.
Думаю, либо у человека дома не всё в порядке, либо работой перегружен, что просто срывается. Такого в отпуск срочно, пусть проспится, а потом решит свои домашние проблемы.
Первое. Конструктивный диалог иногда помогает. Мы же взрослые люди.
Второе. В каждом проекте есть соглашения разработки. Разработчик должен делать так, как принято в проекте, а не так, как ему хочется. Те или иные решения принимались не из-за хорошей жизни. А если они прижились, что значит они работают. А иначе всё будет — как в басне Крылова про 3-х животных. Если кто-то не следует соглашениям, то с этим тоже нужно что-то делать. Например, бить по рукам… :( но это уже крайний вариант
Думаю, либо у человека дома не всё в порядке, либо работой перегружен, что просто срывается. Такого в отпуск срочно, пусть проспится, а потом решит свои домашние проблемы.
Первое. Конструктивный диалог иногда помогает. Мы же взрослые люди.
Второе. В каждом проекте есть соглашения разработки. Разработчик должен делать так, как принято в проекте, а не так, как ему хочется. Те или иные решения принимались не из-за хорошей жизни. А если они прижились, что значит они работают. А иначе всё будет — как в басне Крылова про 3-х животных. Если кто-то не следует соглашениям, то с этим тоже нужно что-то делать. Например, бить по рукам… :( но это уже крайний вариант
>> Чем отличается ваш код сегодня от вашего кода полугодичной давности?
Это точно, порой сам себе удивляюсь, как такой бред мог написать )))
Это точно, порой сам себе удивляюсь, как такой бред мог написать )))
Я смотрю на свой код месячной давности и хочу все стереть к чертовой матери и никому не показывать. Но останавливает меня осознание того факта, что через месяц я буду так же говорить о сегодняшнем коде и так далее. И это происходит уже лет 5-7. И это правильно.
Абсолютно тоже самое и с архитектурой и подходом к разработке: совсем недавно водопадная модель разработки была чем-то совершенным и непоколебимым, однако уже сейчас только ленивый ее не критикует. Никто не может дать гарантий, что то же самое не случится с современными подходами через год-два.
Поэтому надо оглядываться назад, заглядывать вперед, а делать сейчас.
Абсолютно тоже самое и с архитектурой и подходом к разработке: совсем недавно водопадная модель разработки была чем-то совершенным и непоколебимым, однако уже сейчас только ленивый ее не критикует. Никто не может дать гарантий, что то же самое не случится с современными подходами через год-два.
Поэтому надо оглядываться назад, заглядывать вперед, а делать сейчас.
Да, собственно, это наверное и является основным показателем того, становитесь ли вы лучше как программист сам для себя. Если глядя на свой старый код не возникает ощущения и желания все переписать, то возможно два варианта: или вы гений и достигли совершенства (что в общем-то не достижимо и мало вероятно), или же вы просто перестали развиваться :) Хотя скорее всего вы даже и не пытались совершенствоваться. У меня вот есть такие примеры… 3 года — а /*говно*/код как был, так и есть…
Это происходит потому, что в момент возврата к коду через месяц, вы не до конца помните что там есть и зачем это все. Отсюда недоверие.
Чуть-чуть скорректировать архитектуру вы не в состоянии по той же самой причине — не помните тонкостей. Да и страшно: «сейчас ведь работает». Отсюда и желание написать все заново.
Пишите больше автоматических тестов (TDD или не TDD — вопрос десятый) и начнете себе доверять. Сможете лучше оценивать объем ранее сделанной работы и начнете понимать, что переделывать придется попросту Очень много — легче изменить часть которая действительно не устраивает.
Чуть-чуть скорректировать архитектуру вы не в состоянии по той же самой причине — не помните тонкостей. Да и страшно: «сейчас ведь работает». Отсюда и желание написать все заново.
Пишите больше автоматических тестов (TDD или не TDD — вопрос десятый) и начнете себе доверять. Сможете лучше оценивать объем ранее сделанной работы и начнете понимать, что переделывать придется попросту Очень много — легче изменить часть которая действительно не устраивает.
Хм. при чем тут недоверие и память? Это происходит не из-за того, что я не помню зачем я это писал, а из-за того, что сейчас я вижу как это сделать правильней и лаконичнее, например где-нибудь цикл заменить на LINQ выражение. Или Но я прекрасно понимаю, что если я начну это делать во всем коде, то я погрязну в рефакторинге.
Блин, отправилось случайно по Ctrl+Enter… там «Или» — лишнее.
А что вам мешает заменить цикл на LINQ только в этом месте? Почему это надо делать обязательно везде и сразу?
Я к тому, что локальный рефакторинг и «все стереть к чертовой матер» это немного разные вещи. За первое я двумя руками «за», второе же кажется немного странным поведением.
Я к тому, что локальный рефакторинг и «все стереть к чертовой матер» это немного разные вещи. За первое я двумя руками «за», второе же кажется немного странным поведением.
А потом в проекте получается винегрет из стилей и подходов. На мой взгляд постороннему человеку будет проще разобраться с кодом, если он написан хоть и в устаревшем, но едином стиле. Лично меня часто останавливает именно это. В инструкциях к лекарствам в таких случаях пишут «применять, если предполагаемая польза для пациента превышает возможный вред».
Я LINQ привел как пример.
Вы переводите тему разговора в немного дургую область. Суть не в том локальный рефакторинг или «стересть все к чертовой матери», а в том, что по прошествии некоторого времени разработчик просто обязан с ненавистью смотреть на свой старый код и хотеть его переписать. А вот как его переписывать — это уже другой вопрос. И не такой важный вопрос.
Вы переводите тему разговора в немного дургую область. Суть не в том локальный рефакторинг или «стересть все к чертовой матери», а в том, что по прошествии некоторого времени разработчик просто обязан с ненавистью смотреть на свой старый код и хотеть его переписать. А вот как его переписывать — это уже другой вопрос. И не такой важный вопрос.
Рефакторинг — это что-то типа полироля для кода. Если по какой-то причине возвращаешься к своему, старому коду (не для того, что бы его лишний раз облизать, а вполне по делу) и что-то в нем не нравится надо пройти вполне конкретную формальную процедуру: ответить себе на вопрос, а что же конкретно плохо; определить стратегию исправления (возможно на несколько итераций вперед)… В общем ничего нового.
У меня например, есть библиотеки чей код я обожаю — к нему я возвращаюсь (по делу!!!) минимум раз в пол года. Есть проекты, чей код устраивает — которым было уделено больше двух итераций. А есть, чей не нравится — который писался до того как определилась природа описанных в нем сущностей (если вернусь, немного перераспределю обязанности).
Фаулер этому явлению предложил название — «запах»
Факт того, что код мне не нравится, я объясняю не тем что вчера был тупее. А тем, что уделил ему суммарно мало времени. Если возникнет необходимость уделю больше.
У меня например, есть библиотеки чей код я обожаю — к нему я возвращаюсь (по делу!!!) минимум раз в пол года. Есть проекты, чей код устраивает — которым было уделено больше двух итераций. А есть, чей не нравится — который писался до того как определилась природа описанных в нем сущностей (если вернусь, немного перераспределю обязанности).
Фаулер этому явлению предложил название — «запах»
Факт того, что код мне не нравится, я объясняю не тем что вчера был тупее. А тем, что уделил ему суммарно мало времени. Если возникнет необходимость уделю больше.
Прям уж так и полироль.
Напомню цикл рефакторинга. Зафиксировали состояние — изменили — убедились, что не сломалось.
И да, изменения атомарны. Но если каждое изменение маленькое — совсем не значит, что таким образом мало что можно изменить. Постепенным движением можно перелопатить пол-проекта, включая даже какие-то архитектурные основания.
И да, таким методом можно победить синдром «все переписать».
Напомню цикл рефакторинга. Зафиксировали состояние — изменили — убедились, что не сломалось.
И да, изменения атомарны. Но если каждое изменение маленькое — совсем не значит, что таким образом мало что можно изменить. Постепенным движением можно перелопатить пол-проекта, включая даже какие-то архитектурные основания.
И да, таким методом можно победить синдром «все переписать».
А вы вечером прочитайте написанный за день код. Выкинуть не захотелось? ;-)
UFO just landed and posted this here
Первое утверждение — ложное. Если бы в этом мире существовали заказчики с ТЗ, то мы бы уже триста раз собрали и зарелизили коммунизм.
Они существуют. поэтому человечество уже зарелизило коммунизм в альфа версии (немного не похож на ТЗ) — сейчас идут итеративные циклы рефакторинга ;)
Они существуют, но на территории постсоветского пространства их процент очень мал. Поработав с иностранцами могу сказать, что у них ТЗ очень и очень подробные и в этом смысле работать с ними одно удовольствие. Они просто прекрасно понимают, что дешевле один раз написать грамотное ТЗ, чем 5 раз создать мертворожденные прогарммы.
Работаю с заказчиками, у которых есть ТЗ, грамотное, содержательное, лаконичное. Я опять что-то делаю не так?
Или «этот мир» и мой мир — разные вещи? :)
Или «этот мир» и мой мир — разные вещи? :)
Если в вашем мире нет заказчиков с ТЗ, то ваши проблемы с программистом неудивительны.
Ну а просто «Хороший программист» в понимании профессии? Например хороший плиточник ровно кладет плитку, а программист? Может быть хороший программист это опытный программист, который постоянно держит себя в тонусе (не обязательно осваивает все новые тулзы и техники, но знает о них и возможно об особенностях их применения), даже при условии что работает на злую корпорацию которая использует его как печатную машинку.
Обычно первый пункт убивает в программисте программиста, тк сроки обычно невыполнимые (всякие менеджеры и другие гуманитарии любят много чего наобещать чтобы выиграть тендер, и по другим причинам) чтобы написать хороший код в рабочее время, поэтому обычно пишется абсолютный быстро-код. А да, на рефакторинг тоже редко бывает время, да и желание при таком подходе.
Обычно первый пункт убивает в программисте программиста, тк сроки обычно невыполнимые (всякие менеджеры и другие гуманитарии любят много чего наобещать чтобы выиграть тендер, и по другим причинам) чтобы написать хороший код в рабочее время, поэтому обычно пишется абсолютный быстро-код. А да, на рефакторинг тоже редко бывает время, да и желание при таком подходе.
Ко мне те же мысли приходили насчет того, что хороший программист это не тот кто знает все как ходячая энциклопедия, а тот кто умеет эти знания применять. Приходилось мне после 1-го баги латать и архитектуру приложения рефакторить, та еще радость оказалась…
Плохой программист сделает программу за неделю, а если есть доступ к Интернету за 1 день.
Хороший программист тоже сделает программу за неделю, а если нет доступа к Интернету за 1 день.
Хороший программист тоже сделает программу за неделю, а если нет доступа к Интернету за 1 день.
На мой взгляд хороший программер это тот, который спустя годы натолкнулся на код и поняв его воскликнул «Вот именно так и надо писать программы», забыв при этом что автором этого кода является он сам.
Именно к этому критерию и стремлюсь, но пока могу сказать, что не совсем хороший программер, т.к. всегда нахожу что-нибудь что можно зарефакторить.
З.Ы.: Это стремление было сгенерировано в моей голове после прочтения Реймонда про программирование под UNIX, разделы «компактность» и «воспринимаемость»
Именно к этому критерию и стремлюсь, но пока могу сказать, что не совсем хороший программер, т.к. всегда нахожу что-нибудь что можно зарефакторить.
З.Ы.: Это стремление было сгенерировано в моей голове после прочтения Реймонда про программирование под UNIX, разделы «компактность» и «воспринимаемость»
Первая же фраза под катом — «Честно говоря, не знаю» заставила почувствовать себя безнадежно обманутым, и чувство это не улетучилось и по прочтении всей статьи. (
«Хороший программист — это тот, кто смотрит в обе стороны, переходя дорогу с односторонним движением» — взято со статьи, которую читал тут же. Смысл хороший, о многом говорит.
Работал с порядка 20 программистами, как рядом так и руководствуя. И сдается мне что всё что нужно программисту — интерес. Тогда, если есть мозги — приходит опыт, иначе — пропадает и интерес развиваться. Правда бывают еще «с интересом» плюс с нехорошей инициативой, поэтому ниже еще акцептанс тест.
Хороший программист:
1. Пишет код, фокусированно, потому что ему нравится. Почти не сидит на развлекательных.
2. Сфокусирован на результатах, а не на процессе.
3. Тестирует то, что он сделал. Вообще, относится скептически к своей гениальности.
4. Спрашивает себя «какие внештатные ситуации я забыл проверить» (плюс позднее еще «как недопустить и те, о которых я только догадываюсь») и сохраняет этот опыт (не все же сразу знают об XSS, SQL injections, CSRF, ...)
Хороший программист:
1. Пишет код, фокусированно, потому что ему нравится. Почти не сидит на развлекательных.
2. Сфокусирован на результатах, а не на процессе.
3. Тестирует то, что он сделал. Вообще, относится скептически к своей гениальности.
4. Спрашивает себя «какие внештатные ситуации я забыл проверить» (плюс позднее еще «как недопустить и те, о которых я только догадываюсь») и сохраняет этот опыт (не все же сразу знают об XSS, SQL injections, CSRF, ...)
UFO just landed and posted this here
На мой взгляд на Ваш вопрос нету единственно правильного ответа. Но тем не менее я склоняюсь к тому что человек работает для того чтобы жить, а не живет для того чтобы работать. У меня есть семья, есть та которая заставляет биться мое сердце и если честно, то никакое хобби не заменит мне семью. Задачи могут быть сколь угодно интересными, но ни одной задаче не под силу вызвать те самые эмоции, которые возникают, когда моя жена улыбается мне.
Это при том, что сам люблю засидеться до глубокой ночи изучая FreeBSD или чего-нить разрабатывая или еще чего-нить )
Это при том, что сам люблю засидеться до глубокой ночи изучая FreeBSD или чего-нить разрабатывая или еще чего-нить )
Ест такие люди, захваченные идеей, с искрой в глазах, прокручивание алгоритмов и решений в голове происходит у них произвольно, просто само так происходит, не могут они по другому, и иногда их считают ненормальными. Но такой энтузиазм если работать «в коробке» быстро пройдет :)
А здесь не важно, программист вы, или проектировщик настольных ламп. Это вопрос подхода к работе. Я отношусь к тем людям, которые практикуют подход «работа — это большая часть жизни, а не сдача себя в аренду с 9 до 18». Т.е. я не делю работу и остальное — для меня это одноранговое множество.
В жизни человек занимается любыми действиями определенные моменты времени. Например, если я катаюсь на велосипеде по вторникам и пятницам, это не мешает думать о моих поездках, планировать следующую поездку вечером в четверг сидя дома в кресле. С работой ровно то же самое.
Самое важное в таком подходе — уметь расставлять приоритеты. Если не уметь, то такой подход приведет к трудоголии, карьеризму и смерти семейной жизни.
А профит такого подхода огромен и для меня мегаважен — я живу своей жизнью не в свободное от работы время, а круглосуточно. Для меня работа — это не тяжкий «крест», а такая же приятная вещь, как катание на велосипеде.
Кстати, я веб-программист, руковожу небольшим отделом, занимаюсь в том числе серверами, некоторыми административными задачами по проектам.
В жизни человек занимается любыми действиями определенные моменты времени. Например, если я катаюсь на велосипеде по вторникам и пятницам, это не мешает думать о моих поездках, планировать следующую поездку вечером в четверг сидя дома в кресле. С работой ровно то же самое.
Самое важное в таком подходе — уметь расставлять приоритеты. Если не уметь, то такой подход приведет к трудоголии, карьеризму и смерти семейной жизни.
А профит такого подхода огромен и для меня мегаважен — я живу своей жизнью не в свободное от работы время, а круглосуточно. Для меня работа — это не тяжкий «крест», а такая же приятная вещь, как катание на велосипеде.
Кстати, я веб-программист, руковожу небольшим отделом, занимаюсь в том числе серверами, некоторыми административными задачами по проектам.
Плюсы и минусы есть везде каждый решает сам что для него лучше. С одной стороны довольно полезно крутить детали реализации в голове, можно решить некоторые проблемы еще до начала написания кода, соответственно ускорить свою работу. С другой стороны думая все время об этом даже во сне, можно «перегореть», мозг это все таки не процессор, он должен отдыхать. Но если сильно увлечься отдыхом довольно трудно потом втянуться обратно в работу и в уже пройденные детали реализации.
«поскольку победителей олимпиад не так и много, а вакансий «ведущих» и «главных» пруд пруди, то эта планка опускается до более приземленного уровня.»
Очень распространенное заблуждение, что олимпиадник — хороший программист. Не нужно так думать, это неправда.
Очень распространенное заблуждение, что олимпиадник — хороший программист. Не нужно так думать, это неправда.
UFO just landed and posted this here
Верно. Но потенциал у него больше. Хотя бы потому что он «посвятил» часть своей жизни алгоритмам и умеет думать в нужном ключе.
Действительно ли? Имхо тут есть некая грань: человек, который умеет думать и человек, заточенный под быстрое решение искусственно поставленных задач, отсутствующих в 99% реальной жизни
Успешный олимпиадник (международного уровня) — это еще и гарантия отличного технического английского, гарантия того, что человек читая требования увидет все подводные камни, и реализация задачи будет для него рутиной а не подвигом.
Все это само собой может быть и у не олимпиадника, но это надо искать.
Все это само собой может быть и у не олимпиадника, но это надо искать.
Да к сожалению и такое есть. Олимпиадные задачи очень специфичны, и реальная работа не всегда требует знания алгоритмов.
Здесь суть именно в том что он умеет искать подход к решению поставленной задачи, обучаем т.к. в своё время он изучал алгоритмы (что явно заняло не мало времени).
Из субъективного, как мне помог олимпиадный опыт:
* Научился печатать «вслепую» совершенно незаметно для себя, т.к. когда пишешь задачи на время — смотреть на клавиатуру совершенно нет времени
* Научился именно «быстро» искать и писать решения. Пускай и не всегда они правильные, но это помогает не сидеть на месте без дела перед сложной непонятной задачей.
Здесь суть именно в том что он умеет искать подход к решению поставленной задачи, обучаем т.к. в своё время он изучал алгоритмы (что явно заняло не мало времени).
Из субъективного, как мне помог олимпиадный опыт:
* Научился печатать «вслепую» совершенно незаметно для себя, т.к. когда пишешь задачи на время — смотреть на клавиатуру совершенно нет времени
* Научился именно «быстро» искать и писать решения. Пускай и не всегда они правильные, но это помогает не сидеть на месте без дела перед сложной непонятной задачей.
Согласен. Можно провести аналогию со спортсменом и хорошим военным. Хороший военный — это не только отменная физическая форма.
Тут Боб Мартин пытается ответить.
Вот тут попытались перевести его ответ
UFO just landed and posted this here
«The three principal virtues of a programmer are Laziness, Impatience, and Hubris.» — Larry Wall
Довольно сложный вопрос, у каждого данное понятие вызывает разные ассоциации. У меня лично вызывают ассоциацию с человеком, который постоянно самосовершенствуется в своей области и готов признавать, что может совершать ошибки.
Пытался вам написать в блог по поводу этого поста, когда вы его написали в первый раз, но движок сказал, что всё плохо и комментарий не опубликовался. Напишу тут.
«С одной стороны, мы привыкли думать, что «хороший» программист – это обязательно гик в очках и растянутом свитере, победитель олимпиады по программированию»
Если бы я искал программиста, я ни за что не взял бы олимпиадника.
Ну и этот стереотип — старьё безумное. Мой топ программистов одет прилично, некоторые даже без очков.
«С одной стороны, мы привыкли думать, что «хороший» программист – это обязательно гик в очках и растянутом свитере, победитель олимпиады по программированию»
Если бы я искал программиста, я ни за что не взял бы олимпиадника.
Ну и этот стереотип — старьё безумное. Мой топ программистов одет прилично, некоторые даже без очков.
Автор, развивайте тему глубже, ведь по сути вы охватили только вопрос ретроспективы. Из-за этого ваша заметка выглядит очень поверхностной и не соответствующей заголовку. И не пишите, что не знаете ответа, это сильно дешевит. Либо обосновывайте, что правильного ответа нет.
Мне кажется только программисты загоняются по поводу своего профессионализма, такой мании среди других людей никогда не замечал. Хотя наверное я просто ещё молод.
Хороший программист отличается от плохого тем, что от чтения его кода не вскипает мозг.
Перед прочтением этой статьи пошел по ссылке о «хорошей архитектуре» (она над катом). Прочитал с удовольствием, даже прикинул по-быстрому переделку одного класса. почитал про паттерны, щелкнул пару статей на Вашем сайте. Вернулся на хабр, сразу плюсанул эту статью, добавил в избранное.
Только после этого открыл и прочел сабж. Разочарован. Как-то несерьезно и даже обидно. За предыдущие статьи — спасибо. Эта ценна разве что коментариями.
Только после этого открыл и прочел сабж. Разочарован. Как-то несерьезно и даже обидно. За предыдущие статьи — спасибо. Эта ценна разве что коментариями.
Товарищ Пол Грэм о хороших программистах www.paulgraham.com/start.html
> So as a rule you can recognize genuinely smart people by their ability to say things like «I don't know,» «Maybe you're right,» and «I don't understand x well enough.»
Я с ним согласен. Хороший программист это может и золотой медалист/красный дипломник или суровый олимпиадник или успешный фрилансер или автор десятка классных программ или книг. Но он обязательно должен уметь говорить «я не знаю». Без этого с ним каши не сваришь.
> So as a rule you can recognize genuinely smart people by their ability to say things like «I don't know,» «Maybe you're right,» and «I don't understand x well enough.»
Я с ним согласен. Хороший программист это может и золотой медалист/красный дипломник или суровый олимпиадник или успешный фрилансер или автор десятка классных программ или книг. Но он обязательно должен уметь говорить «я не знаю». Без этого с ним каши не сваришь.
спасибо за советы,
я задавал похожие вопросы — но уже касательно проектам:
Ваш самый удачный проект
Ваш самый трудный проект
Ваш самый неудачный проект
Ваш самый интересный проект
Какой проект Вам захотелось бы реализовать.
из ответов на это уже виден кругозор и целеустремленность программиста.
я задавал похожие вопросы — но уже касательно проектам:
Ваш самый удачный проект
Ваш самый трудный проект
Ваш самый неудачный проект
Ваш самый интересный проект
Какой проект Вам захотелось бы реализовать.
из ответов на это уже виден кругозор и целеустремленность программиста.
Если рассматривать статью в целом, то можно уместить её в предложении:
Растекаясь мыслью по древу стоит направить свой взгляд в прошлое, и оценить себя, и сделать выводы.
Было бы интересно почитать о различных методиках и способах оценки :) Какой-то более-менее адекватный набор критериев что-ли :)
Растекаясь мыслью по древу стоит направить свой взгляд в прошлое, и оценить себя, и сделать выводы.
Было бы интересно почитать о различных методиках и способах оценки :) Какой-то более-менее адекватный набор критериев что-ли :)
Sign up to leave a comment.
Кто такой «хороший программист»?