Kyiv IT Outsourcing Forum 2017 — встигни купити Early Bird квитки до 1 травня!

Сложные ситуации в IT, и что с ними делать?

В этой статье разберем эмоционально-сложные ситуации, с которыми сталкиваются айтишники на работе. В конце — пара строк рекламы.

Начальство

Сверху приходят указания:

  • «брось всё — делай вот это»;
  • «делай вот таким способом». А способ — явно не лучший, и объяснить не получается;
  • «останься на выходных» и прочий овертайм;
  • «хорошо сделал — а теперь поставь git-метку, а вот в общий код не мердж». Обидно выкидывать много работы;
  • «быстро заэстимейть подробно эту задачу», причем результат должен уложиться в человеко-месяц;
  • «а давай внедрим KPI».


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

  • низкий IQ. Крайне редкая причина, в айти идиоты не приживаются, а PM «по знакомству» не становятся;
  • мало знаний в профильной области и нет умения окружить себя экспертами. Такое иногда бывает, хотя довольно редко;
  • желание проявить власть. Иногда бывает, но всё-таки редко. Я, пожалуй, только пару примеров могу привести за 18 лет;
  • адаптация — суперэксперты привыкают, что кругом все разбираются очень слабо. Поэтому привычнее сказать «сделай, как я сказал», чем объяснять, почему так. Каждому объяснишь — а работать когда?
  • мало данных и понимания текущей ситуации. Вот это частая проблема. Хуже того, менеджеры часто не понимают, что данных мало, и предпочитают действовать. Что делать:
    • задавать вопросы «а что будем делать, если вот так и вот так?» Скорее всего, к вам этот вопрос и вернется с формулирокой «быстренько посмотри вот это, и давай еще подумаем»;
    • выводить на конкретные изменения в действиях. Т.е. если «вы должны меньше времени тратить на саппорт», то «если я весь саппорт вынесу на понедельники, это ок?».
  • менеджеры, которые выросли из программистов, часто имеют особенности:
    • самим хочется покодить, а некогда;
    • теряется техническая квалификация, но заметить это некогда;
    • их повысили за умение писать хороший код, а дальше хороший код писать некогда и не получается. Начинаются нервы «я должен писать код, я не пишу код, я плохой сотрудник» и включается защита.
    • те, у кого есть склонность к перфекционизму, пытаются контролировать всё. Микроменеджмент убивает.
  • у начальства слабые навыки донесения своей мысли: «ну там это, ну вот, я хотел сказать о, сделай как я уже говорил»;
  • бюрократия. К примеру, оговорено в контракте, что все должны работать на сертифицированных ноутах через RDC — и всё тут. Да, неудобно, но за это платят деньги;
  • ...

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

Менеджерам: одна из задач лидера — это защита команды. Защита в том числе и от начальства. Хорошо бы уметь объяснять, чем обоснованы те или иные начальственные действия. И лучше бы использовать не «они идиоты и считают, что девять женщин родят одного ребенка быстрее, чем одна», а «начальство видит, что мы не успеваем и хочет нам помочь добавлением сильного сотрудника».

«Я — идиот», «меня вот-вот уволят»

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

Знаете, как это бывает? Потратишь пару дней на поиск бага, а потом там оказывается какая-то мелочь — пропущенная точка с запятой или еще какая опечатка. Думаю, у всех было.

  • Ощущение «я тупой» — это нормально для синьора. См. синдром самозванца и эффект Даннинга-Крюгера. Наоборот, если человек говорит: «я классно знаю Java, JavaScript, C# и Ruby» или «я классно разбираюсь в людях» — это наверняка джуниор.
  • Увольняют в IT нечасто, хотя мне довелось проходить эту процедуру неоднократно. Плюс-минус надежный способ это избежать — это регулярно, раз в несколько месяцев спрашивать начальство: «как я работаю?» и «что я могу сделать лучше для повышения зарплаты?».
  • Менеджерам: ваши сотрудники точно время от времени чувствуют себя идиотами. В этот момент им надо:
    • сначала дать поддержку: выслушать, напомнить предыдущие достижения, еще раз выслушать. Про цепочку отрицание-гнев-торг-депрессия-принятие многие читали, впрочем, стадии могут идти и в другом порядке. Дать поддержку — это правильно по-человечески и оправдано с бизнес-точки зрения тоже, ведь человек вернется в рабочее состояние;
    • воспользоваться случаем, и вместе поискать ответ на вопрос «как такое предотвратить в дальнейшем?». Как раз после эпических провалов проще всего начать делать code review, ранние демки, синкапы, парное программирование и прочие сложновнедряемые практики.

