Личностные черты самых замечательных разработчиков

55 комментариев
Личностные черты самых замечательных разработчиков

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

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

Почему лучшие разработчики неисправимые пессимисты, а также прочие их «фичи»

Например, давно ли приходилось какому-нибудь разработчику последней версии Halo потратить целых три недели, чтобы собрать кучу людей из бухгалтерии, отдела маркетинга, продукт-менеджеров и сотрудников колл-центра, чтобы окончательно разобраться с требованиями, которые все равно изменятся уже через пару месяцев после релиза программы?

А когда кому-нибудь с 37Signals доводилось неделями просиживать спина к спине в ходе JAD-сессий?

В моем мире корпоративного программирования я познакомился с некоторыми феноменальными разработчиками. Я говорю о тех ребятах, выкладывающихся на 5 с плюсом, которым хочется посоветовать бросить эту работу и скорее основать свою собственную компанию. И чем больше я задумывался, отчего же они так хороши, тем яснее замечал у них пару общих черт. Ну, честно говоря, не пару, а где-то четыре.

Пессимизм

Адмирал Джим Стокдейл был самым высокопоставленным американским военачальником, попавшим в плен во Вьетнаме. Его держали в тюрьме «Ханой-Хилтон» и многократно пытали на протяжении 8 лет. Однажды Стокдейл сказал Джиму Коллинзу, автору книги «Good to Great», следующие слова: «Никогда не следует путать веру в то, что в конце концов ты победишь (потерять эту веру смерти подобно) с жесткой дисциплиной, которая помогает сносить самые адские проявления бытия, какими бы они ни были». После освобождения Стокдейл стал первым трехзвездным офицером в истории ВМФ США, носившим одновременно и Крылья авиатора, и Медаль Почета.

Стокдейл был пессимистом в краткосрочной перспективе, так как существовал в нечеловеческих условиях, но в долгосрочной перспективе оставался оптимистом, продолжая верить в то, что выдержит все испытания.

Никто не сможет предвидеть катастрофического отказа системы, обращая внимание лишь на положительные ее аспекты. Лучшие разработчики, которых я знаю, отлично умеют находить места потенциальных отказов. Иногда, если им намекнуть о том, что может понадобиться обработать передачу критически важных данных по FTP, и это по диал-апу среди ночи, они не удержатся и спросят: «А что у нас плохого?». Самые лучшие разработчики предвидят такие проблемы, о которых другие даже не задумываются, и делают все возможное, чтобы избежать таких проблем.

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

Нетерпимость к неаккуратному коду

Пол Грэм очень точно подметил эту черту, сказав: «Оказывается, люди, хорошо разбирающиеся в чем-то, не столько убеждены в собственном величии, сколько озадачены некомпетентностью окружающих». Для классного разработчика нет хуже кошмара, чем наблюдать, как чья-то программа бьется в конвульсиях, обрушивая при этом всю остальную систему. Это приводит их в бешенство. И такие проблемы не ограничиваются кодом; дело может быть в плохих установочных пакетах, неаккуратном развертывании либо в ошибочно записанном названии столбца.

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

Примечательно, как работают их программы. Они не валятся. Их не требуется перезагружать. Никаких багов. Это настолько совершенные программы, какие только может создать человеческое существо. Просто статистика: в каждой из последних трех версий программы — каждая длиной по 420 000 строк кода — было найдено всего по одной ошибке. В последних 11 версиях этой программы в сумме обнаружено 17 ошибок. В коммерческих программах сопоставимой сложности встречается примерно по 5000 ошибок».

Я не утверждаю, что любая разработка требует такой высокой планки, но в NASA действительно умеют находить и исправлять ошибки, и делается это одним и тем же способом: отыскивается причина каждой проблемы.

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

