Маленькие советы старшим о младших

    Почему новички время от времени делают «не то»? Почему они не понимают старших инженеров? Всегда ли это происходит из-за отсутствия опыта? И почему время от времени, за разговорами на кухне те же новички называют своих лидов «м*даками»?

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

    Начнем издалека. Когда я еще учился в школе, у меня было увлечение – игры. А именно Warcrtaft III. И я постоянно играл, играл, играл в нее. Сначала дело ограничивалось играми с ботами, затем, в прекрасном 2003’ем у меня появился интернет и понеслись игры с живыми людьми.
    Свою первую игру я проиграл – от нервов и мысли, что я могу проиграть, у меня тряслись руки и мерзли кончики пальцев, а где-то к середине игры на спине выступил холодный пот. Ясное дело, что с таким настроем первую игру я проиграл. Я проигрывал раз, затем другой, а за ним и третий. Это продолжалось довольно долгое время, пока один из моих друзей не посоветовал мне начать смотреть записи игр других, профессиональных игроков.


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

    Эти очевидные, и известные всем истины в тот момент стали для меня откровением. Да, я не раз слышал эти мысли от других людей, но не придавал им особого значения (мол говорят и говорят, у меня своя жизнь) пока не ощутил последствия на собственном опыте. В тот момент я решил больше не нервничать и не торопиться. У меня правда не особо получалось, но я прилежно старался. Показатели побед при тех же стратегия игры заметно пошли вверх. Вместо трех игр я стал в состоянии играть до десяти матчей в день.
    Возвращаясь непосредственно к статье и новичкам, молодым специалистам. Два основных правила, которые практически никто из них не соблюдает:
    1. Не торопиться
    2. Не нервничать

    По поводу первого пункта мы опять немного отвлечемся и я расскажу притчевую историю о разговоре с лидом еще когда я только начинал свою карьеру.
    Опять начну издалека, но потом вернусь к сути повествования, обещаю.
    Гарри Каспарова, чемпиона мира по шахматам, как-то спросили на сколько ходов вперед он в партии думает, планируя следующий ход. Спрашивающие считали, что тот сообщит некую внушительную цифру, и тогда они поймут, что же делает его победителем. Но сказанное им показало людям, что они неверно воспринимают даже саму суть игры: “Главное в шахматах не то, на сколько ходов вперед ты думаешь, а насколько хорошо ты анализируешь текущую ситуацию”.
    Суть этого метода в том, что, не зная объективно всей своей ситуации, люди начинают просчитывать варианты, которые изначально оказываются ошибочными. И поскольку просчитать все не представляется возможным, очередь до правильных ходов так никогда и не доходит. В результате, мы выбираем лучший вариант из худших. Лучший из тех, которые мы пытались так внимательно рассмотреть.
    Применяя ту же самую стратегию к жизни, можно понять, как часто мы, вместо того, чтобы объективно оценить происходящее, пытаемся просчитать ходы наперед, и как часто позднее эти ходы оказываются направленными не вперед, а куда-то в сторону.
    Ясно осознать настоящую ситуацию, — это значит сделать так, чтобы варианты открыли себя сами. Тот, кто говорит, что не знает, что ему делать дальше, всего-навсего не знает, что происходит с ним сейчас.

    Возвращаясь к разговору с лидом: когда я впервые пришел к нему за советом, меня очень удивила одна вещь: на мой вопрос по задаче он спросил еще с десяток уточняющих, затем замолк минуты на три, потом уточнил что-то еще. Я тогда еще подумал: «что он вообще делает, когда задачу решать начнем, ответ же где-то рядом». Помолчав еще, он начал спрашивать вопросы, про которые я просто не подумал, потому что не знал, что на самом деле мне нужно сделать. И только потом, когда он знал все, что его интересовало, он дал мне ответ. В результате такого, как мне показалось «тормозного поведения» в начале, задача была решена за пол часа правильно.
    Раз в пару недель я продолжал подходить к нему и спрашивать похожие вопросы – и его поведение оставалось одинаковым: полностью выяснить начальные условия, задать дополнительные вопросы и только потом начать думать.
    В какой-то момент нашей совместной работы я спросил у него тоже самое, что когда-то спросили у Каспарова. На что он ответил, что не думает наперед, пока полностью не разберется в текущей ситуации. В его голове не было даже мысли двигаться вперед, пока не понятно, что его окружает. В тот момент у меня в голове выстрелила очередная гениальная мысль: да он же прав!
    С тех пор мой список профессионала расширился третьем пунктом: прежде чем начать действовать, выясни, что тебя окружает.
    Другими словами, при получении первых знаний о задании, в голове образуется своеобразная «каша». Цель – от этой каши избавиться и превратить ее в строго структурированную модель, когда все находится на своем месте. Каким образом это делать – тема отдельной статьи.

    То есть другими словами, чтобы писать хороший код, да и вообще делать любое дело добросовестно, необходимо соблюдать три правила:
    1. Не нервничать
    2. Не торопится
    3. Выяснить, что тебя окружает

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

    Теперь рассмотрим проблему, с которой сталкиваются старожилы проекта: некоторые из стариков почему-то не хотят понимать или не понимают, что происходит в головах молодых разработчиков. Они не учат задавать вопросы, они не объясняют простые, по их мнению, вещи. Они не рассказывают, как думать и как строить цепочки размышлений.
    В этом их фатальная ошибка – человеку нужно объяснять, как именно сделать, что именно сделать и почему именно так. Некоторым кажется, что новичок дойдет до всего сам, в процессе. Но реальность далеко не всегда так хороша, как им кажется.
    Сталкиваясь с проблемой, люди начинают зацикливаться, тратить время на решение того, что можно было рассказать или спросить. Они задают не те вопросы, потому что не умеют формулировать свои мысли правильно. Они совершают не те действия, потому что не знают, чего хотят добиться.
    И главная проблема – они интерпретируют малейшее двусмысленное указание лида по-своему!
    Что бы не быть голословным, приведу пример, который отнял у нас лишних десять рабочих дней разработки. Лид переслал письмо мидл-инженеру с описанием задания (реальный текст карточки):
    1. User login with read access to Invoice view
    2. Admin remove access for user to Invoice view
    3. User refresh page with Invoice view
    4. User still has access to Invoice view
    5. User relogin to the system
    6. User has not access to Invoice view

    Что делает человек, как прилежный мидл-инженер? Он начинает разбираться почему так происходит, пишет уточняющие письма заказчику, узнает детали, какие системы могут быть затронуты, если он исправит поведение в системе, где этот баг воспроизводится. Затем все это обсуждается, детали реализации согласовываются с сеньорами. На все уходит 5 дней. Еще 5 дней на реализацию и тестирование.
    Проходит неделя, от продукт овнера приходит гневное письмо с примерным содержанием: «что вы натворили, всех на ковер». Начинаем разбираться, и после нескольких звонков и писем выясняется, что функциональность, которую правил разработчик, на самом деле была Правильной! А тестировщик, который создавал карточку, описанием задания всего лишь имел ввиду «уточнить, правильно ли работает приложение или это баг!».
    Почему-то каждый человек считает, что его собственные мысли, такие простые и понятные, каким-то магическим образом окажутся в голове у других. Что все «лишние и ненужные слова» можно опустить, ведь это само собой разумеющиеся истины. И люди начинают сокращать свои предложения, перестают полностью вводить исполнителя в курс дела, что-то остается недосказанным «потому как это само-собой разумеется».
    НО!
    НО это никогда не работает. Всегда нужно показать и рассказать, а не отмахиваться от проблемы. Переступить мысль «да ладно, они все там поймут, не тупые же» и написать все по пунктам, каждое слово, которое вы имеете ввиду.
    И отсюда очень простой и очень важный вывод: никогда не допускайте двусмысленности при формулировке задания.

    Подводя итоги, повторюсь: если вам необходимо «вести» новичков, с первых дней расскажите и объясните им, что для дальнейшего развития карьеры инженера-программиста им крайне рекомендуется научиться соблюдать четыре правила:
    1. Не нервничать
    2. Не торопиться
    3. Выяснить, что тебя окружает
    4. Не допускать двусмысленных формулировок своих мыслей
    Share post

    Comments 51

    • UFO just landed and posted this here
        +4
        Вы знаете, в последнее время я склоняюсь к мысли, что KISS — это не для джуниоров. Пусть лучше сначала научатся делать хорошо, хоть и избыточно, а уж потом, когда подучатся и станут как минимум regular developers, можно будет начинать бороться с избыточностью. Этапы «делаю как в умной книжке написано» и architecture astronautics тоже еще надо пройти.

        В противном случае KISS выливается в «здесь не нужна авторизация», «здесь не нужна валидация», «ошибок не бывает», «функция, которую я вызываю, всегда работает правильно» и т.д.
          0
          Сначала делаешь кое-как, чтобы оно просто начало работать.
          Потом делаешь, соблюдая ВСЕ известные рекомендации правильной работы.
          А потом, набравшись опыта, делаешь, соблюдая свои собственные рекомендации.
        +12
        6 ????
        7 PROFIT
          +4
          Самое главное правило для новичка — спрашивай, для ведущего — отвечай.
          А мудаков лучше называть в лицо, для этого обычно даже устраивают ретроспективы, где можно вдоволь пройтись по свои и чужим ошибкам и заслугам.

          p.s. Ходит легенда, что если проанализировать действия лётчика во время полёта, то почти каждое содержит хотя бы небольшую ошибку, но он не бросает штурвал, исправляет ошибки, двигается дальше и достигает цели.
            +4
            Новичок не всегда знает что именно нужно спрашивать из-за каши в голове.
              –26
              Такой новичок профнепригоден, ему место за партой, а не в приличной команде продакшена.
              Пусть сначала учится, читает, «смотрит видео», колхозит какой-то свой софт, выкладывает его на гитхаб и т.п.
              Пока он будет учится до уровня, когда его можно подпускать к репозиторию — проект закончится. Ну и смысл такого нанимать?
                +7
                Смысл немного в другом: человек умеет писать код, и квалификация его именно как «кодера» не вызывает сомнений. Но у него страдает внимательность. Услышав лишь начальные условия задачи, он, зажжённый идеей быстрее писать код, не зная всех нюансов, спешит делать выводы, зачастую неверные.
                  –20
                  Если человек пишет код, не понимая решаемой задачи, он профнепригоден. И здесь не в опыте дело.
                    +7
                    Есть разница между «он не понимает» и «ему кажется, что он понимает и поэтому у него нет вопросов».
                      0
                      Я а вот согласен с vanxant, только очень уж резко он выражается. Бывает, что работодатель, который в свою очередь является подрядчиком заказчика, нанимает кучу джуниоров — эникейщиков (кодеров, как ни назови) на должность, где должны быть настоящие программисты — т.е. те, кто не просто умеет код, но понимает для чего и как он это делает.

                      Вывод сделаю такой — кесарю кесарево. Таких джуниоров нужно учить на мелких аутсорсовых проектах, небольших автономных модулях системы за жестким API и покрытых тестами, также хорошо учатся на багфиксинге уже существующего кода (хорошего). Но наш мир не идеален, и зачастую получается, что в целях сиюминутной выгоды таких вот кодеров садят за архитектурные вещи, а у более опытного товарища банально нет времени смотреть что тут не так.
                        0
                        Это из серии: «уметь играть в шахматы» и «знать как ходят фигуры».
                          0
                          Предлагаю вам посмотреть на ситуацию с другой стороны.

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

                          Итог: товар через день эксплуатации сдох продан, быдлокодеры новички получили свои печеньки и отпрвились на другой шлако-генератор проект говнокодить набираться опыта.

                          Что я пытался объяснить: если новичок не хочет становиться профи, он всегда будет новичком. Т.е. это не односторонний процесс: не только «тимлид» должен думать, на что лучше направить новичка, но и новичок должен думать, чего он хочет от своей работы: печенки с изюмом, печенки без изюма, изюм без печенек, опыт или мастерство.
                            0
                            Чтобы новичок так думал, кто-то должен что-то подобное ему сказать. Убедительно.
                            Вот как Вы, например, сказали.
                  +1
                  Ретроспективы немного для другого придуманы — для того, чтобы решать проблемы в процессах, по которым работают все, а не для того, чтобы устраивать разборы полетов отдельным членам команды.
                  +41
                  1. User login with read access to Invoice view
                  2. Admin remove access for user to Invoice view
                  3. User refresh page with Invoice view
                  4. User still has access to Invoice view
                  5. User relogin to the system
                  6. User has not access to Invoice view

                  Автора этого чуда отправили на принудительные курсы английского?
                    0
                    А бывает сделаешь коллеге замечание по жутко кривому английскому в багтрекере — реакция большинства @«да какая разница, это только для нас», @«нам понятно», @«зато он хороший программист, зачем ему английский»…
                      0
                      Может это по тому что багтрекер — не курсы английского?
                      На хабре например про опечатки в статье принято писать в ЛС, тут мне кажется логика та самая.
                        +1
                        Тут, мне кажется, неоднозначность между «сделать замечание в багтрекере» и «сделать (где-то) замечание об уровне английского, который коллега продемонстрировал в багтрекере». Надо попросить iago пояснить, что он имел в виду.
                          0
                          Спасибо, конечно же я имел в виду замечание в качестве совета лично, без багтрекеров, хотя и не выходил для этого специально из комнаты. Если честно, у меня вызывает подозрения программист, который не уверен в написании слова и не сверится с гугл транслэйтом в переводе, а лепит абы что. Есть мнение, что и в коде у него такой же бардак — у всех плохих программистов, который я знал, был плохой английский, но были конечно и плохие с хорошим английским. Пусть не даются языки — мне тоже не очень дается — но сверить со словарем особых талантов не надо.
                            0
                            А вот здесь я бы порекомендовал сменить гугл-транслейт на словарь получше. Сам пользуюсь вот этим: multitran.ru. Фразеология, переносные значения и тому подобное помогают избежать лишних конфузов.
                              0
                              Бог с ней с пунктуацией, даже с порядком слов, но когда встречаешь что в коде товарищей, что в багтрекере неграмотную орфографию, т.е. человек просто ленится свериться со словарем — это уже печально…
                                +1
                                Скорее не ленится, а хуже. Уже встречал таких, когда человек ничтоже сумняшеся пишет так, как слышит (один ещё пропускает буквы), даже порой по-разному в одном и том же тексте. При коррекции говорят, что какая разница, смысл понятен или уверяют, что это я неправ.
                                  0
                                  От души плюсую собрата по несчастью!
                          0
                          Пусть лучше по-русски пишут, этот набор слов вообще не похож на задание
                        0
                        … методом погружения.
                        +4
                        3. Выяснить, что тебя окружает
                        Правильный совет, жаль что иногда люди на уточняющие вопросы начинают потихоньку выходить из себя, как будто бы объясняют тупому и ты ещё себя чувствуешь неловко. Но это не происходит там, где обе стороны заинтересованы в результате.

                        4. Не допускать двусмысленных формулировок своих мыслей
                        Есть более общее правило: передавайте информацию так, чтобы её понял принимающий человек.
                        Т.е. нужно учитывать что знает человек или группа людей и правильно преподносить информацию. Это вообще проблема общения.
                          +1
                          Ох, прямо за живое…
                          Был один заказчик, который 4 пункту не следовал ровным счетом никогда, но в ответ на мое выполнение третьего всегда злился и возмущался.
                          При этом, самому ему приходилось иногда элементарные вещи разжевывать как для дошколят… И его это ни капли не смущало!
                          Ненавижу двойные стандарты :(
                          • UFO just landed and posted this here
                              –1
                              ну как по мне, чтобы не было этих самых «двойных стандартов» нужно перед созданием тз, максимально разжевывать каждый из элементов, и да, иногда и разжевывать элементарные вещи. Ведь заказчик всегда прав… Ну или практически всегда
                              +1
                              Но это не происходит там, где обе стороны заинтересованы в результате.
                              Позволю себе не согласиться, не всегда это работает. Особенно феерично выглядит на стройке, когда, получив задание, надо: во-первых, продумать за несколько секунд (пока начальник в теме) все последствия/преграды/где взять материал (да, и так бывает!); во-вторых, прорваться через всевозможные «меня не е**т те потолки» и «что ты все переспрашиваешь». Поэтому все опытные бригадирА, которых я видел, держат в голове возможные задания (т.е. узнают и просчитывают всё заранее) и обладают непоколебимой стойкостью и упорством.

                              Есть более общее правило: передавайте информацию так, чтобы её понял принимающий человек.
                              Очень многие не понимают одной простой вещи.
                              Если вы разговариваете с человеком и хотите, чтобы он принял вас всерьез,
                              говорите с ним на его собственном жаргоне. Если же вы цитируете Шелли, но
                              говорите, как простолюдин, они находят, что вы милы, вроде обезьянки у
                              шарманщика, но на смысл ваших слов они не обращают внимания. Необходимо
                              говорить на жаргоне, который они привыкли принимать всерьез. И наоборот.
                              Половина политической интеллигенции, выступая перед рабочей аудиторией,
                              ничего не может добиться — и не столько потому, что она стоит выше этой
                              аудитории, сколько из-за того, что большинство ребят слушают голос, а не
                              слова; они пропускают слова мимо ушей, потому что слова эти очень уж
                              вычурные, а не обыкновенная человеческая речь. И вот я рассудил, что надо
                              сделаться двуязыким и каждый язык употреблять в подходящей обстановке, а
                              время от времени — вдруг и не тот язык не в той обстановке. Это действует
                              без промаха.
                              Д.Уиндем, «День триффидов»
                              –6
                              — Хрущ, Хрущ, снеси меня домой! У меня ножки болят.
                              — А ты где живешь?
                              — В муравейнике за лесом.
                              — Далеконько… Ну что с тобой делать? Садись, довезу.
                                +1
                                С 4.п. может дело в «консерватории»?

                                www.rg.ru/2013/10/09/ekzamen.html
                                +5
                                Есть много людей, которые боятся переспрашивать. Думают: «блин, я спросил и мне ответили, а я не понял :( Не буду переспрашивать, а то подумают, что я дурак и не профпригоден».

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

                                Вот тут-то и начинаются разброд и шатания :)

                                А по статье: надо добавить- пытать вопросами, пока у самого в голове не получилась стройная картина. Неважно сколько вопросов это займет.
                                  0
                                  Вот вот, лучше что бы все всё поняли до начала, и в процессе уточняли, чем потом что либо переделывали уже в готовом.
                                  +3
                                  Всегда любил статьи, которые структурирует не совсем очевидные вещи, а не в стиле кэпа повторяют уже давно все сказанное.

                                  Как мне кажется, основная сила этой статьи — это третий пункт, остальное, скорее, в стиле кэпа. Хотя, я понимаю что без этих пунктов статья была бы не полной и все было бы хуже. Но вот третий пункт отличный. НЕ очевидные но простые вещи, на мой взгляд.Отличные цитаты и примеры. Спасибо.
                                    +1
                                    Особенно исчерпывающие, похожие вопросы разбираются в книге «Эмоциональный интеллект». Крайне рекомендую
                                      0
                                      Прекрасная статья. Многие люди, как уже отметили выше, боятся переспросить. А некоторых даже бесят уточняющие вопросы. С этим нужно как-то бороться, и понимать, что если на твой вопрос тебе задают еще 10, то это не ради праздного любопытства. Ну и, к слову:

                                      профессиональные игроки не нервничали
                                      Да бросьте, конечно они нервничают, как и все нормальные люди. Другое дело, что они умеют с этим бороться.
                                        0
                                        Вот именно, умеют бороться, и к моменту старта игры уже не нервничают.
                                        +3
                                        Про англицизмы — есть такая жуткая калька «спросить вопрос». Правильно — «спросить» или «задать вопрос», на выбор. И не говорите мне, что без этой кальки у Вас в тексте что-то непонятно станет :).

                                        А сами по себе правила хорошие, да :).
                                          +3
                                          С тезисами, озвученными в статье, полностью согласен. Сам в своё время наступал на те же грабли: и излишняя ретивость, и страх переспрашивать.

                                          Интереснее, с моей точки зрения, то, почему такие явления имеют место быть. Очевидно, что если проблема столь массовая, значит дело не в индивидуальных особенностях конкретных личностей.
                                          И вот сейчас мне кажется, что корень проблемы — в раннем детском возрасте, во взаимодействии юного человека с семьёй и школой. Родителей вечно бесит, что их чада задают слишком много вопросов — и те не стесняясь орут на них и затыкают, чтобы просто ощутить тишину. Учителей бесит, когда ученики задают вопросы, которые кажутся им неуместными, и авторы таких вопросов подвергаются всяческому унижению и осмеянию, в результате которого уже сами сверстники понимают, что можно невозбранно гнобить тех, кто лишний раз открывает рот.
                                          В итоге, мы имеем то что имеем: люди, вырастая, продолжают жить по принципу «меньше скажешь — целее будешь», а тех кто, следуя логике из статьи, старается быть многословным и недвусмысленным, подкалывают за «избыточность» и «занудство». И такой подход уже настолько глубоко забит в сознании, что достать его через рефлексию или ретроспективные техники крайне сложно.

                                          Что с этим делать — не знаю. Пока мы имеем текущую систему образования, где поощряется унифицированность, а индивидуальность не всегда приветствуется или даже подавляется — вряд ли что-то изменится. Остаётся лишь не уповать на дядю в лице государственных институтов и справляться хотя бы со своими родительскими обязанностями, чутко и с пониманием относясь к вопросам собственных детей и не забывая регулярно напоминать им, что не понимать с первого раза не стыдно и что глупых вопросов не бывает.
                                            +3
                                            Тот, кто говорит, что не знает, что ему делать дальше, всего-навсего не знает, что происходит с ним сейчас

                                            Вот за эту фразу огромное Вам спасибо!!!
                                              +1
                                              Фраза хороша, но всё же не истинна.
                                              Можно вполне знать, что происходит сейчас и не иметь ни малейшего понятия, что с этим можно сделать, чтобы не ухудшить положения. «Не знать» можно на любых этапах развития ситуации!

                                              Но да, достаточно часто не знают именно про первый этап, про происходящее. И тогда до второго этапа, до обоснованного выбора дальнейших действий, просто вовсе не доходит.
                                              0
                                              Вообще, мне иногда кажется, ставить задачу надо как будто респондент — идиот. Разжевывать, уточнять, «понял ли ты что я понял что ты понял»
                                              Пусть тебя считают мудаком, но за то это будет единственное непонимание.
                                                +1
                                                Полностью согласен с тем, что так было бы правильнее, но, увы, человеческие эмоции в этом вопросе очень сильно мешают. Не будет обижаться на такой «идиотский» подход лишь тот, кто уже постиг всю его глубину и сам при необходимости им пользуется.

                                                А те, кто не особо настроен уточнять, задавать вопросы, понимать и быть понятыми, смогут заблудиться даже в инструкции для идиотов. Сам лично наблюдал такую ситуацию, когда паренёк-разработчик чуть ли не проигнорировал половину условий в поставленной задаче, а потом, когда я у него спрашивал, какого хрена он это сделал и даже не задал ни единого вопроса, просто отвечал «ну, я думал что всё правильно понял, извините».
                                                +1
                                                я всегда объясняю дважды, а потом прошу рассказать, что поняли и как правило приходится рассказывать третий раз.
                                                я всегда объясняю дважды, а потом прошу рассказать, что поняли и как правило приходится рассказывать третий раз.

                                                я всегда объясняю дважды, а потом прошу рассказать, что поняли и как правило приходится рассказывать третий раз.
                                                  0
                                                  Вы всегда объясняете четырежды по вторникам и средам после цунами или… Ну как-то так. Короче — я все понял, иду кодить.
                                                  0
                                                  Вот про двусмысленность все верно написали. Являюсь новичком и иногда допускаю двусмысленность, так же, бывает, тороплюсь. Уже осознал эти две вещи. Пытаюсь над собой работать в этом отношении.
                                                    0
                                                    [removed]

                                                  Only users with full accounts can post comments. Log in, please.