Зарплата: «мне переплачивают» и «мне недоплачивают»

Мысль «мне недоплачивают» возникает тогда, когда долго нет провалов и негативной обратной связи. «Переплачивают» — тогда, когда две недели с каким-то пустяком провозился.

Среднюю зарплату проще всего проверить на jobs.dou.ua. Если есть большое отклонение — только тогда опасения обоснованы. Ну и если фирма разоряется, то увольнение тоже вполне реально.

Менеджерам:

  • следите за попаданием з/п сотрудников в общий коридор:
    • большинство склонно переоценивать свою ценность на рынке труда. С другой стороны, зарплаты растут, и сегодняшнего вашего миддла запросто переманят на з/п синьора;
    • когда люди получают оффер от другой фирмы на +20% зп, а потом контр-оффер от своей на +30%, то они обижаются. Ну действительно, раньше +10% получить не получалось, а теперь сразу +30% предлагают?! Такой контр-оффер — это решение на несколько месяцев, да еще и когда станет известно другим сотрудникам — их сильно демотивирует.
  • в любой компании примерно половина сотрудников смотрит на другие фирмы. Что вы будете делать, если кто-то из ключевых уйдет? Погуглите про bus factor.

Хочу открыть свою фирму

Двукратная разница между стоимостью часа, которую выставляют заказчику и часа зарплаты — это более-менее норма. Эта разница оплачивает отпуск, больничный, праздники, железо, офис и т.д. И прибыли остается условных 10-15%. Т.е. с 8-10 программистов получается прибыль в размере средней зарплаты. Подробнее можно почитать, например, тут.

  • До момента, когда у вас в штате не будет 8 программистов, прибыльнее получать зарплату. Это оптимистичный сценарий.

Конечно, своя фирма или фриланс дают чувство свободы, которое сложно получить, выполняя указания начальства.

Менеджерам: тут важно разделять две разных ситуации:

  • человек действительно планирует так поступить в ближайшем будущем, у него есть бэклог, портфель заказов, сроки и прочий бизнес-план. В этом случае нужно думать о минимизации потерь от расставания;
  • для человека это бегство и самоуспокоение, особенно для людей, для которых даже организация пикника дается с трудом. В детстве такое бегство — это «вот если бы я был очень сильным» или «если бы я был очень быстрым», а сейчас — «если бы я был успешным бизнесменом». Никто не признается, что для него мечты о своей фирме — это самоуспокоение, так что тут менеджерские действия:
    • поиск причины, почему человеку плохо. Сам он вряд ли осознает и скажет именно причину, скорее вас накормят поводами. Причина может быть и за пределами работы. Если же причина таки на работе — чаще всего нарушен баланс между похвалами и указаниями «вот тут неправильно»;
    • поддержите человека. Выслушайте и не кормите советами.

Требуют оценить сроки

Обычно менеджерам нужны сроки. Хоть какие-то. Хоть очень примерно. Неопытные менеджеры закладывают сроки «как есть» в контракт, опытные — делают запас. Но каким бы опытным менеджер ни был бы — ему нужны цифры, от которых можно отталкиваться.

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

  • постарайтесь таки помочь менеджеру оценить сроки. А если потом за срыв сроков он накажет — увольняйтесь нафиг.

Менеджерам: если человек не хочет говорить о сроках, даже приблизительную вилку — значит он чего-то боится. Скорее всего, его раньше уже кто-то возил носом по столу за срыв сроков, вот и не хочется подставляться еще раз. Здесь много подходов, и нет ни одного идеального:

  • ограничивайте вилку очень примерно. «Есть ли шанс, что сделаешь за день? Нет... А за два — уже есть шанс?» и с другой стороны «Может ли это затянуться до мая? Быстрее? К середине апреля?»;
  • сравнивайте, объединяйте независимые оценки от разных людей;
  • используйте planning poker, метод футболок и т.д.;
  • расскажите заказчику про NoEstimates :)

Заказчик меняет требования

Иногда такое бывает. Такое бывает всегда. Нужно пару раз побыть в шкуре заказчика, чтобы понять — почему так.

