Pull to refresh

Comments 141

Должен ли код радовать самого программиста? Ну, конечно же, должен. Иначе зачем ему, собственно, работать программистом? Не за деньги же мы все здесь работаем, правда?

Самая сильная фраза!
«Предпочтения у программистов в коде — они как у мужчин в женщинах: кому-то нравятся брюнетки, кому-то блондинки, а кому-то — не очень красивые женщины… Такие люди обычно на перле программируют.»

Тоже круто.
Я не минусую. Просто некрасиво выдавать за цитату, то, чего нет в тексте.
Спс. Не имел возможности посмотреть видео, теперь понятно.
Я думал что ослышался! Оказывается уже 35 таких как я не ослышались )
Я после вашего комментария понял, что видео таки нужно посмотреть :).
Можно поподробнее, в чем сила этой фразы?
Это крик помощи. Яндекс не платит разработчикам
В свете этой фразы видео приобретает иные краски! Разработчиков держат в бетонном бункере с красочной надписью Яндекс, не платят деньги, плохо кормят, не предоставляют бритвенные принадлежности и заставляют писать красивый код и отчитываться сколько красивого кода, а главное почему красивого, они написали. Неожиданно!
самая тролльская фраза :)
Для меня например все просто, красивый код — это код который я не могу больше улучшить.
Т.е. для вас это работает только бинарно — или красивый, или некрасивый, без оттенков?
Тут вернее было бы сказать тогда идеальный код. Вот он −да, без оттенков.
Мое имхо.
ИМХО. Идеального кода не бывает, потому что совершенству нет предела.
Может быть, это Perl, откуда вы знаете :)
Есть. Код, которого нет — вот истинное совершенство :-) Он действительно идеален.
Почему нет? В каждый момент времени вы либо можете улучшить код, либо нет. Какие тут оттенки?
Мне кажется, что ситуация, когда код вообще никак нельзя улучшить, встречается крайне редко. Вопрос в том, сколько на это уйдёт сил и времени.

Исходя из вашего определения, таким образом, получится, что красивый код почти не встречается.
Ну почему редко? Устал, смотришь в код и не видишь возможности сделать лучше. Бывает же :)
Ну почему же, градация есть, в зависимости от количества возможных улучшений.
Не бывало не раз такого? Пол года усердно полируешь полируешь код, а за это время он уже никому оказывается не нужным. Вот такой красивый и не нужный код…
Просто из опыта могу сказать, что код можно улучшать бесконечно, сегодня он кажется идеальным, а завтра ты с нуля все переписываешь) Поэтому тут нужно знать меру и выбирать правильный баланс между идеальностью кода и его полезностью. Правильно сказано: код должен быть не противным.
Бывало часто, поэтому оптимизации я стараюсь делать там где нужно, а сначала пишу код который просто работает.
Вот такой красивый и не нужный код…

… достойный экземпляр для палаты мер и весов :)
«Художник не тогда знает, что он достиг совершенства, когда нечего добавить, но когда нечего больше отнять». (Антуан де Сент-Экзюпери)
Это уже идеальный код.
Чем опытней, тем менее категоричней. В итоге все приходят рано или поздно балансу в виде
код должен быть, по крайней мере, не очень противным
Кстати, по моим наблюдениям, — менее категоричные сами пишут лучше.
Странно, что никто не упомянул конвенции.
Всё-таки, они скорее не о красоте, а о некоторых санитарных стандартах.
А то, как правильно пробелы расставлять, какие переменным имена давать, по каким файликам свой проект разложить и в какие папочки, я считаю суетой. Надо быть выше этого: как договоришься с коллегами, так и делай. Пусть другие об этом спорят.
Код сам по себе — почти чепуха, его можно переписывать. Даже если ничего не изменяется, он все равно по какой-то причине портится.

Кен Томпсон
Должен ли код радовать самого программиста? Ну, конечно же, должен. Иначе зачем ему, собственно, работать программистом? Не за деньги же мы все здесь работаем, правда?