Разработчики, не находящие на это времени, часто выдают неаккуратные решения. Сотни подобных перлов вы найдете на этом сайте. Вот некоторые из таких примеров, встречавшиеся в моей практике:

  • cборка удаляется с сервера после каждой его перезагрузки. Можно написать специальный скрипт, который бы копировал эту сборку на сервер после перезагрузки, либо выяснить, почему именно удаляется сборка;
  • скрипт для операций с изображениями выжирает процессорные ресурсы на протяжении целых минут, тогда как его работа должна занимать менее 10 секунд. Можно запустить этот скрипт в два часа ночи, когда никто этого не заметит, либо потратить время, перелопатить код и найти причину проблемы;   
  • разделяемый XML-файл блокируется процессом, а когда другие процессы пытаются его открыть, они также аварийно завершаются. Можно сделать достаточное количество копий этого XML-файла — по одной для каждого процесса;
  • и т.д., и т.д…


Долговременные планы

Эта черта оставалась для меня загадкой дольше всего, но полагаю, я наконец-то могу сформулировать, в чем ее смысл.

Люди, продумывающие свою жизнь на много лет вперед, обладают даром не менее полно планировать процесс разработки программы. Умение видеть последствия решений, принимаемых сегодня, — ключевой фактор при создании программ, которые будут работать завтра. У самых лучших разработчиков, которых я знаю, хорошо сложилась семейная жизнь, есть накопления на старость, свое жилье. Еще они правильно питаются. Те люди, которые никак не могут наладить свой быт, а также живут от получки до получки, тоже могут быть неплохими программистами, но в офисе им не хватает того же, чего и в жизни: дисциплинированности, а также умения строить долгосрочные планы и строго их придерживаться.

Внимание к деталям

Я знаю очень умных разработчиков, которым не хватает внимания к деталям. У них-то и встречаются орфографические ошибки в названиях столбцов баз данных, код без комментариев, проекты, выполненные без контроля версий, программы, не знавшие модульного тестирования, нереализованные фичи. Все это не представляет проблем, если вы пишете гугловский мэшап или пятистраничный сайт. Но в корпоративной разработке любой из этих недостатков смерти подобен.

Поэтому сейчас сделаю громкое заявление, но обещаю не повторяться:

Никогда, никогда в жизни не встречал выдающихся и при этом небрежных разработчиков.

Еще в колледже работал я с одним программистом, у которого было железное правило: и он, и все его коллеги должны были делать отступ при помощи двух нажатий пробела, а не при помощи табуляции. Если ему давали код с табуляцией, он просматривал его строка за строкой и заменял всю табуляцию на пробелы. Хотя этот пунктик действительно яйца выеденного не стоил (я не раз сам подтрунивал над парнем по этому поводу), такое внимание к мелочам весьма пригодилось ему, когда он не один год занимался разработкой микросхем в Intel.

Итак, мысль понятна

В следующий раз, когда будете собеседовать нового соискателя, проверьте, обладает ли он теми четырьмя чертами, которые я перечислил. Вот о чем бы я его спросил:

  • Вы оптимист или пессимист?
  • Расскажите о случае, когда вам удалось не только решить техническую проблему, но и найти ее источник.
  • Делаете ли вы сбережения? (этот вопрос можно задать, рассказывая о пенсионной программе, действующей у вас на предприятии)
  • Предложите короткий фрагмент кода с явными орфографическими ошибками и спросите, видит ли кандидат какие-то неточности.

Из книги «Facts and Fallacies of Software Engineering» известно, что наилучшие программисты работают примерно в 28 раз лучше самых посредственных. Поэтому в софтверной индустрии, как нигде, кадры решают всё.

Роб Уоллинг

Источник
 

Хотите сообщить важную новость?

Пишите в наш Телеграм

Горячие события

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»
4 июня

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»

JSNation 2020 Amsterdam
3 июня — 5 июня

JSNation 2020 Amsterdam

Amsterdam
Бесплатные творческие лаборатории в ИТ-школе Адукар
3 июня — 7 июня

Бесплатные творческие лаборатории в ИТ-школе Адукар

Минск

Читайте также

Как защитить видеозвонки. Советы экспертов
Как защитить видеозвонки. Советы экспертов

Как защитить видеозвонки. Советы экспертов

За месяц число ежедневных активных пользователей сервиса для видеосвязи Zoom выросло в 1,5 раза — с 200 млн до 300 млн, хотя ещё в декабре их было лишь 10 млн. По мере роста популярности приложение стало привлекать хакеров, а в сети появилось столько новостей об уязвимостях Zoom, что на мессенджер обратило внимание ФБР. Издание Computerworld собрало небольшой список рекомендаций от экспертов по кибербезопасности о том, как защитить данные и участников видеоконференций от взломов, утечек и непрошенных гостей.
Guardian: массовые мероприятия как топливо для эпидемии
Guardian: массовые мероприятия как топливо для эпидемии