На проекте с фиксированной ценой есть две крайности:

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

Что делать:

  • для fixed price — о любых, даже самых мелких правках — сообщать менеджеру или кто там вел переговоры о цене;
  • для time & material — предупреждать заказчика о том, сколько это займет.

У Сергея Бережного был интересный цикл на эту тему.

Менеджерам: только смерть стабильна, жизнь всегда динамична. Создавайте информационный фон, который рассказывает о неизбежности изменений. Например:

  • Чем тщательнее сделано ТЗ, тем больше шансов, что оно уже устарело и не нужно.

Заказчик нифига не понимает в разработке

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

«Если Заказчик хочет Волшебника, то он находит Сказочника» © менеджерская мудрость

Здесь всегда соревнование между желанием чуда у Заказчика и умением объяснять у Исполнителя.

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

Приходится допиливать чужой кривой код

Заказчики, которые уже ушли от Сказочника, обычно имеют массу кода, который «почти работает, чуть-чуть осталось». Почему уходят от Сказочника?

  • срывы сроков;
  • масса багов и недоделок.

Какие сложности для следующего исполнителя:
— чужой код разбирать всегда сложнее. Особенно, если он написан кое-как и нет рядом живого человека, который знает «почему так»;
— заказчику уже пообещали, что тут немного осталось. Сроки не просто горят, а уже сгорели.

Какие плюсы:

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

Менеджерам: иногда получается выбить полную переделку, а иногда у заказчика на это уже нет времени и денег. Если не получилось полный, то ползучий партизанский рефакторинг может помочь.

«Заказчик давит» и удаленная работа

Часто бывает, что заказчик давит. И часто — это побочный эффект от удаленной работы.

Почему так?

  • если нет личного общения, то очень легко перестать видеть в собеседнике человека. Видеоскайп чем-то помогает, но всё равно;
  • когда исполнителя нет рядом, то всё время кажется, что он бездельничает. С такими эмоциями сложно справиться. А если исполнитель еще и не отвечает моментально — то идет заполнение паузы тревожностью и раздражением. А если исполнитель еще и отвечает с паузами на неправильном английском, то вообще ужас;
  • часто у человека, который беспокоится, возникает желание построить рамки: «плз, отвечай мне в течение часа в бизнес-время», «давай эстимейты», «докладывай о прогрессе раз в N рабочих часов».

Более подробно расскажу на PMDay 1-го апреля.

Конфликты

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

Неприятные задачи

Знаю классного бэкендера, который не любит Excel и сисадминство. Другой — не любит задач по саппорту. Пока они молчат о своей нелюбви к каким-то типам задач — менеджер обычно нифига не знает и не меняет.

Менеджерам: знайте, что любят ваши сотрудники, а что — нет :)

Эстетика и прочая гигиена

Можно ли на стену вешать эротический календарь? А если порнографический? Нужно ли ходить в душ после тренировки/велосипеда? Раз в сколько дней (недель) нужно менять футболку? Парням — носить футболку-сетку? Девушкам — цокать высокими каблуками и пшикаться мощными духами? Включить кондиционер или открыть окно? Есть на рабочем месте? А если апельсин (дуриан)?

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

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

Менеджерам:

  • стройте доверительные отношения. Заранее;
  • хоть чуть-чуть покопайтесь в языке жестов. Он проще регэкспов.

Этика

С этическими проблемами мы в айти сталкиваемся реже. Хотя вот примеры:

  • мне пришлось уволить UI/UX в разгар кризиса. Я знал, что у него жена вот-вот родит, но он откровенно не вписывался в рабочий процесс;
  • что делать с человеком, который на корпоративном принтере и корпоративной бумаге печатает по толстой художественной книге в неделю? Меняется ли что-то, если это интерн на испытательном сроке или, наоборот, мегаэксперт, которому фирма может подарить принтер как бонус к зп? А готовы отвечать на вопрос «почему ему можно, а мне нельзя? А где это в правилах?»;
  • сотрудник увлекается стритрейсингом, и других подбивает. С одной стороны — не мое дело, с другой — уже несколько раз в мелкие аварии попадал, и когда собьет кого-то всерьез — вопрос времени;
  • сотрудник очень любит девушек — раньше таких называли ловеласами, теперь модно слово «пикапер». Должен ли я предупреждать девушек? Или они взрослые люди и, если что, то разбитым сердцем будут страдать вне рабочего времени? Или сделать внушение парню?

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

