Я не литературный критик, не научный рецензент, не лингвист, не литературовед, не психолог, но, всё же, читая огромное количество статей в Интернете, в частности, в Дзене, я сформировал вполне определённое мнение о том, что мне нравится и что не нравится в статьях и что меня в них особенно раздражает. Даже хотел написать глобальную статью на эту тему, но сегодня решил ограничиться разбором одной статьи с Яндекс.Практикума, которая, как мне кажется, показывает многие ошибки авторов подобных статей. Вот эта статья.
Начнём с заголовка. В таких заголовках мне, например, всегда режет глаз их категоричность: "8 фраз, от которых нужно отказаться программисту". Не "стоит отказаться", не "желательно отказаться", а "нужно отказаться". С подобными заголовками я сталкивался много раз. "Культурный человек никогда не скажет эти 10 фраз", "эти 10 фраз выдают в вас невежду", "успешный человек никогда не произносит эти слова" и т.д. и т.п. Эти заголовки - не точные цитаты, но вы наверняка видели нечто подобное много раз. Их объединяет стремление навязывать общие правила для всех с иногда скрытым, иногда и не очень скрытым оскорблением тех, кто эти правила не соблюдает. Т.е. получается, что если человек произносит/не произносит какие-то слова, выполняет/не выполняет какие-то действия, он сразу переходит в разряд невежд, некультурных людей, неудачников, ламеров и т.д. Читаешь подобный заголовок, и сразу мысль возникает: "А что, если человек не отказался от этих фраз, он программистом/культурным/успешным/образованным человеком считаться не может?" Как-то неприятно сразу становится, особенно, если ты частенько эти фразы произносил. Получается, что ты должен обесценить либо содержание статьи, либо себя. А если ты и так выполняешь все указанные требования, то и статья тебе особо не нужна... Поэтому лучше отказаться от подобных заголовков. В крайнем случае, можно их смягчить, сделать менее категоричными. По сути подобная категоричность - это выпячивание собственного эго, претензия на непререкаемый авторитет, часто ничем не подтверждённый. Вы как бы говорите: "Слушай сюда, уж я-то в этом разбираюсь, я уже там, куда тебе идти и идти". Не стоит выпячивать перед публикой своё интеллектуальное и/или моральное превосходство, особенно, если оно мнимое.
Второе, что не менее важно: в большинстве случаев, если только не прямое оскорбление или другая крайность, любые фразы уместны в тех или иных случаях. Настаивая на категоричности, вы сразу отсекаете все подобные случаи. Подумайте прежде чем писать подобное, всегда ли ваши суждения справедливы.
А теперь перейдём к конкретным фразам:
1. Я не знаю
Некоторые разработчики практически на любой вопрос отвечают: «Я не знаю». К такому человеку часто не хочется обращаться, потому что это всё равно ни к чему не приведёт. Обычно он отвечает долго, а когда всё-таки отвечает, то это «Я не знаю». Создаётся впечатление, что этот человек не знает вообще ничего. Но так не бывает.
Это уже похоже на юношеский максимализм. Давайте, всё-таки, обозначим разницу между тем, чтобы иногда употреблять такие слова и отвечать так на любой вопрос.
обычно такой ответ означает, что за вас должен ответить кто-то другой из команды. Получается, что вы не только перекладываете работу на коллег, но и не можете подсказать, кто именно из них мог бы помочь с конкретным вопросом
Давайте разбираться. Что значит "должен"? Вообще-то, каждый разработчик работает над своей задачей или, если угодно, над своей частью задачи. По большому счёту отвечать ему вообще никто не должен, это он должен разобраться в вопросе. Разумеется, в любом нормальном коллективе люди задают вопросы и стремятся помочь друг другу, но это вовсе не значит, что если ты не ответил на один из вопросов коллег по их задачам, этим самым ты перекладываешь свою работу на других. Нет, это, как раз задающий вопрос перекладывает часть своей работы на коллег. Ещё раз повторяю: это вполне нормальное явление. Если ты можешь потратить минуту своего времени на то, чтобы помочь коллеге решить задачу, над которой он один будет биться весь день, общая эффективность команды только вырастет. Кроме того: сегодня поможешь ты, завтра помогут тебе.
Другое дело, когда на решение чужой проблемы ты потратишь столько же времени, сколько и тот, кто просит о помощи. Тогда ты потратишь своё время, отрываясь от своих задач, а коллега будет в это время просто бездельничать, пока за него решают его задачу. Очень важно в таких случаях уметь оценивать свои возможности и понимать, когда твоя помощь пойдёт на пользу общему делу, а когда - во вред и поощрение чужой лени.
...но и не можете подсказать, кто именно из них мог бы помочь с конкретным вопросом
Совершенно абсурдный вывод. Как из фразы "я не знаю" следует то, что ты не можешь подсказать, кто из коллег мог бы помочь, если ты, допустим, говоришь: "Я не знаю, но знаю, кто в этом разбирается. Спроси у N"?
если у вас действительно нет ответа на вопрос, скажите, что не знаете, как ответить, но готовы узнать или разобраться и помочь найти решение. Добавьте, что готовы ответить на другие вопросы, если получится (и эти ответы должны быть действительно обдуманными).
Да сразу предложите сделать за него всю его работу, а его отправьте домой, пусть отдохнёт. Этим вы сразу покажете коллегам своё дружеское расположение и укрепите сплочённость команды!
Если вы знаете, что на вопрос может ответить коллега, предложите собеседнику обратиться к нему, а лучше сделайте это вместе.
А заодно по пути к нему пособирайте других коллег, вдруг им тоже будет интересно узнать ответ на вопрос, и припритесь к нему всем офисом, вот это будет team building!
2. Это невозможно
в современной разработке практически нет ничего абсолютно невозможного
Да неужели??? После этой фразы я сильно задумался, а работали ли авторы статьи хоть день разработчиками ПО. В разработке есть огромное задач, которые в принципе невозможно решить, причём по самым разным причинам: от логической противоречивости самой постановки задачи до банальной нехватки вычислительных ресурсов! И только очень далёкий от IT человек будет слепо верить в их практическую неисчерпаемость. Конечно, вам вряд ли будут давать неразрешимые задачи в вашей работе, но если такое, всё же, случится, то не просто можно, но и нужно сказать, что это невозможно, но при этом нужно также уметь объяснить на доступном языке, почему такое невозможно, иначе придётся рисовать 7 красных линий, 3 из которых зелёные, а потом объяснять, почему у вас это не получилось.
Рано или поздно найдётся специалист, который оспорит невозможность реализации какой-то задумки, и это может стоить работы тому, кто был излишне категоричен.
Что лучше сделать вместо этого: искать альтернативные подходы или решения.
Поиск альтернативных подходов, как раз, предполагает, что данный подход, вероятно практически невозможен. Ничто не мешает сказать, например: "То, что вы предлагаете, практически невозможно реализовать, но я могу предложить вам вместо этого то-то и то-то. Это вероятно, удовлетворит пользователей и гораздо проще в реализации". Программисту куда важней не учить фразы, которые нельзя произносить, а уметь рассчитывать свои силы и определять сроки выполнения задачи, хотя бы, примерно, а для этого надо чётко согласовывать ТЗ, проясняя любые непонятные, кажущиеся нелогичными или слишком затратными моменты. И делать это стоит не только на этапе согласования ТЗ, но и в ходе его выполнения, потому что в ходе выполнения задания может выясниться, что что-то, что вам казалось простым, оказалось куда сложнее, вы можете столкнуться с проблемами, о которых не подозревали раньше, или вдруг окажется, что вы не совсем чётко понимали задание, а когда дело дошло до реализации каких-то моментов, возникли новые вопросы. Все эти вещи лучше обсуждать сразу по мере их появления, иногда при этом приходится несколько корректировать задание. Всё это нормальные моменты в разработке. Куда хуже если вы взялись за выполнение непосильной задачи, протянули время, а к дедлайну выясняется, что у вас ещё конь не валялся. Вот это с куда большей вероятностью может стоить вам работы, потому что ни одна организация не станет терпеть сотрудников, которые её постоянно подводят!
3. Просто скажите мне, что делать
Почему не стоит говорить «Просто скажите мне, что делать»: специалист, который бездумно выполняет механическую работу, может допустить ошибки в логике или не заметить что-то неправильное в работе кода.
Я вас открою страшную тайну: допустить ошибки или не заметить что-то неправильное в работе кода может абсолютно любой специалист и даже не специалист, и даже не программист, а вообще любой человек. И программисты тут не исключения: они тоже ошибаются, и ошибаются довольно часто. И от того, что вы никогда не произнесёте фразу "Просто скажите мне, что делать", вы ошибаться не перестанете, уверяю вас! Пассивных людей, которые только и делают, что ждут, когда перед ними поставят задачу, действительно не очень любят в IT-компаниях, но вовсе не потому, что они могут допустить ошибки, а потому, что они малоэффективны. За ними всё время приходится бегать, следить, чтобы они не сидели без задания... В конце концов это может просто надоесть.
4. Вы неправы
Нам всем хочется казаться умнее, чем мы есть, даже если наш ум не вызывает сомнений у окружающих. И когда кто-то другой говорит что-то ошибочное, нас так и подмывает сказать «Вы неправы!» Искушение особенно велико, если это происходит на глазах у других, ведь так можно показать своё превосходство сразу всем.
...когда людям говорят, что они ошибаются, это фактически означает, что они бесполезны и им не следует даже пытаться что-то делать. Это может разрушить моральный дух в команде и настроить коллег против вас. Когда вы говорите другому человеку о его неправоте, это становится личным. Такое редко забывается, и из-за этого в будущем люди с меньшей вероятностью станут спрашивать вашего мнения.
Я решил процитировать этот бред целиком, потому что это такая "песня", из которой слова не выкинешь! Во-первых, с какой стати, если сказать человеку, что он неправ, этим можно показать своё превосходство сразу во всём? Человек неправ в каком-то определённом вопросе, вы ему сообщаете об этом... Как из этого следует, что вы его превосходите во всём? Где-то тут хоть какая-то логическая связка? Причин, по которым человек неправ, может быть сотни: не подумал как следует о том, что говорит, недостаточно компетентен в данном вопросе, да просто оговорился... Как из этого следует, что человек, который ему сообщает о его неправоте, превосходит его во всём? Кто-то хорошо разбирается в одних вопросах, кто-то - в других. Я могу быть неправым, если буду высказывать своё ничем не подкреплённое мнение об истории древнего мира, какой-нибудь гуманитарий может быть неправым, когда будет высказывать своё мнение о математике. В первом случае он меня может поправить, во втором - я его. Это вовсе не значит, что кто-то из нас кого-то превосходит во всём! И любой человек может ошибаться! Как простая констатация этого факта может быть таким смертным оскорблением? Как из этого следует, что люди, которые в чём-то неправы, бесполезны и им не следует даже пытаться что-то делать? Я, человек крайне обидчивый, перенесший кучу психологических травм в детстве, не вижу в этих словах ничего оскорбительного! Тебя же не называют идиотом, ни на что не способным болваном, ламером, даже на личности фактически не переходят. На что тут обижаться? Вообще предполагал, что в IT работают не кисейные барышни с кучей непроработанных психологических травм, готовых затаить смертную обиду на слова о том, что они неправы, а вполне себе взрослые, знающие себе цену люди. Впрочем, я уже высказывал сомнения, что люди, написавшие эту статью, работали хоть день в IT.
можно сказать, что в работе другого человека есть ошибка или его мнение ошибочно
А чем это, собственно, отличается от слов, что он неправ?
5. А на моём компьютере работает
Если код или программа не работает у других, но работает на компьютере разработчика, фраза «А на моём компьютере работает» не может быть ни оправданием, ни поводом оставить разработчика в покое и искать причину проблемы где-то ещё.
Разумеется, не может, но она может, например, быть поводом сообщить о достаточно серьёзной проблеме, требующей глубокого анализа и тестирования на разных компьютерах.
делая такое заявление, вы перекладываете ответственность за доказательство наличия проблемы на группу тестирования или того, кто сообщил о неисправности кода. Хорошие программисты не предполагают, что они правы, они проверяют свой код, чтобы убедиться в своей правоте.
Вообще-то доказательство наличия проблемы и лежит изначально на группе тестирования. Любой профессиональный тестировщик, сообщая о наличии проблемы, опишет точные условия её воспроизведения, а не скажет: "У тебя тут приложение иногда падает с "Access violation". Разберись", потому что если он так скажет, ответ "А у меня не падает", будет самым адекватным! Если мне сообщают об ошибке в программе, я, прежде всего, смотрю, описаны ли условия, при которых эта эта ошибка появляется, и пытаюсь их повторить. Если условия описаны недостаточно чётко или ошибка не повторяется, я уточняю у человека, сообщившего об этой ошибке, как мне её воспроизвести, и, только убедившись, что ошибка действительно существует, я полезу в код и начну разбираться в её причинах. Ни один программист не станет искать ошибку у себя в коде, не убедившись, что она каким-то образом проявляется в работе программы! Разумеется, бывают достаточно редкие случаи, когда одна и та же последовательность действий и одни и те же входные данные приводят к разным результатам на разных компьютерах, и, разумеется, такие ошибки тоже надо исправлять, но, при этом, повторяю ещё и ещё раз: даже в этом случае, прежде чем искать у себя ошибку и бросаться что-то исправлять, надо обязательно убедиться в наличие проблемы. Потому что если вы не можете убедиться в её наличии, совсем не факт, что она вообще существует! Тестировщик мог взять старую версию программы, тестировщик мог взять кривые данные, результат на которых будет заведомо неправильным, тестировщик мог сделать что-то, о чём не написал в описании проблемы, тестировщик мог не разобраться с логикой работы программы и правильную её работу принять за ошибку. Возможно, проблема вообще не связана с той частью программы, над которой работает вы... Всё это обязательно нужно проверить! Если вам не удаётся воспроизвести ошибку, вы можете попросить тестировщика показать её на своём компьютере, можете попросить коллег проверить её на своих машинах, но пока факт наличия ошибки не будет точно установлен вами, браться за её решение бессмысленно, потому что если вы не можете убедиться в наличие ошибки, вы не сможете убедиться и в том, что её исправили. Ни один программист не пишет код вслепую! Он тут же проверяет результат своей работы!
6. Я работаю над тикетом 518
Почему не стоит говорить «Я работаю над тикетом 518»: такая фраза не предоставляет информации о том, над чем именно работает разработчик, а потому бесполезна. Указание только на номер тикета не даёт ясности о том, что именно делается и какой прогресс уже есть по задаче. Это может вызывать путаницу и затруднять коммуникацию внутри команды.
Я не знаю, как организована работа у того, кто это писал, но, например, в той компании, где я сейчас работаю, один тикет - это, как бы, квант выполненной работы. Каждый тикет назначается вполне конкретному человеку и его выполнение выкладывается на сервер одномоментно. Какой смысл в подобной ситуации уточнять, над чем именно в данном тикете вы в данный момент работаете, я не понимаю. Скорее тут имеет смысл уточнить, когда тикет будет сделан, но уточнять, над чем именно вы работаете, как раз, смысла особого нет, если только вас не проверяют на предмет того, что вы заняты делом, а не балду пинаете. Разумеется, возможны всякие исключения и я даже готов предположить, что у того, кто это писал, работа организована как-то иначе, например, один тикет разбивается на множество подзадач, на каждую из которых будет свой отдельный коммит, но, опять же, в этом случае очень раздражает, что кто-то корпоративные нормы, связанные со своими локальными особенностями работы, пытается навязать всем, видимо, по недомыслию считая, что эти нормы распространены в абсолютно всех IT-компаниях.
7. Это не моя задача
Я не очень понимаю, в каких случаях, по мнению авторов этой статьи, может возникнуть необходимость говорить эту фразу. Есть вполне конкретные задачи, записанные в тикетах, на конкретных людей, есть профессиональные отношения типа "начальник-подчинённый". Если начальство хочет, чтобы вы занимались данной конкретной задачей, оно может просто написать соответствующий тикет на вас и это будет вашей задачей. Если кто-то хочет переложить выполнение своего тикета на вас без согласования с начальством, то, по-моему, указание на то, что это не ваша задача, вполне уместно. Часто ещё штат разработчиков делится на отделы, где каждый отдел занимается своим типом задач. И в этом случае, если вам пытаются всучить задачу, которая явно не относится к специализации вашего отдела, на мой взгляд, будет вполне уместным указать на этот факт, иначе непонятно, а зачем вообще существуют эти отделы.
8. Моя часть работы сделана
Опять же, не очень понятно, когда по мнению авторов этой статьи, разработчик должен произносить эту фразу и какой смысл в неё вкладывать. Что значит "Моя часть работы сделана"? У тебя больше нет работы в этой компании? Тогда что ты вообще здесь делаешь? Срочно увольняйся! Серьёзно, что это за фраза и кто её вообще говорит? Как будто работа компании - это нечто, что можно один раз сделать и дальше только почивать на лаврах. Ты завершил какой-то очередной тикет? Ну так берись за следующий. Нет следующего? Попроси, чтобы тебе дали новых задач. Часть какой работы должен выполнить разработчик, чтобы вот так сообщить об этом? Честно говоря, я с трудом себе это представляю. Возможно, имеется в виду завершение какого-то крупного проекта... Впрочем, во-первых, это бывает настолько редко, что вряд ли даже стоит упоминания, во-вторых, а что там в проекте было прямо так чётко прописано, какая часть проекта за кем закреплена? Вот прямо так, чтобы можно было сказать: до этой черты - это моя часть, а после неё - уже не моя?
Эпилог
Собственно, на примере данной статьи с Яндекс.Практикума я хотел показать, насколько убогими выглядят статьи подобного типа. Сама попытка устанавливать какие-то общие правила для определённого класса людей довольно ущербна по своей сути, особенно когда эти правила носят такой категоричный характер. Если говорить непосредственно о данной статье, то непонятно, кому она обращена: людям, которые только собираются работать в IT, тем, кто уже работает программистом, но имеет небольшой опыт? Мне сложно представить, чтобы кто-то извлёк из подобных статей какую-то полезную информацию. Кажется очевидным, что для работы программистом прежде всего нужны глубокие знания в IT и опыт работы. Вы должны как минимум знать языки программирования, лучше несколько, разбираясь в тонкостях каждого языка, уметь писать код, уметь пользоваться различными технологиями, знать, как кодируется информация в компьютерах, придумывать и реализовывать различные алгоритмы, лучше всего, если вы будете иметь представление о том, как работают компьютеры на низком уровне, как реализуются те или иные механизмы языков программирования, потому что важно не только сделать, чтоб работало, но и сделать, чтоб работало за приемлемое время. Это огромный пласт знаний, от глубины проникновения в который будет зависеть эффективность вашей работы и, соответственно, ваша зарплата. Именно это ценится работодателями при приёме и в ходе работы. Именно на приобретении этих знаний стоит сосредоточить своё внимание! Всё остальное приложится! Как себя вести, как разговаривать, какие фразы произносить, какие не произносить, вы научитесь по ходу погружения в эти знания и приобретения опыта. Не надо запоминать, что ни в коем случае нельзя произносить фразу "я не знаю", лучше станьте крутым специалистом, разбирающимся во многих вещах, и тогда необходимость произносить эту фразу отпадёт сама собой! Подобные статьи опасны тем, что от их прочтения может сложится впечатление, будто соблюдение нескольких простых правил сделает тебя хорошим программистом. На самом деле всё в точности до наоборот: когда ты станешь крутым специалистом, ты будешь следовать определённым правилам автоматически! Не в такой категоричной форме, конечно, потому что опыт подскажет вам, когда их стоит нарушить, а когда - нет. Но если только начиная карьеру, человек слепо следует этим правилам, это может сделать только хуже, потому что он будет сосредоточен не на совершенствовании себя как специалиста, а на том, чтобы, ни дай бог, не нарушить какое-то неписанное правило. Например, прочитав о том, что не следует говорить "я не знаю", он будет стесняться задавать вопросы, боясь показать свою некомпетентность, что затруднит как его работу, так и получение новых знаний. А это очень важно! Не надо бояться признать, что вы чего-то не знаете, потому что признание этого - это первый шаг на пути к приобретению новых знаний. Это не значит, конечно, что надо задалбывать коллег постоянными вопросами, но помните, что рядом с вами сидят не ваши враги и конкуренты, а люди большей частью адекватные и дружелюбные, которые, к тому же, делают одно дело с вами, поэтому, скорее всего, вам не откажутся помочь в ответ на адекватную просьбу. Программисты - такие же люди, как и все остальные и разговаривать с ними стоит как с обычными людьми, естественно, стараясь поддерживать дружескую атмосферу, ну просто потому что в такой атмосфере работать гораздо комфортней. Но нет никаких особых правил общения программистов в команде разработчиков, это всё миф. Если вы умеете находить общий язык с людьми вообще, ничто не помешает вам находить такой язык и с коллегами. Всё остальное касается только специфики работы программиста.