Guardian: массовые мероприятия как топливо для эпидемии

Коллективная статья семи журналистов Guardian о том, почему массовые скопления, рукопожатия, поцелуи и общие напитки виноваты в распространении коронавируса. Публикуем перевод материала с незначительными сокращениями.
1 комментарий
10 образовательных приложений, чтобы провести самоизоляцию с пользой
10 образовательных приложений, чтобы провести самоизоляцию с пользой

10 образовательных приложений, чтобы провести самоизоляцию с пользой

Перевели подборку бесплатных приложений для удалённого обучения. для тех, кто устал от доомашнего спорта, документалок и сериалов.
3 комментария
Как локдаун помог интернету
Как локдаун помог интернету

Как локдаун помог интернету

MIT Technology Review объяснили, почему резкий рост трафика не «сломал» сеть, а привёл к серьёзным качественным улучшениям.

Обсуждение

2

> Еще в колледже работал я с одним программистом, у которого было железное правило: и он, и все его коллеги должны были делать отступ при помощи двух нажатий пробела, а не при помощи табуляции. Если ему давали код с табуляцией, он просматривал его строка за строкой и заменял всю табуляцию на пробелы.
Это не программист. Настоящий программист должен быть достаточно ленив, чтобы один раз написать соответствующий инструмент и потом применять его для удовлетворения собственных странных желаний.

-2

такой инструмент уже есть - это Vim, а в сферическом вакууме это сделает sed.

Андрей Митин
Андрей Митин System analyst в CTDEV
0

Вы как-то слишком хорошо думаете о людях, если предполагаете, что единственная беда тех исходников была в наличии табов вместо пробелов. Надо быть пессимистичней. ;-) Наверняка присутствовали и погрешности в отступах, и другие неприятные вещи (с точки зрения дотошного программиста), поэтому в общем случае требовалась не просто замена \t на два пробела, а всеразличные разумные правки форматирования. Автоматизация потребовала бы создания (или поиска) серьезного тула. Возможно, человек не каждый день занимался таким code review, поэтому посчитал нецелесообразным заморачиваться тулом, ну а сам-то писал всегда правильно (с его т.з.).

amok
amok Team Lead в Ergalio
0

Опять же это проблема тула. Нормальный редактор кода может поправить отступы и заменить пробелы/табы. "Крутой" программист может стоить $300 в час. Это бред, если он занимается форматированием.

0

А с какого года появились эти самые "нормальные редакторы"?

0

Emacs - 1976
Vi (Vim) - 1976-1979
Достаточно давно, чтобы приобщиться ;)

0

и с тех пыльных годов они умеют форматировать текст исходного кода на любом языке программирования в соответствии с заданными пользователем правилами?

0

Для очень многих было и есть. Как-никак, Vim даже сейчас самый популярный редактор, не говоря уже про старые времена. + Обладают отличной расширяемостью/кастомизацией. А к чему вопрос? Они вам не по вкусу? Я не навязываю.

0

я просто не могу найти это функционал никак
как плагин называется?

0

Плагин называется унылый троллинг. Неинтересно и неконструктивно. За сим откланяюсь.

5

вот всегда так с теми, кто предлагает использовать vim/emacs, ни подсказки ни совета

0

Для людей с С-бэкграундом (у вас как я вижу С++) и желающим попробовать emacs я могу порекомендовать начать http://david.rothlis.net/emacs/howtolearn.html
С Vim я знаком на уровне "быстро поправить конфиги" поэтому сходу не посоветую.
Для emacs скажу, что вникать надо долго, поэтому поначалу просто юзать как дефолтный блокнот и постепенно осваиваться. Помнить, что не вы подстраиваетесь под него, а он под вас. Сила emacs в возможности расширить, дописать под себя, если вам это не надо, то врядли ваше время окупится - лучше подучить более легкий редактор.

0