QA против программистов

Я в таких фирмах не работал, но вполне представляю, как такое может быть. Например, в комментах проскочила фраза: «Один джун конкретно накосячил у меня... В общем отправил его в тестеры. Наказал в общем и сильно».

Менеджерам: на мой взгляд, как только какая-то роль на проекте обозначается неважной, то начинаются обиды и дедовщина. Это здорово вредит рабочей обстановке, и такое нужно пресекать. Если вам какая-то роль не нужна — сократите её и поделите освободившуюся зарплату. А если таки нужна — уважайте.

Подчиненные

  • «Добавили помощников, теперь совсем некогда работать» — очень примерно: один подчиненный требует один час в день. Новички и джуны требуют время чаще, синьоры — больше, на обсуждение серьезных вопросов.
  • Судя по здесь и здесь, в украинский IT-бассейн людей втекает 20% в год, а вытекает — 5%, и мы знаем, что втекают джуниоры, а утекают синьоры, то что будет с остающимися? Правильно, процентное соотношение будет отклоняться в сторону джунов. Кто будет с этими джунами возиться? Нынешние миддлы и синьоры. Вот такая пирамида обучения.

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

Code Review

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

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

Что изучать?

Языков / фреймворков / библиотек сейчас очень много. А времени, почему-то, мало. Что же учить? А для чего?

  • Если для себя — то всё равно что. Хоть фортран, хоть монады — лишь бы интересно было.
  • Если для дальнейшей работы или для трудоустройства — то лучше что-то из тех технологий, которые сейчас вверх лезут. Кмк, это JavaScript и Python.
  • А если уже совсем с точки зрения прагматичной, то смотрим на рынок труда, например, djinni.
    • для джунов имеет критическое значение стаж. Вы его наберете автоматически, и хорошо бы к стажу добавить еще и навыки. Очень хорошо бы.
    • для синьоров технические навыки квалифицированно за час-другой не оценишь, и на первое место выходит английский. Очень печальный для меня вывод, мне английский дается с большим трудом.

При обучении темп работы падает. Если до этого все время писал на Ruby, а тут решил nodejs освоить, так на руби сервак написать всё равно быстрее выйдет. Когда еще дойдешь до такого же уровня... Дальше гуглить по «Кривая процесса обучения (А. Бандура)».

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

Вместо вывода

В этой статье мы рассмотрели разные эмоционально-сложные ситуации, в которые попадают программисты и менеджеры. Список неполный, и решения однозначно не стопроцентные, буду рад комментам и дополнениям. Еще я провожу 9-го апреля тренинг в Киеве, на котором многие проблемные ситуации отработаем на практике. Подробности и запись — тут.

38 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Хороший конспект. Очень жаль, что подробнее не раскрыли тему

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

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

Насчет сроков — как программист говорю. Берешь оптимистические и умножаешь их на 3. А вообще есть притча «о Сократе и прохожем». По концу первого спринта будет понятно кто с какой скоростью ходит.

Норм статья. Коротко и ясно

Спасибо

Отличная статья, спасибо. И примеры показательные. (По-моему, я её частично её тут видел в более ранних постингах? но сводная форма всё равно не помешает.)

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

Вот в этом

«ты балбес» — «ты плохой программист» — «ты написал криво» — «это кривой код» — «тут лучше сделать вот так» — «можно ли с помощью лямбда-выражений сократить этот код?»

одна из проблем, что слишком многие реагируют на варианты 4-6 примерно как на вариант 2, если не как на 1. Это чаще с представителями некоторых восточных народов, но и с нашими бывает, а как-то я видел даже с одним амером — национальные свойства дают статистику, но не отдельные случаи.

«Если Заказчик хочет Волшебника, то он находит Сказочника»

Запишу в цитатник.

Цитата — не моя

По-моему, я её частично её тут видел в более ранних постингах
Разве что на фейсбуке. На DOU идут недублирующиеся вещи.

Я останній рік думаю про застосування теорії керування до проектного менеджменту... PID-контролер для початку. І тут в статті, як підтвердження, кілька разів згадується, що добре, коли зміни є плавними.

Дожити б до пенсії і постраждати фігньою...