Ну вообще то за деньги и только за деньги, перестань Вам их платить или платить хотя бы в 2 раза меньше Вы уйдете с этой работы. За последние лет 7 я почти не видел человека, который бы работал за моральное удовлетворение или за спасибо и которому бы не важен был уровень его ЗП.
Конечно, не только за деньги.
Если мне перестанут платить, или будут платить заметно меньше — безусловно я уйду.
Но программировать я не перестану!
А если будут платить больше, раза в 2 и скажут, что нужно перестать программировать, а руководить? Уверен, что перестанете программировать. Собственно вот он ответ на извечный вопрос, зачем мы работает — деньги зарабатываем.
Боюсь не поверите, но у меня два года назад была такая же ситуация. Сделали начальником отдела, дали двух молодых программистов и аналитика, теперь на работе не программирую вовсе, только руковожу. Однако дома начал программировать вдвое больше (для души), не смог таки отказаться :)
95% вероятности, что Children.count() < 1
К счастью для моего внутреннего программиста — да. Программировать буду меньше, но хотеть программировать — отнють )
Хотеть не программировать, поэтому работу лучше выбирать по душе. Удачи в этом нелегком мире, в общем :)
Если Вы сейчас программируете только для того, чтобы стать руководителем и получать больше денег, то мне кажется вы избрали неверный путь для достижения своих целей.
Кесарю кесарево…
Дело в том, что если Вы программируете профессионально и это Ваш хлеб, то рано или поздно у Вас будет меньше этого хлеба или Вас вообще понизят или уволят. Просто есть такая штука как возраст, и с возрастом Вы не сможете держать ту высокую планку, как требует работодатель и выполнять так же быстро задания как программист моложе Вас. Конечно если Вам 25, то об этом задумываться рано, но когда Вам 35, то тут стоит очень хорошо подумать. Поэтому, тут два пути: первый — становится начальником программистов, и хоть сам Вы не будите программировать, зато останетесь на счету и в почете + будите получать больше, либо путь номер два — искать другую профессию. Вариант номер два гораздо сложнее для программиста, в виду некоторых особенностей склада ума, нельзя быть до 40 лет программистом, а в 41 стать телеведущим.
Мне кажется Вы немного заблуждаетесь. Я могу привести много примеров людей, который до сих пор программируют будучи уже в возрасте далеком от 35. Навскидку тот же Эрих Гамма — один из авторов книги про паттерны проектирования.

Вопрос у меня возник. Если бы работа мастера по укладке кафельной плитки Вам денег приносила больше, чем работа программистом, вы бы стали «кафельщиком»?
Дело не в том, что они программируют в возрасте за 40, а в том насколько эффективно, по сравнению с талантливым 25-летним программистом. И еще момент, одно дело работать на «дядю», другое на себя. Принимайте во внимание и этот факт.
И я могу привести другой пример, Линус Торвальдс, думаю он более известен чем Эрих Гамма. Дак вот он сейчас, по большей части, руководит разработкой ядра, а программирует гораздо меньше, чем как когда-то. Думаете почему?

Почему из бизнеса уходят в политику? Одна из причин — политикой можно заниматься и в 80 лет, руководить компанией из 5 тыс. сотрудников — нет.
Я считаю что возраст не имеет решающего значения в вопросе эффективности. Люди разные, соответственно и квалификация у них разная. Также в этом вопросе не будет однозначности, т.к. опыта в программировании будет больше в 40, нежели чем в 25.

Мне понятна Ваша мысль, как и понятны опасения, т.к. в молодую команду программистов вряд ли возьмут какого-нибудь «старца», потому что мыслят стереотипно и считают что он не уживется с «молодыми и амбициозными» (а зря, был положительный опыт).

По поводу Торвальдса не знаю — может не интересно стало или занят более важными занятиями.

По себе скажу, может я еще молод и глуп, но работаю вот не только ради денег. Руководителем быть пока что не хочу, да и не сумею (потому в свое время отказался от статуса CTO). Возможно моя позиция не окончательная и лет через эдак 10 я и пересмотрю свои взгляды, но вот пока так.
UFO just landed and posted this here
Как-то вы однобоко сравниваете…
Тупой 40 летний прогер и талантливый 25 летний.
А вы сравните многоопытного, талантливого и т.д. и т.п. 40 летнего гуру программиста и 25 летнего новодела, который без гугла и foo buzz test не сможет сделать)
В первую очередь играют роль личностные качества и уже потом все остальное.