Раз уж мы решили перейти на личности и смотреть профайлы собеседника, то наверное можно обратится к такой незыблемой сфере знаний, как собственный опыт.
Уже лет этак 10 как я научился выходить из vim с сохранением и без сохранения изменений (как-бы он не был беспощаден). Но к сожалению получить для vim / emacs хоть сколько-нибудь адекватный автоматический-рефакторинг из-коробки (вот как eclipse для Java хераксь ctrl+shift+d) у меня не вышло. И поэтому интересно, какие есть решения для этого (из-коробки), боюсь писать свой лексический-синтаксический парсер у меня нет желания.

2

Дело не в туле и не в пробелах вообще. Этим было лишь подчеркнуто, что человек был внимателен к мелочам. Это - очень ценный признак, тут я полностью согласен с автором.
> такое внимание к мелочам весьма пригодилось ему, когда он не один год занимался разработкой микросхем в Intel.
А вот в этой отрасли уже совсем другие редакторы, отладчики и симуляторы. Свое дело они делают хорошо, но по дружественности к пользователю они отстают лет так на двадцать от знакомых нам IDE.

10

Нельзя делать инструменты, которые поощряют небрежность. А так он давил на вашу совесть. Печально, когда команда играет в лебедя, щуку и рака, вместо того чтобы сесть и договориться делать одинаково.

1

> Нельзя делать инструменты, которые поощряют небрежность
Это инструменты, обеспечивающие единые подходы независимо от причин, вызывающих разнобой.
А палить время работодателя на собственный перфекционизм... да, мы все умеем и любим это делать, но не так часто хвастаемся с документальным подтверждением :)

1

Ладно пробелы, а если он скобочки начнёт переставлять, вы готовы пожертвовать историей коммитов? Гордиев узел нужно рубить сразу, никакого личного перфекционизма.
А то пробелы плавно перетекают в скобки, затем в архитектурные решения, переделываемые за коллегами, затем идеи, что нужно переписать всё с нуля. Свой мнение нужно проявлять лишь на этапе обсуждения или код ревью, после того как код приняли, нужно уступать командному большинству. "Архитекторы" на проекте ещё хуже говнокодеров.

0

По-моему, мы оба сходимся во мнении, что тот чувак ни разу не крутой программист :)

0

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

0

А еще круче, если "звезда" будет работать в команде :) Интересно, как в этом плане существуют команды, куда набирают исключительно крутых спецов? Нет ли там мордобоя?

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

0

Мордобоя нет, договариваемся. Тренируется очень важный скилл - увидеть недостатки в собственном решении.

-1

Ха, чё-то мне подумалось... Товарищ-из-статьи пробелы расставлял вручную - для него это было важно + не было подходящего инструмента под рукой (чтобы не вручную). А вы об истории коммитов пишете - видимо для вас это важно + нету подходящего инструмента (чтобы подредактировать)

Но ведь что тот товарищ, что вы... как-то идейно я разницы не вижу :)

0

Ну, раз вы не видите разницы, значит вы мне не товарищ. Разница не идейная, а практическая. Вы теряете автора и контекст.

0

Это была ирония.

3

Вопрос пробелов и скобочек решен сто лет назад с изобретением Coding Style. И таки-да, коммит имеет право на существование, если он приводит код в соответствие с принятым Coding Style.

0

Вот-вот, вся команда должна придерживаться единого стиля, без учёта гениальности отдельных личностей.
Но вот коммиты фиксящие стиль не всегда уместны, особенно со скобочками, которые могут добавить в дифф 2 строки и изменить авторство, отвязать код от таска в системе и т.д. Всё зависит от проекта и количества разработчиков. Я, как правило, в легаси коде стиль не меняю, хотя это делается одной строкой в консоли.

0

Главное - чтоб код был читабельным, понятным, чтоб его легко было понимать и изменять. Просто чаще всего это предполагает следование (полное или частичное) какому-либо стилю. А тупо следование единому стилю ради следования - имхо, не надо.

2

Философская мысль. Если фикс стиля или добавление комментов вы (мы, они) не можете сделать, потому что у вас (нас, их) ломается инфа о коммите - может быть что-то не так с вашими (нашими, ихними) инструментами?

0

