Автор статьи, перевод которой мы сегодня публикуем, говорит, что команда, в которой он трудится, воодушевилась рассказом TechLead’a о 7 привычках высокоэффективных программистов. Члены команды решили высказать собственные мысли по этому вопросу. Здесь, в форме советов, приведён разбор 7 навыков эффективных программистов.
1. Учитесь читать чужой код
Все кроме вас пишут ужасный код. Именно поэтому способность программиста работать с чужим кодом — это ценный навык. Этот навык даёт тому, кто им обладает, много хорошего.
Программисту необходимо уметь разбираться в чужом коде. В конце концов, это — его работа. При этом неважно то, насколько запутанным выглядит подобный код, или то, как плохо он написан. «Чужим кодом», кстати, может быть то, что было написано самим программистом, скажем, год назад.
Этот навык положительно влияет на программиста двумя способами. Во-первых, способность к чтению чужого кода даёт возможность понять то, как устроен некачественный код. Просматривая чужие работы, можно узнать о том, какие приёмы являются рабочими, а какие — нет. Во-вторых, что более важно, это помогает выявить особенности восприятия чужого кода другими людьми, выяснить, какой код воспринимается легко, а какой — тяжело.
Если вы читаете чужой код и встречаете в нём что-то такое, что вам не нравится, постарайтесь не молчать об этом. Это поднимет ваш авторитет в глазах сослуживцев.
Обращайте внимание тех, с кем вы работаете, на то, как важно писать код, который легко поддерживать, на то, как важны хорошие комментарии. Это ещё сильнее упрочит ваш статус в команде.
Ваш собственный код должен быть спроектирован настолько качественно, чтобы он был бы понятным и без документации. На самом деле, у хороших программистов не возникает нужды в документировании кода. Это — пустая трата времени, того времени, которое лучше было бы потратить на программирование и на проведение совещаний.
Способность понимать некачественный код, кроме прочего, помогает во внесении изменений в подобный код. Иногда это означает редактирование кода, в котором некто разбирается не очень хорошо. Например, однажды нам попался скрипт, в ходе работы которого были задействованы такие технологии, как PowerShell, Python и Perl. В Perl мы разбирались не очень хорошо. Однако нам удалось достаточно глубоко разобраться в проекте, удалось понять сущность происходящего и внести в код необходимые изменения. Это стало возможным благодаря тому, что мы поняли тот код, который нам нужно было изменить, включая и код Perl-скриптов.
Умение разбираться в чужом коде повышает ценность программиста из-за того, что он может понимать то, как устроены даже переусложнённые системы, такие, при взгляде на которые у кого-нибудь другого попросту опускаются руки.
2. Развивайте в себе чутьё на неудачные проекты
Существует множество навыков, на овладение которыми нужно время. Один из них, который, мы уверены, стоит освоить, заключается в том, чтобы развить в себе понимание того, какими проектами заниматься не стоит, и того, какие проекты с высокой долей вероятности могут вылиться в «гонку на выживание».
В больших компаниях всегда имеется множество проектов, над которыми трудятся программисты. Но далеко не все эти проекты будут завершены. Далеко не все из них принесут пользу. Среди них могут быть и такие, которые не имеют коммерческого смысла (по крайней мере — для программиста). Некоторые проекты, в целом — перспективные, могут страдать от недостатков управленческого характера. Это не значит, что вы должны отказываться от неких идей сразу же после того, как поняли, что вы не согласны с теми, кто их предлагает. Однако если автор идеи не может внятно объяснить то, какую пользу компании может принести проект после его завершения, тогда, возможно, такой проект не стоит и начинать.
Кроме того, некоторые проекты могут быть чрезмерно ориентированы на технологии, а не на решение некоей проблемы. Это иногда, ещё в самом начале работы, позволяет понять, что завершение подобного проекта не принесёт особенной пользы.
Для того чтобы научиться с первого взгляда распознавать бесперспективные проекты, нужно принять участие во множестве подобных проектов. Поэтому, если вы находитесь на начальном этапе карьеры программиста — не тратьте слишком много времени на попытки оценки перспективы всех достающихся вам проектов. Со временем у вас выработается внутреннее чутьё, руководствуясь которым вы сможете быстро распознавать проекты, обречённые на неудачу.
3. Избегайте совещаний
Кем бы вы ни работали, без совещаний вам не обойтись. Это касается абсолютно всех. Дело в том, что вам нужно находить общий язык с менеджерами проектов, пользователями, клиентами. Однако у совещаний есть одна неприятная особенность: иногда они внезапно занимают едва ли не весь рабочий день. Именно поэтому очень важно научиться избегать ненужных совещаний. Пожалуй, лучше будет не «избегать совещаний», а стремиться к тому, чтобы «контролировать время, которое уходит на совещания». Цель этого заключается в том, чтобы тратить время только на те совещания, которые действительно необходимы, на такие, которые способствуют развитию проектов.
Самый распространённый метод управления временем, которое уходит на совещания, заключается в том, что ежедневно выделяется двухчасовой блок, который превращается в непрерывное совещание. Многие назначают повторяющиеся совещания на время, которое они считают наиболее подходящим. Эти совещания используются для обсуждения рабочих вопросов.
Ещё один способ управления временем — приходить на работу раньше других для того, чтобы успеть справиться со своими делами. Мы, например, предпочитаем поступать именно так. И, кстати, если в офис прийти пораньше — работать там будет гораздо спокойнее чем обычно. Большинство людей, приходящих пораньше, похожи друг на друга. Они это делают для того, чтобы успеть справиться со своей работой. Поэтому они не мешают работать другим.
В нашем случае это важно для отдельных членов команды. Дело в том, что наша работа требует времени на то, чтобы полностью сосредоточиться на некоей задаче. В это время мы ни с кем не общаемся. Конечно, бывают ситуации, когда для решения задачи нужно с кем-то её обсудить, поработать совместно. Но после того как все вопросы разрешены, разработчику нужно лишь писать код. В общем-то, речь идёт о попадании в некую зону комфорта, в которой программист может постоянно держать в голове всё то, что связано с решаемой им задачей. Если его постоянно прерывают, у него могут возникнуть сложности с быстрым возвратом к тому, на чём его отвлекли.
4. Освойте GitHub
Когда смотришь на некоторых высококлассных программистов, то возникает ощущение, что они начали пользоваться GitHub в первый же день своей жизни. Они понимают смысл каждой команды и параметра, они без труда справляются со своими делами.
А вот другие впервые сталкиваются с GitHub на первой работе. Для них GitHub — это настоящий ад, построенный из непонятных команд и таинственных процессов. Они никогда не уверены полностью в правильности того, что делают. Именно поэтому весьма популярны всяческие «шпаргалки» по GitHub.
Вышесказанное справедливо для любой системы контроля версий. Если ей пользоваться правильно — она оказывает весьма полезной. Если пользоваться ей неправильно — она страшно мешает работать. Простой PR или коммит легко может превратиться в кошмар, который отнимет у программиста несколько часов. Это время уйдёт на распутывание хитросплетений веток и форков. Кроме того, если регулярно забывать о загрузке на свою машину самой свежей версии репозитория, можно постоянно заниматься решением конфликтов слияния. Ничего хорошего в этом нет.
Если вам нужна «шпаргалка» по GitHub — сделайте её.
Научитесь продуктивно работать с GitHub. При этом неважно то, как именно вы этого добьётесь.
5. Пишите простой код, который легко поддерживать
Некоторые начинающие программисты имеют следующую черту: они пытаются, в одном проекте, реализовать всё, что знают. Дело тут в том, что они стремятся использовать в каждом фрагменте создаваемого ими кода свои знания об объектно-ориентированном программировании, о структурах данных, о паттернах проектирования и о новых технологиях. Это неоправданно усложняет код из-за того, что при таком подходе на решаемую программистом задачу легко могут повлиять, например, те паттерны проектирования, которые он уже реализовывал на практике.
Существует баланс между слишком сложными структурами проектов и простым кодом. Паттерны проектирования и объектно-ориентированное программирование нацелены на то, чтобы упрощать код в крупномасштабных проектах. Однако чем больше мы прибегаем к абстрагированию и инкапсуляции, чем больше в наших решениях «чёрных ящиков» — тем сложнее отлаживать код таких решений.
6. Научитесь говорить «нет» и расставлять приоритеты
Эту рекомендацию, на самом деле, можно дать кому угодно — хоть финансовому аналитику, хоть программисту. Но можно отметить, что возникает такое ощущение, что все хотят чего-то особенного именно от технических специалистов. Например, если вы — инженер по анализу данных, то вам, возможно, предлагают задачи, которые оказываются гораздо шире того, чем, как предполагается, вы должны заниматься. Одним командам нужны какие-то выборки из данных, другим нужны сводные данные, третьим — новые конвейеры.
Надо отметить, что способность расставлять приоритеты и умение говорить «нет», на самом деле, может представлять собой два отдельных навыка. Однако эти навыки очень близко друг с другом связаны. Там, где возникает необходимость в одном из них, обычно нужен и второй. Расстановка приоритетов — это когда время тратят только на то, что оказывает серьёзное влияние на компанию. А умение говорить «нет» — это отказ от выполнения работы, которую должен выполнять кто-то другой.
Научиться тому, о чём мы говорим, может быть непросто, так как люди часто стремятся к тому, чтобы решить каждую задачу, которую перед ними ставят. Особенно это характерно для тех, кто только что отучился и получил свою первую работу. Раньше, на учёбе, им давали задания, с которыми они вполне справлялись. Теперь же, на работе, они ожидают того же и стремятся к тому, чтобы никого не разочаровать.
Тут надо понимать, что в больших компаниях существует бесконечное количество задач. Самое важное — это браться только за те задачи, которые можно решить.
Существует множество навыков, на владение которыми не тестируют на собеседовании. Их редко можно получить на учёбе. Часто такая ситуация складывается лишь из-за особенностей учебной среды, а не из-за того, что кто-то не хочет показывать учащимся настоящие задачи, с которыми они могут столкнуться в реальности.
7. Научитесь думать о том, как именно будет использоваться ваша разработка
Есть один навык, на владение которым сложно организовать проверку в ходе собеседования. Ситуации, в которых он нужен, тяжело воспроизвести во время учёбы. Речь идёт об умении видеть ошибки, которые может совершить конечный пользователь программной системы. Мы обычно называем это «продумыванием сценариев использования программы».
На самом деле, это «продумывание сценариев» — лишь достаточно мягкое название того, что называется «защитой от дурака».
Например, так как большая часть работы программиста заключается в поддержке кода, ему часто приходится менять код, который тесно связан с чем-то другим. Даже простое изменение чего-либо требует поиска всех тех мест, где это используется. Например, меняться может объект, метод, API некоей системы. Если внести в систему непродуманное изменение — это может «поломать» работу совершенно неожиданных частей программы. Причём, речь идёт об изменениях любого масштаба — даже о чём-то вроде смены типа в базе данных.
Этот навык также включает в себя умение находить и анализировать пограничные ситуации, которые могут возникнуть при работе с системой. Сюда же идёт и способность осмысления высокоуровневой схемы решения на этапе проектирования.
Это относится и к разработке более крупных частей систем, таких, как модули или микросервисы. Приступая к решению подобных задач нужно подумать о том, как именно будут использоваться сущности, которые планируется создать. Нужно поразмыслить о сценариях их неправильного использования, о различных вариантах их использования, и о том, что тем, что вы создаёте, возможно, будут пользоваться совершенно неочевидными на первый взгляд способами.
Сам процесс написания кода — это лишь часть работы по решению некоей задачи. Нетрудно создать программу, которая хорошо работает на вашем компьютере. Но код, с которым работает кто-то другой, легко может вести себя совсем не так, как изначально ожидалось. Как код, который вы пишете, будет использоваться в продакшне? С какими системами ему придётся взаимодействовать? Частью каких процессов он может стать? Не покажется ли он слишком примитивным и ограниченным программисту, которому придётся поддерживать его через несколько лет? Это — очень непростые вопросы.
Итоги
В этом материале мы представили вашему вниманию обзор 7 навыков, которые характерны для высокоэффективных программистов. Надеемся, вы нашли среди них те, которые вам захочется развить и у себя.
Уважаемые читатели! Что вы посоветовали бы освоить тому, кто стремится к профессионализму в программировании?
Комментарии (78)
AHDPEu
25.06.2019 12:44Если вы читаете чужой код и встречаете в нём что-то такое, что вам не нравится, постарайтесь не молчать об этом. Это поднимет ваш авторитет в глазах сослуживцев.
— Вы все говно! (с)
Всегда думал, что сначала стоит узнать — почему выбрано такое решение. Предложить своё, обсудить возможные вариант.a-tk
25.06.2019 13:28Авторитет зависит не только от факта обсуждения чужого кода, но и от тона, с которыми это делалось и ещё от множества не технических факторов.
i86com
25.06.2019 15:16Мне вот следующий абзац ещё больше понравился.
Обращайте внимание тех, с кем вы работаете, на то, как важно писать код, который легко поддерживать, на то, как важны хорошие комментарии. Это ещё сильнее упрочит ваш статус в команде.
Оно вроде как бы и не враньё — статус оно таки упрочит. Вот только вам этот статус не понравится, скорее всего.
Самое мягкое, что вы услышите от программиста в ответ на претензии к недостатку хороших комментариев в его коде — «ну так возьми и напиши».
То же самое про поддержку — чаще всего есть причины, по которым некоторый код тяжело поддерживать. Например, потому что система мгновенных транзакций делалась из системы заявок, которая делалась на основе чата, который делался на основе форума (которым проект был N лет назад). И автор этих переделок вас, конечно, выслушает, но вряд ли согласится с предположением о том, что все проблемы от недостатка планирования наперёд.
GavriKos
25.06.2019 13:17+7Когда уже все эти советчики научатся отличать GitHub от git.
sumanai
25.06.2019 23:15+5И частную программу Git от систем контроля версий.
CrzyDocTI
26.06.2019 11:00-1GavriKos
26.06.2019 11:39+1Да. Вы не понимаете отличия конкретной реализации системы контроля версий, от целой категории такого софта.
Учить надо не столько гит, сколько в целом системы контроля версий. Чтобы небыло попаболи когда приходите в новую контору, а там вместо гита пластик или меркуриал.CrzyDocTI
26.06.2019 11:58-1Тогда будьте добры — напишите название для
системы контроля версий
используемой Git, если Git — это только название конкретного приложения.
Я вот читаю(https://en.wikipedia.org/wiki/Git#cite_note-linusGoogleTalk-11):
These criteria eliminated every then-extant version-control system, so immediately after the 2.6.12-rc2 Linux kernel development release, Torvalds set out to write his own
GavriKos
26.06.2019 12:08+1Где вы в моем ответе увидели слово «приложение»?
Разжую чутка. Есть такое понятие — «система контроля версий». Их есть много реализаций — svn, git, mercurial, plastic, TFS. Git — конкретная реализация этого понятия. Которая имеет общие черты с другими реализациями — так же как и автомобили имеют общие черты, несмотря на конкретные реализации.
Так вот. Лучше всего учить и понимать как работает абстрактная система контроля версий. А потом уже спроецировать эти знания на конкретную реализацию. Грубо говоря — вы учитесь ездить на автомобиле, а не на конкретной модели. И еще грубо говоря — в резюме вы сможете написать «умею работать с системами контроля версий», а не конкретно с гитом. Который вообще не панацея.CrzyDocTI
26.06.2019 12:29-1Да вы, мсье, хамло. И, видимо, ответить не сможете.
А чтобы не быть голословным по поводу хамства:
1) В компьютерном сленге часто используется слово софт, произошедшее от английского слова «software», которое в этом смысле впервые применил в статье журнала American Mathematical Monthly математик из Принстонского университета Джон Тьюки в 1958 году.
Wiki
2) «software» переводится как «программное обеспечение»
3) Прикладное ПО — программа, предназначенная для выполнения определённых задач и рассчитанная на непосредственное взаимодействие с пользователем. В большинстве операционных систем прикладные программы не могут обращаться к ресурсам компьютера напрямую, а взаимодействуют с оборудованием и другими программами посредством операционной системы
GCU
26.06.2019 12:09-1Шутка была в том, что github это не только Git, а целая инфраструктура.
Кстати checkout оттуда можно сделать и при помощи SVN, хотя это другая система контроля версий.
В частности git это лишь одна из систем контроля версий.
P.S. А ещё git это контент-адресуемое по SHA-1 хранилище объектовCrzyDocTI
26.06.2019 12:16+1Так я ничего и не говорил про github. Меня, как человека пару месяцев занимающегося изучением вопросов CI/CD очень заинтересовало отличие «частной программы» от «системы контроля версий».
GCU
26.06.2019 12:00Вы не в тренде :)
Сейчас модно тупо лоббировать переход на Git вместо изучения других систем контроля версий, даже если они уже вполне успешно используются.
P.S. Оригинальной статье сарказм не чужд
Acuna
26.06.2019 18:03Понятно что они путают теплое с мягким, но в защиту хочу сказать что в плане Git Гитхабу альтернативы по сути нет, ибо Гуглокод уже ридонли официально, остальные проекты полумертвые, а с тем же Гитлабом лично у меня как-то не сложилось, не знаю, какой-то он не такой, я хотел на него пересесть, ибо люблю альтернативы, но как-то не зашло, поэтому в мире Git это уже стало нарицательным по сути, как ксерокс или джип, уже же никто не говорит, мол, да когда уже эти обыватели научатся отличать копир от ксерокса?)
sumanai
26.06.2019 18:07Bitbucket?
Acuna
26.06.2019 18:16Ни одного проекта на нем не встречал, каким бы крутым бы он ни был. Возможно изначально Гитхаб был популярнее, и разрабы не видят смысла поддерживать несколько проектов в разных системах одновременно. Я просто констатирую факт, что есть — то есть.
GavriKos
26.06.2019 22:50По проектам — Unity держит всякое-разное на битбакете.
По популярности — да, гитхаб более раскручен.
Про поддержку проектов — ерунда. Сделать пуш не в один remote а в два требует ровным счетом ничего.
По факту — битбакет и гитлаб круты тем, что их можно поставить на локальные сервера. В первую очередь.
Ну а так да, сравнение с ксероксом — прям в точку.Acuna
27.06.2019 15:18Сделать пуш не в один remote а в два требует ровным счетом ничего.
Возможно, просто та же IDEA вроде как может только в одну SVC коммитить за раз. Во всяком случае насколько я знаю. У меня только GitHub, поэтому его подключил и лью все на него, может и в несколько можно…
По факту — битбакет и гитлаб круты тем, что их можно поставить на локальные сервера.
Это да, это да, тут спорить не буду, самому очень не хватает своего Гитхаба, люблю все хранить у себя. Пока в виде компромисса храню все в приватных репозиториях, надеясь что однажды они не станут публичными :/ Утешаю себя что для Гитхаба это могут быть многомиллиардные потери, ибо в Штатах очень любят получать компенсации за моральный ущерб, поэтому всяко думаю у них все в порядке с этим, а взломать можно все, было бы желание.sumanai
27.06.2019 18:06Возможно, просто та же IDEA вроде как может только в одну SVC коммитить за раз.
В VSCode это 3 дополнительных нажатия правой кнопкой мыши.
Skerrigan
28.06.2019 05:15IDEA вроде как может только в одну SVC коммитить за раз. Во всяком случае насколько я знаю.
Да, я тоже за одну оправку могу запушить в один из репозиториев. Но повторить дело для другого репозитория — дел меньше чем на минуту.
Занудство QAтолько в одну SVC коммитить за раз
VCSAcuna
29.06.2019 13:56VCS
Ой, ну конечно, господи, как неловко-то, 10 лет разработки и такая ошибка) Редко просто эту аббревиатуру использую…
Skerrigan
27.06.2019 06:06Все наши проекты (фирмы, где я работаю) на битбакете. Другое дело, что проекты «закрытые». Но они есть, кода очень много.
*сугубо свои «домашние, R&D» держу сразу и на гитхабе, и на битбакете. Но опять же, репозитории закрытый характер носят.
*да, локальный битбакет был одним из плюсов
Daemonis
25.06.2019 14:04Как стать высокоэффективным программистом (если верить статье) — приходи пораньше, хреначь, не отвлекаясь, и не забывай пушить :)
GCU
25.06.2019 14:16+1Сам процесс написания кода — это лишь часть работы по решению некоей задачи. Нетрудно создать программу, которая хорошо работает на вашем компьютере. Но код, с которым работает кто-то другой, легко может вести себя совсем не так, как изначально ожидалось. Как код, который вы пишете, будет использоваться в продакшне? С какими системами ему придётся взаимодействовать? Частью каких процессов он может стать? Не покажется ли он слишком примитивным и ограниченным программисту, которому придётся поддерживать его через несколько лет? Это — очень непростые вопросы.
Вопрос откуда взялись вопросы, если в оригинале их не было :)
Simply coding and programming is only part of the problem. It’s easy to create software that works well on your computer. But there are a lot of ways deploying code can go wrong. Once in production, it’s hard to say how code will be used and what other code will be attached to your original code. Five years from now, a future programmer might get frustrated at the limitations of your code.
vassabi
25.06.2019 14:16Пишите простой код, который легко поддерживать
Или как шутил наш техлид: «Подходит ко мне заказчик, смотрит мне в глаза и спрашивает: Ребята, просто скажите — сколько? (драматическая пауза) я все пойму, просто скажите — сколько? (еще одна драматическая пауза с заглядыванием в глаза) сколько стоит, чтобы вы писали код без багов ?»Yastreb1332
25.06.2019 14:49без багов не бывает.
alsii
25.06.2019 22:17+2"Если отладка — это процесс удаления ошибок из программы, тогда программирование — это процесс внесения их туда".
orion76
25.06.2019 16:31+1Помнится в ВУЗ-е самую первую лекцию по АиЯП лектор начал с фразы: Программирование без ошибок есть теоретическая абстракция. -)
rvs2016
26.06.2019 00:02Вопрос «сколько?» напомнил мне вопросы типа «когда?». Типа сколько времени на разработку? Когда программа будет готова? Вопросы начальства/заказчика вроде бы справедливые, но точно ответить бывает не всегда легко. Вот вопрос «за сколько секунд поднимешь мешок цемента на 3-й этаж» — всегда простой — ответ на него легко вычислить, а если даже не вычислить, то уж засечь время на примере. А «кагда завершишь программу?» — не для каждой программы ответ однозначен и точен.
GavriKos
26.06.2019 00:19coub.com/view/1s775f
Кстати полная лекция очень даже ничего. Анекдот про обезьяну и бильярдный шар можно цитировать при каждом старте нового проекта.
hd_keeper
26.06.2019 10:01Без багов — это ему в NASA надо.
shaggyone
25.06.2019 14:36+35. Пишите простой код, который легко поддерживать
Уважаемый филин, а есть у вас тактические рекомендации, как мышкам стать ёжиками?GCU
25.06.2019 15:01В оригинальной статье тэг «Юмор» — это дело привычки :)
Высокоэффективные программисты так привыкли.
Можно ещё написать что высокоэффективные программисты имеют привычку высокоэффективно программировать o_O
sbnur
25.06.2019 14:56Ужасный перевод — давайте читать в оригинале, и его обсуждать.
GCU
25.06.2019 15:17Можно тогда уж и на оригинале обсуждать.
Причём даже комментарии аналогичны:
GitHub is not Git.
Not including any documentation is horrible advice.
This article is a joke, right?!
Причём с ответом автора что да — это статья-шутка
Вообще это мысль — к переводу статьи вставлять переводы комментариев :)
vav180480_2
25.06.2019 15:02Ваш собственный код должен быть спроектирован настолько качественно, чтобы он был бы понятным и без документации. На самом деле, у хороших программистов не возникает нужды в документировании кода. Это — пустая трата времени, того времени, которое лучше было бы потратить на программирование и на проведение совещаний.
Сколько еще будут писать вот эту глупость, это я как имеющий большой стаж по SQL(PL/SQL) спрашиваю. В одной компании где это же обсуждали (писать или не писать комменты) я выдал код на 4 строчки в SQL который решал очень стандартную задачу, которая часто встречалась всем, но никто так и не догадался что он делает. По факту если у вас не какой нибудь декларативный язык, сам код отвечает на вопрос КАК (это видно), а не на вопрос ЧТО (это ниразу не очевидно).GCU
25.06.2019 15:09Это был «юмор», в оригинале сарказм был выделен зелёным, но при переводе выделение потеряли, как и это:
Everyone but you writes terrible code.
Все кроме вас пишут ужасный код.
sumanai
25.06.2019 23:18По факту если у вас не какой нибудь декларативный язык
SQL — декларативный язык программирования
vav180480_2
26.06.2019 06:52-1SQL — декларативный язык программирования
ммм не совсем… лично мне он напоминает цикл for/foreach вывернутый на изнанку… как тесто в сосиске:) Просто те кто привык работать с модельками ООП не совсем понимают что кроме извлечения данных у SQL есть куча возможностей их обработки, запросы на пяток страниц (с рекурсивом и аналитическими функциями:)) для ораклистов это норма.nitrat665
26.06.2019 13:54Декларативный — декларативный. Другой вопрос в том, чтобы с ним хорошо работать, надо еще иметь хотя бы среднее понимание того, что творится под капотом. Например, те же рекурсивные и аналитические функции мы в нем все-таки декларируем, а вот как их база внутри реализовывает — это лучше знать, чтобы не понаписать тормознутого говна.
AlePil
25.06.2019 15:29оригинал пропитан сарказмом, который, к сожалению, не так явно виден в переводе.
amaksr
25.06.2019 16:32«чутьё на неудачные проекты» — это типа чтобы боссу сказать, что «мне проект не нравится, и я над ним работать не буду»? Ну-ну. Гораздо полезнее тогда чутье на неудачные команды или компании.
«приходить на работу раньше других для того, чтобы успеть справиться со своими делами» — если уходить тоже пораньше, то тогда нормально, но повод боссам задуматься что что-то организовано не так, если сотрудники не имеют возможности эффективно работать в стандартные часы.
«Научитесь говорить «нет»» — я всегда считал, что программист, как солдат, должен работать над тем, что скажет начальник. Начальнику нельзя сказать нет, но нужно донести до него мое экспертное мнение, и возможно он примет другое решение. Если задание идет от параллельной команды, то пусть обращаются через начальника, он заодно и назначит приоритет. Иначе начинается переработка и стресс.Alexey_Sobolev
26.06.2019 04:40+2Даже солдат не должен выполнять прямо уж любой приказ, тем более программист. По моему имеется в виду, что начальнику надо уметь объяснить что он хочет хрень и что потом эта хрень будет хреново работать.
sumanai
26.06.2019 18:07Только начальники обычно это не сильно любят. А уж менеджеры объяснять клиентам и подавно.
Alexey_Sobolev
27.06.2019 08:49Получать по голове от своего начальника начальники тоже не любят, поэтому адекватные начальники все таки прислушиваются к мнению специалистов
Skerrigan
26.06.2019 08:07не имеют возможности эффективно работать в стандартные часы
Ну, ради объективности, не всегда есть какая-то в этом проблема. Даже на примере самого себя могу сказать, что иногда есть банальное желание прийти «с зарей», пройдясь по пустым улицам и обдумать в такой «романтичной» прогулке план работ на день. А бывает хочется банально выспаться.
По мне так максимально гибкое расписание — ощутимый плюс работ\команды.
P.S. Всегда на связи — если есть необходимость, со своей стороны так же готов проявить гибкость :)
Exponent
25.06.2019 18:23Неплохие советы, но, как известно, проэкты не проваливаются из-за программистов, а из-за плохого руководства проектами. Вот из-за плохого руководства пишется говнокод, который потом не то чтоб понять, прочесть невозможно. Переписать его тоже практически невозможно, т.к. все переплетено и находится в продакшене. Тестов естественно нет никаких. Поэтому надо хорошо продумывать архитектуру перед написанием кода и не давать никому из «талантов» ее нарушать. Для этого можно использовать code-review подход чтобы изменения контролировались и следовали задуманной архитектуре.
dizel3d
26.06.2019 00:52+1Обращайте внимание тех, с кем вы работаете, на то, как важно писать код, который легко поддерживать, на то, как важны хорошие комментарии.
На самом деле, у хороших программистов не возникает нужды в документировании кода. Это — пустая трата времени, того времени, которое лучше было бы потратить на программирование и на проведение совещаний.
Избегайте совещанийtbl
26.06.2019 01:16Такое ощущение, что статью писал тролль ради флейма: ошибки + взаимоисключающие параграфы
vcooking
26.06.2019 02:31Так автор же говорит, что комментарии должны писать другие, а он — Д'Артаньян
Magister-Ice
26.06.2019 09:59«3. Избегайте совещаний» — очень сомнительный пункт. Он может работать только тогда, когда команда очень маленькая. Когда команда состоит и более чем 5-ти человек, есть необходимость регулярного обмена состояниями (например: чтобы не искать решения уже решенных проблем, чтобы код у команды имел единую архитектуру, чтобы быть в курсе изменения требований и т. д.).
«4. Освойте GitHub» — реклама GitHub'а? Я слышал что на этом ресурсе банят за прямую рекламу! Но если имеется в виду любая система контроля версий (о чем говорится в описании пункта), то совет не плохой (но в этом случае пункт должен называтья «4. Освойте систему контроля версий»).
«6. Научитесь говорить «нет»» — такой совет многие начинающие разработчики могу понять неправильно и в дальшейм сильно недоумевать почему у них проблемы на работе (или уже на бывшей работе). Возможность сказать «нет» есть далеко не всегде, не везде и не у всех. А если ты начинающий разработчик, то лучше всего научится всегда говорить «да».
Gorthauer87
26.06.2019 10:50- Совещание это не про обмен опыта, а обмен состояния это дейлики по 15-20 минут, они много времени не жрут. А вот когда кучу дней подряд идут совещания по три часа, где из 5 человек только двое в теме, а остальные слушают и пытаются ухватить контекст это не обмен опыта а трата времени и сил. Особенно весело в какой-то момент вначале потерять контекст а потом еще 2 часа с умным видом хлопать глазами.
- Насчет сказать нет ведь не имеется в виду послать начальство, а высказать свое мнение, почему так нельзя.
RikoSaGe
26.06.2019 10:39Статью писал точно не программист. Ставлю, что это ПМ, который таким нехитрым образом поднимает эффективность своей команды, заставляя гребцов работать с раннего утра. В топку.
dipsy
26.06.2019 12:23~~~ T.D.D. ~~~
Просто надо понять, что написание программы в любом достаточно большом и долгом проекте (практически все, которые существуют в объективной реальности) или делается через TDD или покрывается мерзкими и неожиданными багами и медленно в муках умирает на руках обессиливших и потерявших всякую надежду вдохнуть жизнь в эту кучу сочащейся всеми жидкостями плоти программистов. Третьего варианта нет.
Это как строить дом вслепую, просто завязываем глаза и начинаем класть кирпичи, всё же просто. Даже какие-то приемы у людей появляются, как ловчее кирпичи эти класть, паттерны там всякие, бросаются всё это изучать, применять, называют себяпрограммистамистроителями. А надо в первую очередь контролировать получающийся результат, контролировать отсутствие его деградации от разных возмущений, обратная связь нужна, как для любой системы, от которой нам надо получить некое устойчивое состояние.
serbod
26.06.2019 14:36Однажды я попросил очень опытного водителя научить меня правильно водить машину. А он говорит:
— Едь как в автошколе учили, не нарушай правила.
— Ну это понятно. А как быстро разгоняться и проходить повороты, как выходить из заноса?
— Если будешь ехать по правилам, то не будет разгонов и заносов. И с машиной меньше хлопот.
— А если…
— Если скучно нормально ездить — иди с парашютом прыгай.
Ну, вот я отмотал мильон километров и написал мильон строк кода. Да, все так. Чем спокойнее едешь, тем меньше износ (машины и организма), тем больше можешь проехать. Больше внимания уделяется маршруту, цели поездки. Чем аккуратнее пишешь код (с говорящими именами, соблюдением стиля и правил безопасности), тем легче его читать и дорабатывать, тем больше кода и крупнее проекты можно поддерживать. То есть, код сам по себе перестает быть проблемой, можно сосредоточиться на решаемых задачах, взаимосвязях, архитектуре.
barbanel
Orange11Sky
И поменьше впечатляться статьями, подобной этой.