Все ваши примеры притянуты за уши и откровенно отдают юношеским максимализмом). Линус Торвальдс стал меньше программировать не потому, что отупел, а потому что организация разрастается, и кто-то должен руководить. Он, как автор начальной идеи, лучше всего подходит на роль продакт менеджера.
Из бизнеса уходят в политику тоже не потому что тупеют, а потому что это следующая ступень власти, которая открывает новые возможности в том числе и по заработку.
Опять же, далеко не все уходят из бизнеса в политку. Даже половина бизнесменов не уходит.
Многие программисты, с возрастом, просто перестают метаться как молодняк, от одной технологии к другой. Перестают мерятся у кого больше аббревиатур в резюме. Они выбирают ту, которая им больше всего по душе и становятся в ней асами.
Вы глубоко заблуждаетесь по обоим пунктам. В политику уходят из тщеславия, а не потому что уже в полной немощи рулить бизнесом. Кто-то от жадности. И уж в редких случаях — от альтруистического желания служить своему народу вместо коллектива своей фирмы. Управлять государством независимо от мотивации (эгоизм или альтруизм) неизмеримо сложнее, чем фирмой, где вы по сути диктатор и можете выпилить все деструктивные элементы, например. Но это все за скобками сабжа.

Не всем программистам найдется руководящее место, так уж сложилось, что руководителей меньше чем подчиненных. Но в этом нет никакой трагедии. Работа программиста как раз одна из тех, где качество куда важнее скорости. И спешить обычно как раз не стоит. Старый конь борозды не испортит. Место профессионалу найдется всегда.

(не говоря уже о факторе наших зарплат. Джуниоры в других профессиях столько не получают)
Больше позитива, бро!
Кризис среднего возраста к товарищу пришел :)
Пройдет.
Фраза — «Суммарный опыт программирования всех участников этого микроинтервью на восьмерых составляет 198 лет.». Напомнила мне вот эту
«Девять женщин не родят ребенка за один месяц».
Вот напишешь без смайлика, и все всерьёз воспринимают.
Девять женщин не родят ребенка даже за 100 лет. Нужен еще мужик.
Достаточен просто материал.
но за 9 месяцев они смогут родить 9-рых.
Собственно ожидаемо, от этого и засада на собеседованиях. После вопроса — «Что такое красивый\хороший код?», пытаешься угадать мысли и внутренний мир собеседника, реагируя на мимику.
Угадывать? Но зачем?
Это ведь не экзамен по предмету, о котором впервые услышал накануне сдачи.
Ох! Как же отлично прослеживается зависимость между возрастом (опытом) человека и его понимаем проблемы. Старожилы ведут речи о высоком, о внешнем виде, о приятном чтении исходников, а в глазах тоска и усталость от многочасового чтения говнокода. Молодняк же давит на практическую сторону, на конечный продукт и скорее оправдывается, чем ищет истину.
А есть ли она, истина, единая и неоспоримая для всех и каждого, единое мерило, способное удовлетворить любого?
Еще бы пример сорцов от каждого участника — что они считают красивым кодом?
Или еще лучше: вот захотел я красоты, в каких проектах мне её подсмотреть? Книгу «Чистый код. Создание, анализ и рефакторинг» Роберта К. Мартина — знаю. А еще?
Философия UNIX? Не код, но фундамент точно
+1, согласен с вами. Разговоров много, интересных и познавательных, а вот кода нет, ни в статье, ни в комментах. Было бы здорово подискутировать, предложить разные варианты.
Вот мое понимание красивого кода:
красивый код должен неожиданно и приятно удивлять своего автора своей гибкостью, когда идет процесс его модификации. А также радовать своей безотказностью при применении в сложных и новых ситуациях.
Я считаю красивым тот код, который является наиболее простым для решения конкретной задачи. Простым с точки зрения как программиста, так и компьютера.
К этому выводу я пришел следующим путем: думаю никто не будет спорить с утверждением, что красота кода понятие относительное. Если учесть, что в коде можно сделать только два вида изменений — в лучшую или в худшую сторону — то любое изменение программист будет считать улучшением кода (ведь никто сознательно не станет портить свой код, это возможно только от незнания альтернатив). Следовательно для данного программиста код будет красив тогда, когда в нем невозможно будет больше делать изменения в лучшую (по знаниям программиста) сторону, а этому требованию может отвечать только простой код (в сложном коде больше мест для изменений).
Залез в философию )
Zalina
1) Сложно не отметить шикарное начало ролика! Именно таким должно быть введение в программерскую тематику. Понятно про что ролик. При этом ни одного лишнего слова. И все это из уст очаровательной юной девушки!
2) Также хочется услышать мнения программеров Вашей компании по поводу сред разработки. К примеру в видео мелькали VIM(было бы здорово посмотреть на конфиг к нему) и IDEA.
1. Спасибо! Не буду рассказывать, какой это дубль :)
2. Да, мы сами тоже думали, что стоит затронуть эту тему. Возможно, в ближайших роликах порассуждаем и на неё.