Блин, вы так рассуждаете, как будто в каменном веке живём и всё делаем ручками. Есть CI, есть определённый список метрик для обеспечения качества, среди которых проверка CS. Фейл CS, фейл билда, фейл таска. Работа это не турецкий рынок чтобы торговаться и не реалити шоу, чтобы демонстрировать свою удаль. Если человек не может привыкнуть расставлять скобки как все, то нарушать правила он будет и в других местах.

0

А может вместо философии и написания своего VCS стоит просто делать свою работу и решать проблемы проекта, а не проблемы своих сексуальных предпочтений.

Вы Итре не используете CI и CS? Это не велосипед, это нормальная практика, зачем придумывать геморрой, если можно подцепить готовый инструментарий для автоматизации и заниматься делом.

0

Я живу в мире реальных исходников, а не розовых пони. Каким образом заставить человека расставлять скобки "как все", если ему допустим так неудобно? Я лично не вижу смысла спорить по таким вопросам, они реально не так важны. CI - Continuous integration? Что такое CS?

0

В реально мире это и делается с помощью правил cs - code style
https://github.com/squizlabs/PHP_CodeSniffer
Вешаете правило в CI и никаких холиваров, благо инструменты и стандартные есть для любых языков

0

"PHP_CodeSniffer tokenises PHP, JavaScript and CSS files and detects violations of a defined set of coding standards". 1) В мире бывают еще другие исходники кроме PHP/JS/CSS. 2) Ну и что, что он "detects"? Дальше-то что?

0

Эммм.... а что я должен ответить? Слазить в гугл и дать ссылки на аналогичную тулзу для всех языков программирования? Я же сразу написал про другие языки. Или научить вас пользоваться CI, бороться с ошибками стиля, копипастом, уменьшать цикломатическую сложность, писать тесты, использовать фиче бранчи, работать с тасками в джире???

0

Вы какой-то агрессивный товарищ. Я вам про философию и высшие материи, вы мне про секс с велосипедами.

0

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

0

Что ответить? Рабочее решение, а не какой-то частный случай, абы что-то ответить.

0

Согласен, в контексте практического применения моя мысль вообще ни о чем. Есть конкретные решения (вы их указали), кто-то их применяет, кто-то нет.

Например, мы у себя в php-команде используем некоторое компромиссное решение - PSR + сниффер, встроенный в PHPStorm + в некоторых случаях код ревью и "воспитание коллективом". Пока все здраво, негативных тенденций нет. Если появятся признаки бардака - зайдем на http://phpqatools.org/, прикрутим метрики и прочие тулы. Пока что смысла в них нет.

Так вот про философию (которая пока что глупость)... Любая свеже-новая идея рождается на почве критики вещей, которые критиковать многим здравомыслящим людям и в голову бы не пришло. Я, конечно, не гений и вполне допускаю, что сказал чушь (я даже почти уверен в этом), но порой к абсурдным вещам стоит прислушаться. Естественно, в нерабочее время, не на продакшене и исключительно в целях продвижения отрасли вперед-вверх.

-1

Был предложен конкретный продукт для решения подобной задачи. Найти другие, думаю, не составит особого труда.
А Вы хотите рабочее решение сразу для всего и вся? По-моему где-то тут пробежал розовый пони;)

1

"Если ему давали код с табуляцией, он просматривал его строка за строкой и заменял всю табуляцию на пробелы."
Любой прапорщик догадался бы что надо переформатировать не самому - а заставить это делать подчиненных!!

-1

Если чувак страдает аутизмом, он не только правкой управляющих последовательностей может сидеть и заниматься.

-1

это действительно черты корпоративных хороших разработчиков.
в более мелких задачах такой перфекционизм и фанатизм только вредит делу)

6