Насчет первой части «начальство». Иногда сотрудник не понимает логику решения и на его уровне оно кажется бессмысленным или вообще идиотским. Но сотрудник может не видеть всю картину с позиции директора на проект и взаимоотношения с заказчиком. А обьяснять либо долго и бесперспективно либо информация может быть конфиденциальна.

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

Отличная статья, спасибо!

Спасибо, такие комменты греют :)

в айти идиоты не приживаются, а PM «по знакомству» не становятся
регулярно наблюдаю обратное

То есть, вот фирма уже лет десят работает без убытков и в ней n-е количество идиотов?

принцип Парето нам даже показывает граничное значение в 80% для последних,
главное, чтобы другие 20% по прежнему делали 80% всей работы

А кто будет делать остальные 20%? Идиоты? Вы же понимаете, как это скажется на качестве софта?

Никто. А качество софта?
Можно подумать, что ты не программист, что такие вопросы задаешь.

Вот эти 80% и делают остальные 20% работы. И не обязательно говорить только о программистах. В этих 80% почти все — менеджеры, которые днями просиживают на митингах, «улучшая стратегию» :)

Я знаю контору, что делает очень приличные вещи и в ней из 300 душ реально качественно работают человек 30 только. Этого достаточно.

Бывший советский НИИ что ли? Вот там примерно такое соотношение и было.

Уже давно нет. Но контора прикормленная госзаказами.
Тем ни менее на одном мексиканском большом тендере порвали все остальные конторы из своей области соотношением цена/качество предлагаемого продукта.
Кстати, контору я ранее уже не раз называл.
В некоторых своих продуктах они в 10-ке мировых лидеров по качеству.

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

А остальные 270 что делают?

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

А остальные 270 что делают?
ИБД.

Ваш КЭП.

Они сломали закон парето

Учитывая, что в любом коллективе люди распределяются на 5-20% умных и 80-95% остальных — как раз нормальный уровень управленческого искусства это сделать, чтобы эти 80% всё равно работали на пользу. Пусть и на порядок меньше top-группы.

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

Менеджеры у нас обычно из технарей, сами программисты и концентрируются на коде, а не на людях. А тут нужно и то, и другое :)

менеджерам задача ясна

а шо делать нам, программистам?

Вроде везде старался рассматривать и со стороны программистов, и со стороны менеджеров. Так что задумался. В каких именно ситуациях?

Что изучать?

Языков / фреймворков / библиотек сейчас очень много. А времени, почему-то, мало. Что же учить? А для чего?

Если для себя — то всё равно что. Хоть фортран, хоть монады — лишь бы интересно было.
Если для дальнейшей работы или для трудоустройства — то лучше что-то из тех технологий, которые сейчас вверх лезут. Кмк, это JavaScript и Python.

Классный совет. Мне нравиться. Дайшь новую Индию. 5-7 лет и слово «индуссокод» будет заменено на «украинокод».
А не, в Индии и такие продукты как Matlab разрабатывают.

Вот support.upwork.com/…​/en-us/articles/235060368 ссылочка. В разделе «Who qualifies?» там есть списочек, который неплохо коррелирует с тем, что в статье.

Web Development: Ruby on Rails; Python using Django; Javascript using Angular, React, Backbone, or Ember; PHP; WordPress
Mobile Development: iOS using Objective-C, Android using Java

А что касается индусского кода, он, насколько я знаю, отлично пишется на любом языке. Я недавно видел вполне индусский код, написанный на C#. Тут не в языке дело. :)

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

Полностью согласен с первой частью, со второй — хочу подумать. ПТСР — тоже только в голове, а проблемой точно является.

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

А как еще может быть с английским у явного (см. рисунки) визуала? Это поправимо! ))

Поправимо. Вот взял себе ученика на войтивайти. Я его учу Ruby, он меня — английскому. Учитель физики в LA, нэйтив-спикер))

Я в своё время сорвал джек-пот — меня с английским окончательно вывела в люди американка, которая в ВК искала людей, которые могли бы ей помочь с изучением украинского. У меня был уже достаточный уровень английского, чтобы объяснить ей нашу фонетику и грамматику, а она мне дала беспрецедентную (по часу в день с носителем языка) практику английского и исправила наши самые распространённые ошибки (опускания артиклей, игнорирование межзубных, неиспользование Present Perfect Continuous), после чего я заговорил с заказчиками в темпе обычной речи, ненапряжно...

Подписаться на комментарии