Хороший код это предсказуемый код. Который читаешь и уже примерно предполагаешь где и что лежит дальше.Имеет он при этом комментарии и как форматирован неважно. Главное его можно легко понять исправить и продолжить.
Если Вы пишите комментарий, то может следует подумать что комментарий который вы пишете это на самом деле имя новой функции?
Нумерация строк в виме снизу вверх — это экстравагантно!
(1:18)
Там нумерация относительна позиции курсора (опция relativenumber). Т.к. курсор находится внизу, у Вас создалось впечатление, что она снизу вверх. Выглядит это так:

А для чего надо? Можете привести user-story когда это помогает и действительно необходимо?
Не нужно считать строки для команд вида 5k
Действительно необходимо — вряд ли, удобно — однозначно.
Например, вы хотите удалить N следующих строк. Вы можете выполнить dd и клацать точку N-1 раз, а можно набрать Ndd. Если использовать обычную нумерацию, то Вам придется вычислять N (так, я нахожусь на 13-й строке, хочу удалить до 27, тааааак...). Относительная нумерация сразу показывает Вам N.
А Visual Mode в таком случае разве не удобнее?
Дело вкуса.

В случае с относительными номерами, это, как минимум быстрее.
Вы видите строку до которой хотите удалить (или другое действие), смотрите на номер рядом с ней (например 8) и набираете 8dd — 3 нажатия.

В случае с визуальным режимом будет что-то типа Vjjjjjjjd.