Однажды, когда я только начинал, один опытный программист рассказал мне секрет: самыми "успешными программистами" становятся те, кто умеет правильно объяснить, что вокруг них тупые люди. Спустя много лет я должен признать, что человек этот был чертовски прав.
Для того чтобы стать хорошим программистом вам не нужно лучше всех писать писать код. Вам нужно объяснять в чём ошибки окружающих. При таком раскладе во-первых вы никогда сами не ошибаетесь, так как мало что делаете. Во-вторых, вы показываете начальнику, какие вокруг собрались глупые люди. В-третьих, вам просто некогда делать что-то полезное, так как вокруг вас собрались одни идиоты и у вас едва хватает времени на тыкание их носом исправление всех их ошибок. В-четвёртых это великолепно согласуется с принципом построения иерархий в человеческих коллективах - вам не нужно больше всех работать, вам нужно отбирать у тех, кто работает. Те, кто работает, слишком заняты работой, чтобы быть готовыми к отражению атак. Вы же сможете оттачивать своё мастерство на новых и новых разработчиках (текучка будет однозначно, но ведь это и очевидно, в компании-же высокие требования к программистам, а попадаются одни идиоты :-) )
В целом, если вы хотите пойти дальше, стать управленцем, вам нужно переключится с выявления ошибок в коде, на более общие темы.
Рассказывайте людям как они слишком плохо относятся, слишком много хотят, неправильно ведут себя. Не вовремя улыбаются или смеются. Носят не ту одежду. Читают не те книги. Иерархия строится на вменении неполноценности. Ваш фокус - не код, не продукт, не кастомер, не успех проекта. Ваш фокус - место в иерархии. Выбирайте компании с большими ветвистыми иерархиями и кучей ступенек "наверх". Переключайтесь на политическую борьбу.

0

> Рассказывайте людям как они слишком плохо относятся, слишком много хотят, неправильно ведут себя.
Вы хоть сами пробовали ? :-)
А может что-нибудь слышали про "управленцев", с которыми никто не хочет работать ?

2

Популярность зарабатывается разбрасыванием денег и левой пропагандой. Особенно в постсоветском обществе. Ведите свою деятельность внутри компании,"выбивайте" у капиталистов. Убеждайте людей что они жертвы и их эксплуатируют и обманывают. Людям нравятся такие мотивы. Быть жертвой всегда удобнее чем нести ответсвенность за себя и свои поступки.
"Радейте за коллетив": бильярдные столы, теннисные, велотренажёры, турники и проч, без чего невозможно наладить производственный процесс программистов. Используйте доступ к финансам на полную катушку - набирайте слабых товарищей(поект закроется, людей придётся рассовывать по другим командам, так что они не будут проблемой для вас, наоборот, у вас резюме красивое и много друзей, и никакой ответсвенности перед компанией), закупайте ненужную технику (столько новых друзей сразу среди продажников железа!). Для пущей "справедливости" - сливайте проекты на сторону.Работодатель ведь ваш враг, вы просто забираете вам по праву рождения принадлежащее право хорошо жить. Ваш работодатель хорошо живёт. Это потому что за ваш счёт, жирует, наглая капиталистическая морда. Ваши страдания - это всё из-за несправедливого работодателя.
Поскольку вы "справедливый делитель" "смелый требователь" "щедрый тратитель" и "профсоюзный лидер"с корпоративной зарплатой, вы станете очень популярны. В идеале попадите ещё работайте на каком-то non-billable проекте, чтобы вас кормили другие. Многие любят ребят, которые тратят деньги, зарабатывать сложнее.
Правда будьте готовы к тому, что в течении нескольких лет вам, как "поплуярному управленцу" нужно новое место работы, так как кормить популистов среди капиталистов дураков нет и ваш рост будет ограничен. Скоро вас охватит зависть от чужих успехов, конечно же вы в этом увидите "происки капиталистов" "недальновидные менеджмент" и тд. Придётся забирать с собой "эффектным жестом" гоп-команду низкоквалифицированных пивняков (вряд ли умные люди ведутся на левую пропаганду), уменьшать зарплатные ожидания и искать новую компанию-донора, приписывая себе чужие достижения, ведь "выбил у шефа корпоративные обеды в Фальконе" не вызывает экстаза у рекрутёров.
И это тоже путь, и так тоже можно "управлять". Детройт - могила таких управленцев. Они так искренне боролись за права рабочих, что заводам оказалось дешевле перенести заводы через пролив в Канаду.

0

Извините великодушно, но в вашем сценарии левыми идеями даже и близко не пахнет :) хотя, справедливости ради, вы правы -- Детройт погубили именно что профсоюзы, под лозунгом "отнять и поделить". Ну насколько я в курсе всей этой истории.