И вообще, я ничего не пропагандирую — я просто объяснил почему у работника Яндекса такая нумерация и для чего она может быть нужна.
Небось вы еще и goto используете в своем коде? -_- (шучу)
В Vim реже всего используется именно VM
Delphinum и truezemez Спасибо за разъяснение, а то пока на этапе тренировки рук для VIM еще не перешел )))
Попробуйте воспользоваться Vimperator (если вы с firefox) и процесс перехода станет приятнее ;)
Порадовали ответы г-на Бакунова. Кстати, сейчас стартанул новый курс по алгоритмам на курсере (https://class.coursera.org/algs4partI-004). И первая цитата из лекции была:

«Bad programmers worry about the code. Good programmers worry about data structures and their relationships.» (с) Linus Torvalds

Без обид Яндекс! Вашу курсы ШАД тоже просто отличные! :)
А вот еще такой вопрос, тем кто находит красоту в коде, а может ли он быть с блоками try catch, утверждениями (assert) и с условиями проверки валидности? То есть со всем, что страхует программистов и пользователей от ошибок.
UFO just landed and posted this here
UFO just landed and posted this here
А что плохого в функциональном, но одновременно красивом устройстве?
UFO just landed and posted this here
Должен ли быть красивым леопард? Или болид Формулы-1? Для функциональности красота, вроде бы, не нужна. Но по мере улучшения характеристик устройство становится всё более совершенным, и в конечном итоге это совершенство воспринимается нами, как красота.
UFO just landed and posted this here
Ну, раз уж Вы акцентируете внимание на этом пункте…
Когда Вы спрашивали, «должен ли быть красивым токарный станок или телескоп», то не уточняли, для кого он должен быть красивым. Следовательно, неявно предполагалось некое понятие «красивости», не зависящее от субъекта. Иначе вопрос был бы — «должен ли станок или телескоп быть красивым именно для меня?». Так что выбирайте — либо существует «группа ценителей», для которой работает понятие «красиво вообще», либо каждый раз указывайте — для кого конкретно некое нечто должно быть красивым.
Должен ли токарный станок быть красивым для разработчика? Для покупателя? Для токаря? Для инспектора токарных цехов? Для посетителя музея, где этот станок окажется в итоге? И что в данном контексте значит «должен»? Может быть красивым, может не быть. Окажется некрасивым — будет какой-то штраф (в широком смысле). Где грань между «неплохо бы» и «должен»?
"- Эти ягоды можно есть? — Можно. Только отравишься." (с)
UFO just landed and posted this here
Так Андрей Плахов и говорит мне, что это похоже на вопрос о том, должен ли быть красивым дом — не обязан, но было бы хорошо. Это довольно глубокий вопрос обо всем тогда. Должен ли быть красивым смартфон? Должны ли быть красивыми автомобили? Должна ли быть красивой посуда на кухне? Кажется, необязательно, но очень приятно пользоваться такой. Людям нравятся вещи с хорошим дизайном. Вы какой телескоп при прочих равных возьмете? С хорошим дизайном или обычный?
UFO just landed and posted this here
UFO just landed and posted this here
Однозначно должен быть! Очень неприятно смотреть на всего лишь поржавевший станок, который хоть и работает, а на поржавевший телескоп вообще с опаской смотришь… глядишь, прям на месте и рассыплется.
UFO just landed and posted this here
Золотая оправа и инкрустация самоцветами для инструмента скорее не «красиво», а «аляповато».
Хотя некоторым может и нравиться.
UFO just landed and posted this here
Ох, уж эти сказошники… :)
«Сделайте нам красиво...»

Пока не заминусовали, открою страшную тайну. Имеются ГОСТ 28195-89 Оценка качества программных средств. Общие положения и ГОСТ 28806-90 Качество программных средств. Термины и определения, в которых кривовато, но исчерпывающе расписаны все «красивости» программного кода. Так что тема изначально высосана из пальца, эти 2 стандарта многократно перекрывают все без исключения комментарии.

А еще есть автоматное программирование, позволяющее писать совершенно прозрачный код, читабельный даже без комментариев и начинающий работать практически без отладки. Спасибо проф. Б.П. Кузнецову! А для малолеток есть вот это — Автоматное программирование для начинающих

Теперь минусуйте.

Ну так сколько лет этому ГОСТу-то!
Типичная отговорка — «типа все ГОСТы устарели». Наитипичнейшая, поскольку, как правило, другие аргументы не приводятся :)

Вы их внимательно почитайте, а потом скажете, много ли изменилось на текущий момент и что в этих ГОСТах неправильно. Но предупреждаю сразу: ГОСТ — это не водевиль, читается достаточно тяжело, язык очень формальный.

А понятие «красивость программного средства (кода)» Вы нигде не найдете — гарантирую :)
Есть одна проблема в текущем техническом образовании. Мало акцентируют у студентов внимание на термины. Читая статьи и комментарии, можно наткнуться на то, что большое количество хаброюзеров использует термины абсолютно не вдумываясь в их значение. «Принцип» вместо «способ» или «архитектура» вместо «структура» — легко и просто. А без этой основы, правильно понять ГОСТ, на мой взгляд — невозможно.

Поэтому, сколько бы вы ни писали про ГОСТ, многие вас, просто, не поймут.
Почти все опыт программирования ~25 лет… Уважуха мужикам!!! :)
Для меня красивый код, это тот в код, в котором очень быстро разберется твой коллега.
Понимаемость программного средства (understandability) по ГОСТ 28806-90

Совокупность свойств программного средства, характеризующая затраты усилий пользователя на понимание логической концепции этого программного средства. Примечание — Под логической концепцией подразумеваются основополагающие понятия, принципы и соглашения, придающие системе правил работы пользователя с программным средством согласованный и обоснованный характер и позволяющие логически точно определять конкретное назначение и содержание этих правил [из п. 3.1 Прил. 2 ГОСТ 28806-90]

Вот как-то так, только применительно не к пользователю, а к кодировщику. Меняем пользователя на коллегу и получаем определение «красивости» кода :)
Если вчитаться в определение, то так оно и есть :)
А всего лишь какой-то «безнадежно устаревший» ГОСТ… :) На любой вопрос всегда найдется ответ, а эта пурга из комментариев юных дарований совершенно пуста. Сейчас совсем заминусуют, карму понизят…

Как я люблю ГОСты… Прекрасный инструмент, позволяющий прижать к ногтю оппонента любого ранга, довести до истерики любого «эксперта», выиграть бешеный конкурс и, наконец, СНЯТЬ С СЕБЯ ЛЮБУЮ ОТВЕТСТВЕННОСТЬ :)

Только Вы меня понимаете, SowingSadness :) Все остальные — ПЛОХИЕ :)

И напоследок:

Удобство использования программного средства (usability) по ГОСТ 28806-90

Совокупность свойств программного средства, характеризующая усилия, необходимые для его использования, и индивидуальную оценку результатов его использования заданным или подразумеваемым кругом пользователей программного средства [из п. 15 разд. 2 ГОСТ 28806-90]
Я думал, что Орлов сейчас попросит провести исследование с помощью МРТ :)
Как видно, совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять.
Антуан де Сент-Экзюпери.

ps. английский вариант применительно к коду, правда больше подходит:
It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.
а чего они через одного «Р» не выговаривают?
После вашей реплики вспоминается Жванецкий:

О чем может спорить человек, который не поменял паспорт? Какие взгляды на архитектуру может высказать мужчина без прописки?

И вообще, разве нас может интересовать мнение человека лысого, с таким носом? Пусть сначала исправит нос, отрастит волосы, а потом и выскажется.
А это вот возможно именно тот случай, про который и говорил Гулин. Код из Интернета, в котором пытаются разобраться программисты Яндекса.

Меня теперь мучает другой вопрос — разработчики в Яндексе оставляют комментарии в коде на английском или на русском?
Хочется верить, что подобное не уходит в релиз. Хотя, сам факт возникновения этого поста свидетельствует о том, что Яндекс дошел в своем развитии до необходимости решения таких проблем. И это радует.

Расстраивает другое — когда инженер обосновывает решения своим чувственным восприятием мира, то это значит, что он не знает, как технически правильно решить задачу.

комментарии в коде на английском или на русском?

IMHO Ключевые слова, константы, переменные… — на «английском», тогда логично, что и комментарии на том же языке. Иначе будут ненужные сложности перевода для неминуемо связанного «embedded language» в комментариях. Да, и неоднократно доказано, что правильно написанные комментарии на английском будут короче, обеспечивая тот же объем информации.

IMHO Ключевые слова, константы, переменные… — на «английском», тогда логично, что и комментарии на том же языке. Иначе будут ненужные сложности перевода для неминуемо связанного «embedded language» в комментариях. Да, и неоднократно доказано, что правильно написанные комментарии на английском будут короче, обеспечивая тот же объем информации.


Ну и на мой взгляд комментарии на английском удобней по ряду причин (не надо менять раскладку, при редактировании кода по SSH нет запарок с кодировкой и т.п.), просто интересно стало как в Яндексе обстоит. На работе меня в свое время «били по рукам», т.к. общепринятым было комментарии формировать на русском языке.
Расстраивает другое — когда инженер обосновывает решения своим чувственным восприятием мира, то это значит, что он не знает, как технически правильно решить задачу.

С точностью до наоборот.
Для того, что бы увидеть «красоту» либо «уродливость» определённого решения нужно иметь чёткие представления о том, как это должно быть сделано правильно и как делать не следует.

Там дальше «except mango returns all the hits in ExtractSnippetsHit» т.е. код не мёртвый.
Без разницы. Программа это идея воплощенная в исходном коде. Комментарий свидетельствует, что в коде воплощена «некрасивая» идея. Процесс разработки обязан уметь отслеживать наличие подобных проблем в коде для возможности их оценки и, возможно, исправления. Рассматриваемый комментарий серьезно затрудняет это. Именно поэтому он некрасивый.

«Красивый» коммерческий(!) код обязан быть прагматичным.

Например, этот комментарий мог бы быть таким:
// FixMe #100500
где #100500 это ссылка на запись в используемой системе отслеживания проблем.

Однако, если использовать «notepad» в качестве инструмента разработки, то такой вариант будет не очень удобен. Поэтому, «красота» кода не может рассматриваться вне контекста проекта, процесса разработки и в отрыве от используемых инструментов.

Что-то я не понял:
Владимир Иванов
В Яндексе — 22 года.

вики:
1997 — запущена поисковая система «Яндекс» в компании CompTek
2000 — основана компания «Яндекс»

как так?
Начал работать программистом Яндекса за несколько лет до старта собственно Яндекса. В 1992 году из того, что было, собрал в локальную сеть пять компьютеров — ночью, из любопытства. Когда Яндекс выделили в отдельную компанию, перешёл в неё заниматься сетью и долгое время руководил всеми NOC.


в статье вроде как черным по-белому, или Вы только видео смотрели :)?
Я только видео посмотрел. Спасибо, нашёл в тексте, где я ошибся.
Но эта компания ведь с чего-то выросла… часто бывает так что сначала что-то делают, а потом оформляют под это дело фирму, придумывают звучащее название и т.д.
Меня пока что поразило как это люди столько лет програмят? на вид всем от 25 до 35.
Например, Анатолий anatolix Орлов, 25 лет программинга, а возраст Анатолия 34 года. Что-то тут не сходится. Хотя, если называть программированием пробы на первых синклерах в бейсике писать что-то типа let a = b + 5, тогда всё логически сходится.
А вам было бы интересно слушать 34 летнего Анатолия, который программирует 4 года?
Я не об этом. Опытного человека очень интересно слушать. Я сам начал изучать азы программирования ещё с 6 летнего возраста и пытался писать на ассемблере в 14 лет, но тем не менее, не могу назвать это программированием. И называю программированием именно профессиональную деятельность. Хотелось бы уточнить эту логическую загадку.
Я тоже не об этом ) я вас сразу понял. Думаю авторы просто захотели добавить авторитета выступающим.
Есть проекты, где год за два считается.
Думаете они из этого исходили при указании стажа?
Думаю, что цифры нужно читать, как «гуру» фирмы. И эти ребята были выбраны авторами публикации, чтобы представить годами наработанное мнение 6000-ного коллектива по профессиональному вопросу, который важен для любого программиста.
На самом деле, я просто спрашивала участников видео, со скольки лет они программируют, и дала возможность самим решать, какой момент они могут обозначить как «я начал программировать». Признаюсь, я склоняла и искушала внести в счет даже первый калкулятор :) И кто-то назвал этот момент, а кто-то — тот, когда написал более серьезную программу. Андрей Гулин, например, вспомнил, что программировать начинал еще в уме, потому что компьютера не было.
Как-то подленько-подленько и трусливо тут все. Кто-то снижает карму и т.п. — хочется дать ему в рожу — а нет возможности… Анонимоус, однако. Понятно, когда банит админ — это адресно и есть кому предъявить претензии. А тут… Быдлофорум очередной. Жаль только, что даже доктора наук на это купились. Разумные, казалось бы, люди. Не нашли себе адекватного ресурса.

Напоследок — нате! Государственные стандарты в информационных технологиях (ИТ). Часть I — почему мы не любим ГОСТы и что нам за это будет?

ЗЫ. И ссылки не работают. Кому интересно — сами найдете по ключевым словам.
Не нервничайте, это вредно. Как для местной кармы, так и для кармы вообще.

Слили вас, скорее всего, не за содержание ваших предыдущих комментариев, а за их форму. Не любят здесь шибко дерзких, высказывающихся в виде «вы все пи**расы, а я — д'Артаньян».
Не царское это дело — нервничать :) Генералам прикажем — это их задача :)

Форма — фантик, не так ли? Любят джуниоры фантики.

За формой не видят сути. Подмена понятий. Господь им судья. И мне что — расстраиваться из-за этого? Вот уж нет уж.
Sign up to leave a comment.