Одна беда... этот лозунг к левым идеям не имеет ровно никакого отношения вообще. Сюрприз, да?! :)

Кратко поясню. Одно время большевики использовали тактику "отнять и поделить", "экспроприация экспроприаторов" и тому подобное. Это был просто инструмент, в рамках большой стратегии, реализующей те самые левые идеи. И этот инструмент был использован, как соответствующий определенному историческому и политическому моменту. В рамках большой стратегии, повторюсь.

"Отнять и поделить" это не идея, не идеология, это просто некое действие. Инструмент. Как нож, которым можно хлеб резать, а можно и людей.

В качестве простого примера, для понимания сути -- Робин Гуд тоже использовал инструмент "отнять и поделить", и это ни разу не делало его левым, коммунистом, большевиком, марксистом или еще каким-нибудь там социалистом, простиосподи. Он и слов-то таких не знал.

Киношные "воры в законе" (а возможно и реальные, я тут не сильно в курсе) используют инструмент "отнять и поделить" (отнимают у барыг, кладут в общак, якобы делят среди братков в местах не столь отдаленных)... и это снова не делает их левыми, что очевидно любому вменяемому человеку :)

0

Признайтесь, вы читали Стэнли Бинга :) А если нет - то почитайте! :)

4

На мой взгляд, самое важное качество программиста - это желание понять "как это работает", это вопрос "почему", пытливость ума.
Придумал для себя "однокнопочный тест программиста". Суть его вот в чём.
Открываете бразер, ставите курсор в поле ввода URL, нажимаете одну кнопочку на клавиатуре, видете вывалившиеся подсказки, часть из которых прилетела с удалённого сервера и начинаете задавать вопросы "почему".
Почему когда мы нажимаем пластмасску с подписью "G", на экране появляется G. Как это работает. Почему не "K". Почему именно в этом окошке. За 10 минут вы узнаете что человек знает о электронике, микросхемах, прерываниях, шрифтах, локалях, программировании GUI, gpu, многозадачности, потоках, shared библиотеках, потом будет повод поговорить о том, как буковка "G" улетела в сторону серверов в интернете, при чём здесь ethernet, tcp/ip, DNS и зоны, http, ssl, базах данных, пауках в интернете, поисковых машинах, потом, обсуждая то, что прилетело в ответ, можно поговорить о синтаксическом и лексическом анализе, деревьях и алгоритмах, растровой и векторной графике. И это всё по нажатию одной кнопки. И поверхностно.
Само собой в "корпоративном секторе" всё намного проще. Проверяем что человек знает как сделать SQL SELECT и что такое XML. Для сеньоров - SQL JOIN и как замапить класс на таблицу. И - наперад, за грашыма у хайтак.

4

Я бы добавил еще одну черту - доводит свою работу до конца.

-3

Статья с душком, но для обсуждения сгодится.
Итак, как на мой взгляд, хороший программист ответил бы на предлагаемые вопросы:

> Вы оптимист или пессимист?
Дайте точное определение пессимизма и оптимизма.

> Расскажите о случае, когда вам удалось не только решить техническую проблему, но и найти ее источник.
Расскажите мне о своих существующих проблемах, и я скажу чем могу помочь.

> Делаете ли вы сбережения? (этот вопрос можно задать, рассказывая о пенсионной программе, действующей у вас на предприятии)

Это не имеет отношения к данному собеседованию. Это вы мне должны предоставить работу, а не я вам налоговую декларацию.

> Предложите короткий фрагмент кода с явными орфографическими ошибками и спросите, видит ли кандидат какие-то неточности.

Хорошо, но только здесь и сейчас и не более 20 минут. И никаких домашних заданий.

3

цитата не помню кого
"программист переходя дорогу с односторонним движением смотрит в обе стороны"

3

Я лично так и делаю )

-1

программер знает, что кроме правостороннего движения еще существует и левостороннее :)

0

Да нет, просто все, что возможно теоретически, то возможно и на практике. Так что посмотреть по сторонам на улице с односторонним движением - это что-то типа защитного программирования :)

4

не ну без пессимизма никуда точно

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже