Отдыхайте

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

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

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

Мне рассказывали про коллегу, который работал по 16 часов в день и заработал себе инсульт - и это в 30-летнем возрасте. Чувак выжил и… продолжил работать по 16 часов.

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

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

Про экспертов-новичков

Однажды я наткнулась на статью на Хабре про такого зверя как expert beginner. И сразу заподозрила, что речь идёт обо мне. Это был первый пинок к смене работы.

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

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

Когда я устроилась на ту работу, у меня был нулевой опыт разработки на реальных проектах. Код я писала как умела и как получалось. Хороший он или нет - судить было некому, так как никто мой код не ревьюил и в глаза не видел. Так что решения о том, что хорошо, а что плохо приходилось принимать самостоятельно, наступая на грабли и учась на своих ошибках. И вот работала я так, работала, и однажды я уже - типо старший специалист, и у меня уже даже появились свои джуниоры. А я тогда даже тестов к своему коду не писала.

Но я вполне себе догадывалась, что это только по меркам нашей «сельской библиотеки» я сеньор-разработчик. А кто я на реальном рынке? Что я знаю о том, как устроены процессы и разработка в более современных и топовых компаниях (кроме того, что слышала о них на конференциях)? Что я вообще знаю о best practices в IT? Умею ли я вообще писать код?

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

Тогда я сменила работу. Конечно, к тому были и иные причины.

- А в итоге - если ты новичок-эксперт, это замедляет развитие?

Конечно. Нет ничего зазорного в том, чтобы быть просто новичком. Но новичок, который считает себя экспертом - это уже искаженное восприятие самого себя. Из этого искажения рождаются неверные установки из серии «я лучше знаю», «я это делаю n лет, мне виднее», и «я и так знаю, как делать правильно, зачем мне учиться/спрашивать чье-то мнение» итд итп. А все привычные лично ему решения кажутся оптимальными - не потому что они таковыми являются, а потому что «я всегда так делал». А на самом деле ничего ты не знаешь, Джон Сноу.

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

Я, конечно, утрирую. И всё сильно зависит от адекватности конкретного человека. А посыл поста был в том, что не стоит спешить надевать корону и почивать на лаврах. Даже если у вас хороший авторитет среди коллег. Задайте себе вопрос - а ̶к̶т̶о̶ ̶я̶ ̶б̶е̶з̶ ̶к̶о̶с̶т̶ю̶м̶а̶ кем бы я был в другой компании (гугле/яндексе/подставьте другое известное название)? В стартапе из 5-ти человек вы, возможно, действительно - лучший. Но так ли вы круты по меркам всего рынка?

Кто-то остаётся на должности «эксперта», потому что ему нравится наслаждаться своим авторитетом и вертикальным карьерным ростом. И это тоже выбор - у всех свои приоритеты. Есть еще вариант - оставить разработку и уходить целиком в управленческие задачи, тогда экспертиза уже и не так важна. Мне же хотелось расти в техническом плане и чувствовать себя заслуженно… ну хотя бы нормальным средним специалистом, а не псевдоэкспертом с завышенным чсв.

- Как спорить с такими грозными [начальниками]? Отстаивать свое мнение. Не принимая во внимание сложный характер, может есть какой-то лайфхак?

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

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

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

Если же начальник остался при своем мнении - то не стоит переживать. Потому что ответственность за принятое решение и за его последствия - тоже на нём. В принципе мы всегда делаем всё так, как решило руководство - такая судьба у наёмных работников. Другое дело, что аргументировать и переубеждать начальство - это полезный и важный навык.

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

Как понять, что IT - это «моё»?

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

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

То, что меня может в каком-то виде интересовать IT мне никогда не приходило в голову. В школе информатика была очень слабой, уроки не вселяли энтузиазма, а какие-то зачатки бейзика и паскаля, которые там всё же пытались нам дать, я благополучно пропустила мимо себя, даже не пытаясь разобраться, что это такое. Впервые открыла для себя программирование я примерно в 23-24 летнем возрасте, и пожалуй что случайно. И всё ещё не могла решить для себя - «моё» это или «не моё».

Позже я сформулировала для себя такой принцип выбора профессии: если я могу заниматься каким-то делом 3-4 часа подряд (и более) без насилия над собой - значит, оно мне подходит. Потому что примерно так будет выглядеть каждый день жизни, когда устроишься на работу. С программированием у меня всё было именно так - закапываешься в какую-то задачу, ищешь решение, и не замечаешь, как проходит несколько часов. Никакой боли или скуки этот процесс не вызывал, наоборот - довольно увлекательно и интересно - а значит подходит, можно брать. Хотя в теории меня и пугала перспектива целыми днями копаться в коде.

А громких слов о поиске своего призвания и следовании за мечтой я до сих пор не понимаю. Вместо IT у меня могло бы легко быть что-то другое. И у вас, скорее всего, тоже. Но в наше время это одна из самых передовых областей, так что почему бы не выбрать её?

О чем спросят на техническом собеседовании?

Тут всё всецело зависит от собеседующего и его ̶з̶а̶с̶к̶о̶к̶о̶в̶ взглядов.

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

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

Везде, разумеется, зададут вопросы (или задачку) на знание вашего языка программирования. Вопросы могут быть базовые на знание основ, но кто-то любит копать и в тонкости: например, питониста могут попросить написать декоратор и генератор и поинтересуются, что такое метакласс. И да, не исключено, что после собеседования на этом месте работы вы ни разу больше не напишете ни декоратор, ни генератор (или 1-2 раза за 5 лет), и, тем более, никогда не столкнётесь с метаклассами. Именно поэтому такие задачки считаются очень спорными.

Есть еще стандартный список вопросов для каждого языка - они легко гуглятся вместе с ответами на них. Для питона, например, это «что такое GIL» и «как работает garbage collector»? Проблема с такими вопросами в том, что кандидаты часто выучивают ответы чуть ли не наизусть. Но проницательный работодатель догадается задать уточняющие вопросы и копнуть чуть глубже, чтобы понять - действительно ли кандидат знает, о чем говорит или загуглил список типичных вопросов перед собеседованием. Кто-то же намеренно избегает расхожих вопросов. Ну а кто-то примет тупо выученные ответы за чистую монету. Лично я, кстати, ни разу не готовилась к собеседованиям специально - говорят, почти все готовятся - ну а мне это в голову не приходило, и ничего. Я, конечно, никого не призывают брать с меня пример в этом смысле.

На счёт алгоритмов тоже кипят споры - надо или не надо про них спрашивать? Если спрашивать - то, наверно, про самые простые? Отсортируй массив «пузырьком». Вот только зачем «пузырьком»? Я не уверена, что сходу вспомню, чем там этот пузырек отличается от сортировки вставками, а та от сортировки выбором. Да и кому они нужны, эти типы сортировок, они же все с квадратичной сложностью. Но просить реализовать на собесе merge sort или quick sort - это уже сложновато. Поэтому «пузырёк». «А сколько раз в своей работе ты использовал эти алгоритмы? Ни разу, верно?» - спрашивает один коллега другого, сторонника таких вопросов.

В целом я бы разделила всех собеседующих на Знаек и Незнаек. Знайки убеждены, что любой кандидат должен знать всё, если не более того. Написать на бумажке реализацию красно-черного дерева - раз плюнуть, знать ассемблер, C++ и устройство микроконтроллеров - маст хэв. И пофиг, что чувак пришел сайты писать на, прости господи, PHP. Ещё он должен уметь написать накопленную сумму на чистом SQL, знать все мыслимые и немыслимые разделы высшей математики на 5+ ну и, конечно, уметь летать.

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

Но не пугайтесь - знаек не так уж много. И лично я с вопросами такой сложности на собеседованиях ни разу не сталкивалась. Найти кандидата, подходящего под критерии таких Знаек сложнее, чем найти любовь всей жизни с первой попытки в Тиндере. Поэтому нереалистичные требования в итоге приходится смягчать (если, конечно, работодатель не Павел Дуров). Конечно, круто, если у вас сильная база, но если вы не во всем сильны - это не беда. Работы на всех хватит.

За офисный планктон замолвлю слово

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

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

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

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

3. Перенимание опыта. На работе можно встретить классных профессионалов, и учиться у них (удаленно осуществить такое сложнее). Это могут быть и очень сильные технические специалисты, и менеджеры, и люди с развитыми soft-скиллами. Наблюдаешь, например, за начальником отдела, и видишь, как он умело общается с подчиненными, как умеет к каждому найти индивиуальный подход и замотивировать. И учишься у него этим навыками. Смотришь на других руководителей и понимаешь, какие именно личностные качества и знания позволяют ими управлять людьми и разруливать разные ситуации, добиваться высоких результатов. И так ты тоже приобретаешь некоторые компетенции рукводителя. Да, разумеется, речь идёт именно о сильных профессионалах, если таких у вас на работе нет - то есть вероятность, что ловить там действительно особо нечего.

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

Так что офис может быть не таким уж плохим местом, потому что офис - это не бетонная коробка, офис - это люди, с которыми мы работаем, и если люди там классные, то и работа будет в радость (по крайней мере первые пару лет 🙂 )

- Вас так быстро нашла HR прежде всего потому, что вы прошли за два года некоторое количество курсов по матану и computer science? Что ее заинтересовало в вашем резюме прежде всего?

Я не экстрасенс, и точно не скажу, что именно зацепило взгляд HR. Скорее всего, ей дали задание найти разработчика и ключевые слова, по которым надо искать (sql, python итд). Ключевые слова совпали с моим резюме, вот и вся загадка.
А связалась она со мной так быстро, скорее всего, потому, что на рынке IT царил и будет царить дефицит - искать людей очень сложно, и обращают внимание на всех (разве что кроме тех, у кого в резюме есть что-то откровенно отталкивающее).


- В ОС, протоколах и базах данных я разбираюсь, мне казалось даже странным это подчеркивать в резюме.

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

- Но вот с C не сталкивался никогда, с памятью и указателями не работал. И непонятно, тратить ли на это время сейчас, пока ещё не работаю в IT.

Знаете, универсального ответа тут нет. Не факт, что вы когда-то столкнётесь с Си на работе - это зависит от специфики проектов, над которыми будете работать. Например, для веб-разработки Си понадобится вряд ли. Если хотите быть в тренде (и выбирать простые пути), более востребованным может оказаться, например, Go. Но как база знание Си - это хороший навык. Когда начнёте работать, вряд ли у вас будет время и ресурсы на его изучение (если не возникнет острой необходимости). Утверждение, что вы не работали с памятью звучит немного странно - наверно, вы имели в виду, что вы не выделяли и не освобождали память явными вызовами, как это делается в Си.

- Или лучше, например, в паттернах разобраться.

А вы уже освоили ООП? Пишете большие классы и проектируете относительно большие программы с иерархией классов? Если да - то паттерны пригодятся. Если же вы пока на уровне небольших скриптов, или делаете всё в рамках готовых фреймворков (типа django в питоне), то паттерны на этом этапе применять будет особо негде. Это не значит, что их не стоит изучать вообще. Я лишь о том, что не факт, что это первый приоритет на этом этапе (а я даже не знаю, какой у вас этап).

Я маленький, глупый и ничего не умею

Часто начинающие разработчики приходят на свою первую (или не первую) работу с такой установкой. Психологически это вполне понятно и объяснимо. Но из этой неуверенности в себе вырастают неправильные установки и дезадаптивное поведение (которое мешает и вашему росту как специалисту, и команде, частью которой вы теперь являетесь).

Приведу примеры такого поведения вместе с более правильной стратегией.

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

У вас вызывает сомнение какое-то решение? Непонятно, почему другие разработчики выбрали именно его? - Не молчите. Выскажите свои сомнения. Попросите обосновать. Если вам что-то неочевидно или непонятно, значит эти моменты заслуживают пояснения. Вполне возможно, что вы правы. Да, вы, именно вы, а не вон те умные и опытные разработчики. Мышление - вещь коварная, и новый человек может помочь взглянуть на проблему под другим углом, который упускают люди, долго занятые в проекте. К тому же ваши вопросы помогут быстрее войти в курс дела и разобраться в проекте.

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

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

Верно? Неверно. Снимите подгузник и вытрите слезы. Есть идея - предложите её коллегам. Даже если она им не понравится, и они её раскритикуют - у вас будет шанс узнать, что в этом решении не так (не забудьте попросить обосновать их возражения), и что вы не учли, когда думали о проблеме.

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

Напоминаю, вопросы от начинающих (и будущих) айтишников можно задать в боте: @hum_it_bot.

Про эффективность кода

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

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

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

При написании кода нужно помнить о том, что любая программа всегда завязана на ресурсах компьютера - она использует память, ядра процессора и диск. Поэтому не стоит, не задумываясь, читать файл размером в 20 Гб в память - есть ли у вас эти 20 Гб памяти, и оправдано ли их использование в этом случае? От использования этих ресурсов (в частности, от него) зависит и время исполнения кода.

Приведу пример такого необдуманного кода от джуниор-разработчика. Задача была - прочитать построчно большой файл и каждую строку обработать определенным образом. Человек написал код, который выполнял эту задачу, но максимально медленно и неэффективно. В файле было 500 тысяч строк. Разрабочик написал цикл, который выполнялся 500 тысяч раз. В ходе каждой итерации вызывался метод read() (прочитать весь файл в память). То есть, огромный файл был открыт, закрыт и прочитан 500 тысяч раз, а не 1 раз. Во время каждой итерации вызывался метод skip(), чтобы пропустить нужное количество обработанных ранее строк - на первой итерации 0, дальше 1, потом 2 и так далее. То есть метод skip был вызван так же 500 тысяч раз.

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

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

Другой пример от этого же разработчика: в реляционной БД есть таблица с индентификатором id. По этому полю построен индекс, что позволяет, зная id, находить нужную запись в БД мгновенно. Про индексы и их роль в БД разработчик знал из университетсткого курса, но пока не понял, как это знание использовать на практике. В общем, получился у него SQL, который работал очень медленно, и когда я посмотрела, в чем там проблема, оказалось, что разработчик конвертировал id (число) - в строку, и использовал эту строку в запросе. Но вот беда, индекс-то построен по числовому полю, а со строкой работать не умеет. Поэтому теперь, чтобы найти запись с id «5» - базе данных нужно было прочитать все записи в таблице (например, их там миллионы), конвертировать каждый id (из миллионов) в строку - и сравнить его с искомым. Сколько времени потребуется на это базе данных зависит в основном от её размера.

Так что если ваш код работает очень медленно, скорее всего, причина лежит где-то на поверхности.

Рекурсия для гуманитариев

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

Попробую рассказать про рекурсию максимально просто (для более интеллектуальных и подробных объяснений ищите статьи и видео в Интернете, и всё должно проясниться) для тех, кто ещё не разобрался.

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

Давайте возьмём для примера функцию «сумма элементов списка» (или массива).
sum(lst) - можно ее определить итеративно, пройдясь циклом через все элементы списка. (for x in list: result += x)

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

1) Если список пуст, то сумма равна 0. - Это граничное условие, оно должно быть не рекурсивным, потому что в этой точке цикл выполнения функции закончится, и рекурсия остановится.

2) Если список не пуст, то сумма равна первому его элементу + сумме оставшейся части списка.

На питоне это будет выглядеть примерно так:

def rec_sum(lst):

if lst == []:
return 0

return lst[0] + rec_sum(lst[1:])

Давайте представим, как будет выполняться такая функция со списком [1,2,3]

1) Первый вызов rec_sum([1,2,3]) - вернёт 1 + rec_sum([2,3]))
2) Второй вызов вернёт 2 + rec_sum([3]).
3) Третий 3 + rec_sum([]) - здесь рекурсия заканчивается, с пустым списоком функция вернёт ноль.

То есть, выполнение разложится на этапы так:
rec_sum( [1, 2, 3]) = 1 + rec_sum([2,3]) = 1 + 2 + rec_sum([3]) = 1 + 2 + 3 + rec_sum([]) = 1 + 2 +3 + 0 = 6

После того, как функция разложится на такую цепочку рекурсивных вызовов и достигнет дна рекурсии, каждый вызов функции начнет возвращать значения - начиная с самого нового, самого последнего вызова (то есть с пустым списком):

rec_sum([]) возвращает 0
rec_sum([3]) возвращает 3 + то, что вернула rec_sum([]) = 3 + 0 = 3
rec_sum([2,3]) возвращает 2 + то, что вернула rec_sum([3]) = 2 + 3 = 5
rec_sum([1,2,3]) возвращает 1 + то, что вернулось на предыдущем шаге, то есть 1 + 5 = 6

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

Напоследок добавлю print в нашу функцию, чтобы наглядно показать, что происходит, когда мы её вызываем на каждом этапе:
[21]: def rec_sum(lst):
...:
...: if lst == []:
...: print('returning 0')
...: return 0
...:
...: print('next: {} + rec_sum{}'.format(lst[0], lst[1:]))
...:
...: ret = lst[0] + rec_sum(lst[1:])
...: print('returning {}'.format(ret))
...: return ret
...:

In [22]: rec_sum([1,2,3])
next: 1 + rec_sum[2, 3]
next: 2 + rec_sum[3]
next: 3 + rec_sum[]
returning 0
returning 3
returning 5
returning 6
Out[22]: 6

В общем, всё как я и описала.

P.S: Пример выше исключительно для демонстрации рекурсии. С точки зрения продуктовой разработки, рекурсия со слайсами списка в питоне - очень неэффективное и ресурсозатратное решение. Используйте циклы 🙂

P.P.S: А вот в функциональных языках программирования есть оптимизации на уровне компиляторов для эффективного выполнения хвостовой рекурсии. Вот только кто использует этот ваш Haskell в проде?

Про корпоративы

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

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

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

Как наши установки мешают росту

Условно образ мыслей любого человека можно поделить на два типа - «неподвижный» (fixed mindset) и «нацеленный на рост» (growth mindset).

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

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

Противоположный тип мышления - это growth mindset. Такие люди не рассматривают себя как набор качеств, которые нельзя изменить. Они считают, что человек - это процесс, и чем больше ты вкладываешься в этот процесс, тем больших высот можешь достигнуть. Их подход - «у меня плохо с математикой пока, но я работаю над этим». Препятствия и трудности на пути они воспринимают как нормальные стадии роста, и проявляют настойчивость в их преодолении. Потому что рост - это бесконечный процесс, и всегда можно стать лучше. Если ты в чем-то не силён, это значит, что ты раньше не уделял внимания этой области, и это всегда можно исправить.

Думаю, вывод ясен: меньше ярлыков - больше роста. А еще хвалить и поощрять (и себя самого и, например, своих детей) лучше не за стабильные качества («ты умный»), а за усилия, которые человек прикладывает. За то, что вкладывается в процесс своего развития.

P.S.: Мысли позаимствованы вот из этого видосика: https://www.youtube.com/watch?v=Yl9TVbAal5s&feature=youtu.be

IT - это опасно

Пишу не с целью напугать новичков, а чтобы призвать к бдительности. Старинная народная мудрость гласит «семь раз SELECT, один раз UPDATE». И не зря.

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

Как быть осторожнее? Ну во-первых, если у вас есть доступ к продакшену, подумайте, а действительно ли вам нужен этот доступ? Может есть, например, какая-то реплика или тестовая копия базы данных и можно там провернуть свои опасные манипуляции? (любые манипуляции на проде - опасны) Да-да, даже с помощью обычного SELECT можно сломать продакшен - если он окажется очень тяжелым и будет долго выполняться.

Во-вторых - если речь идёт о базе данных, и вы как раз собираетесь в ней выполнить руками UPDATE или DELETE - остановитесь. Подумайте, что вы сейчас хотите сделать и зачем? Почему вы собираетесь менять вручную данные на проде? Что вас привело к такому решению? Может, не надо? Может, лучше у кого-то спросить, как решить проблему по-другому? Дальше, если это вас всё-таки не остановило - вспомните о такой штуке как транзакция - и выполняйте скрипт внутри неё, чтобы можно было потом изящным движением руки полностью откатить изменения. После изменения или удаления строк выполните SELECT и проверьте, что все ок, и только тогда закрывайте транзакцию. Для тех, кто в танке - транзакция открывается волшебной командой BEGIN; И откатывается с помощью ROLLBACK.

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

Часто ошибки происходят от того, что человеку банально лень разбираться с инструментом, который он использует. Так что если вы сейчас собираетесь выполнить команду в командной строке (извините за эвфемизм) - убедитесь, что вы понимаете, что эта команда делает и как работает - не удалит ли она нужный файл, не перезатрёт ли данные. Почитайте документацию - и только потом действуйте. На моей памяти юные падаваны ухитрялись даже удалить коммиты из git-а, потому что не стали затруднять себя чтением документации и не до конца понимали, что конкретно делает та или иная команда гита. Оказывается, даже гит - это опасно. Будьте аккуратнее с гитом. Не действуйте наугад. Мир технологий - это мир знаний и логики, а не Хогвартс, тут нужно разбираться, что и как работает.

Как усидеть за работой?

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

Одна из них - это увлечься какой-то интересной и сложной задачей, и погрузиться в неё часов на 5-6-8-10. Особенно если работаешь из дома, и ничто не отвлекает. Это всё без перерыва, без обеда и практически без движения. Когда наконец отдираешь своё тело от стула, с удивлением замечаешь, что уже поздний вечер, ноги и 5-я точка затекли, а желудок ноет от голода. И состояние разбитое, даже если чувствуешь какое-то удовлетворение от проделанной работы.

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

Для самочувствия, настроения и результативности работы в конечном итоге вредны оба состояния. А решение для них одинаквое.

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

Когда срабатывает таймер - самое лучшее - это в первую очередь оторвать попу от стула и пройтись - хотя бы сходить заварить чая или попить воды, выйти на улицу, в магазин, куда угодно еще. Если вообще нет никаких дел, чтобы за ними идти - то хотя бы пару кругов по офису навернуть, прежде чем снова занять сидячее положение. Дальше можно некоторое время провести за любыми посторонними делами - посмотреть картинки, поспорить в Интернете, там ведь опять кто-то не прав! Позвонить жене, мужу, маме, брату или другу детства. Проверить заказ в Интернет-магазине. Оплатить ЖКХ. Ответить в чате друзьям. А если руки тянутся к коду и глаза уже смотрят в текстовой редактор - значит ставим таймер на следующие полчаса (или другой интервал, который вам подходит) и переходим к фазе работы.

Главное - не смешивать фазы отдыха и работы. Не продолжать решать рабочие задачи во время перерыва, и не отвлекаться на посторонние раздражители во время работы.

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

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

Про( )активность

Вы, вероятно, уже где-то слышали такое модное слово как проактивность. И о том, что в современном мире IT бывает такое, что технические навыки (hard skills) не всегда играют решающую роль в том, возьмут ли кандидата на работу. И что собеседующие могут обратить внимание на soft skills и, в частности, на пресловутую проактивность.

Так что же это такое? Глубоко копать не буду, кажется, «бытовое» использование этого слова уже несколько ушло в сторону от первоисточника. Расскажу о смысле, который по сути вкладывают в это слово в IT-компаниях. Быть проактивным - значит брать на себя ответственность и проявлять инициативу тогда, когда это не обусловленно твоими прямыми обязанностями (и когда нет никакой внешней необходимости к этому). Это в том числе и готовность признавать свои ошибки, и работать над развитием личностных качеств, а не оставить всё как есть и спокойно плыть по течению, и сказать потом, что это «оно всё само», «я не виноват».
То есть это противоположность пассивности, инертности, бездействию и желанию переложить ответственность на кого-то другого. Как и вере в то, что от тебя ничего не зависит.

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

Приведу несколько примеров:

- Новичка позвали на совещание по техническому вопросу. Он всё совещание молчит. Можно предположить, что он хотя бы слушал. Позже оказывается, что и это не так - он ничего не понял и подумал, что ему это всё не нужно. - Что можно было сделать - Задавать вопросы. Выяснить, что сейчас обсуждают, и какова цель встречи. Прояснить все непонятные для себя моменты. Если ты пока не готов предложить свою идею, то хотя бы будь в контексте. Вовлеченность ценится выше, чем пассивность, которую могут трактовать как раздолбайство и лень.

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

- Вы видите, что не работает Интернет, или локальный git-репозиторий упал. А ну и фиг с ним! Пойду лучше кофе пить. Или всё-таки сходите к админу и расскажете о проблеме?

- Вам нужен корпоративный пароль для доступа к нужному сервису. Вы написали админу, он сказал ок, а потом молчит. Молчит день, два, три - ну и пусть молчит? Подождёте, пока он сам вспомнит - или напомните ему о себе?

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

Напоследок, про пассивность и робость: в США (кажется, там) произошел случай, когда пациентке во время операции по удалению гланд хирург по ошибке удалил часть ступни. И проблема не только в самом хирурге. Проблема в том, что все его ассистенты, медсестры и другой медицинский персонал всё видели, но побоялись спросить - что, собственно, происходит. Поэтому не бойтесь открывать рот, не бойтесь проявлять инициативу и брать на себя ответственность за происходящее - однажды это может спасти кому-то жизнь (ну или спасти проект).

Друзья, помогайте! Если вы новичок в IT - недавно начали работать в этой области, или пока только учитесь, но не работаете. Или если вы еще не начали изучать IT, но задумываетесь о таком направлении развития - то наверняка у вас есть вопросы о работе в сфере IT, о трудностях, с которыми (не) сталкиваются новички, о том, что вас там ждет и как себя вести в тех или иных озадачивающих ситуациях. Все вопросы можно писать в бота - @hum_it_bot. Ответы на самые интересные вопросы появятся в будущих постах. Только на вопрос «Какие книги и курсы посоветуете?» отвечать не буду, так как в блоге уже было несколько постов на эту тему. =*

Всем спасибо за вопросы! Вопросов много, разгребать буду постепенно. Бот открыт для вопросов - присылайте ещё, не стесняйтесь!

Начну я с блока условно психологических вопросов про работу в IT. Сразу оговорюсь, я не психолог и не психотерпевт, и всё ниже - либо моё личное мнение (не обязательно верное), либо информация, почерпнутая из разных источников - из книг, от психологов, в ходе терапии итд.

- Как поставить сексиста на место, когда ты новичок? То есть плохо у тебя получается не по той причине, что ты женщина, а по той, что новичок?
Думаю, это вопрос можно обобщить до «Что делать, если коллега ведёт себя неподобающим образом и причиняет мне дискомфорт»?

Для начала, определимся с целью. Если цель - эскалация агрессии, раздувание конфликта и месть коллеге, то вы сами догадаетесь, что делать. 🙂

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

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

Факты -> Описание своих чувств, которые вызваны этими фактами. -> Рассказ о ваших потребностях/ценности, которые таким образом нарушены. -> Просьба, обращенная к коллеге, которая вытекает из предыдущих пунктов

То есть в случае с сексистским поведением коллеги это будет выглядеть примерно так:
1. Факты: «Сегодня ты рассказал шутку про … , вчера прокомментировал …». - Тут только голые факты, без оценок, без обобщений - перечисление конкретных поступков человека.
2. Чувства: «Меня огорчают такие шутки, потому что я в них слышу уничижительное отношение к женщинам, а я сама женщина, и, следовательно, эти шутки относятся и ко мне. Мне сложно сосредоточиться на работе после такого, потому что я бываю расстроена.» - Рассказ о чувствах делают в формате «Я-послания». Слово «ты» и обвинений здесь не используют, просто говорят, какие эмоции у вас есть в связи со сложившейся ситуацией.
3. Потребности и ценности. «Я хочу работать в комфортной атмосфере, где все коллеги уважают друг друга, и где не принято завуалированно оскорблять кого-либо.» - Описать, чего вы хотите достичь.
4. Просьба. «Поэтому я хотела бы попросить тебя избегать оскорбительных высказываний, основанный на поле человека»

Это первая фаза. Скорее всего, адекватный человек прислушается к вежливой просьбе и пары таких разговоров будет достаточно. Если же ничего не меняется, и поведение коллеги продолжает причинять дискомфорт, дальше идут фазы с эскалацией конфликта. Алгоритм примерно такой же как и раньше, Я-послания можно усилить, а в конце добавляется еще один пункт - угроза применения санкций (не знаю, какие санкции можно применить к коллеге, это надо придумать - например, прервать всякие контакты с ним, отказаться общаться с ним устно, а на рабочие запросы реагировать только по email с руководителем в копии получателей). То есть в конце будет еще пункт про «Если ты не перестанешь так делать, я…». Говорить нужно настойчиво и твёрдо, но по-прежнему вежливо.

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

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

Всем привет! Продолжаю отвечать на ваши вопросы. Напоминаю, вопросы можно присылать в бота: @hum_it_bot.

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

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

С чего начать человеку, который был далёк от IT, но хочет начать изучать?
У меня гуманитарное образование, стоит ли ставить на себе крест?
Сложности возникли со структурой: с чего начать, как практиковаться, если ты до этого не сталкивался ни с чем подобным, а школьная и университетская информатика была на уровне: «включите комп, подключайтесь к wi-fi. Поздравляю, можете заниматься тем, чем хотите. А, точно, wi-fi же у нас нет... ну рисуйте в Paint или пяльтесь в паук-пасьянс…»

Вы так говорите про гуманитарное образование, как будто это какой-то диагноз, или инвалидность. Образование - это набор знаний и навыков, а не клеймо. Не думаю, что полезно рассматривать его как препятствие на пути к новым знаниям или другим навыкам. Для меня это звучит как «я умею кататься на велосипеде, значит ли это, что я не смогу научиться чистить картошку?». У меня тоже гуманитарное образование. А в университете на информатике мы рисовали кораблик в Paint. И ничего, живу. И даже код пишу за деньги. 🙂 Сейчас вообще набирает популярность идея lifelong learning или непрерывного образования - учиться всю жизнь и менять профессию каждые 5 лет.

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

Какой язык программирования сейчас самый популярный?

Всё зависит от того, что вы хотите разрабатывать. Если, к примеру, мобильные приложения под Android - то Java. Под iOS - кажется, Swift. Если хотите делать сайты (фронтенд) - то Javascript и разные фреймворки и либы на нём (jquery, React, Angular, Vue и другие). Если интересует бэкенд-разработка - то тут из простых вариантов - Python, и, пожалуй, Go. Многие сайты всё ещё написаны на PHP, и он остаётся востребованным языком, но к нему многие относятся свысока.
Одним из самых востребованных и распространенных языков (и многими нелюбимых) языков остаётся Java. В платформе .Net используют C#, и не только. И есть еще мощная «золотая классика», которая не сдаёт своих позиций - C и C++. Для Data Science обычно используют Python или R. Это, пожалуй, самые частые варианты.

P.S.: для работы с базами данных - SQL - этот нужен почти всем.

Всем привет! Продолжаю отвечать на ваши вопросы. Напоминаю, вопросы можно присылать в бота: @hum_it_bot

Как сохранить в себе терпение изучать программирование?

Поскорее переходить от чисто учебных и не практических задач к реальным проектам - более интересным и более сложным. Например - найти себе какую-нибудь стажировку или part-time подработку на джуниорской позиции. Поучаствовать в каком-нибудь хакатоне. Принять участие в разработке open-source проекта. Или заняться своим личным проектом - написать свой сайт или бота, или мобильное приложение. «Мне еще рано, я еще не умею» - плохие оправдания, всё, что нужно знать - легко гуглится в процессе разработки.

Как справиться с ужасом и тревогой которые мешают процессу обучения (
Очень сложно учить новое так как всегда кажется что я бесконечно отстала и никогда не догоню ((
А еще немного стыдно что у меня уже возраст 🙈 мне неловко спрашивать простые вещи у коллег так как вроде как такие штуки уже все знают(

Похоже, тут скорее проблема в неправильных установках. Когда недостаток знаний, опыта или скиллов воспринимается как неизлечимая болезнь. Такие установки мешают росту в любых начинаниях - например, не умеешь плавать - значит никогда не научишься, не знаешь иностранного языка - значит никогда не сможешь его выучить. Попробуйте к каждой мысли про «я не умею» прибавлять в конце слово «пока». «У меня [пока что] получается хуже, чем мне хотелось бы», «Я [пока еще] мало знаю». У меня был пост про два типа установок мышления - вот тут.

Если тревога и, как вы описываете ее - ужас - очень сильные, возможно, стоит обратиться к психотерапевту, такие страхи могут сильно портить не только процесс обучения, но и качество жизни в целом. А пока подкину одну из практик когнитивно-поведенческой терапии: когда вас одолевают тревожные мысли - запишите их (или хотя бы мысленно обратите на них внимание). Например: «Я не смогу ничему научиться, потому что мне уже много лет». Таких должно получиться 3-5 штук. Потом попробуйте придумать несколько альтернативных мыслей про то же самое - например, «Я смогу все освоить, когда что-то не получается с первой попытки - это нормально.» И потом задайте себе вопрос - какую пользу можно извлечь из первой мысли? А какой вред она может принести? Потом те же два вопроса про вторую (альтернативную) мысль. Пользу и вред каждого набора мыслей тоже запишите (или запомните). И проделывайте это каждый раз, когда тревожные мысли к вам возвращаются.

И наконец - «все уже всё знают» - это большое заблуждение. Даже опытные разработчики часто ничего толком не знают (но хорошо умеют гуглить). А ваши сокурсники вряд ли уже - очень опытные и знающие разработчики. Так что стыдиться (особенно перед ними) вам нечего. Вас волнует, что другие о вас подумают? А какая разница? Возможно, этих людей вы больше никогда не встретите в своей жизни. Лучше сосредоточьте внимание на процессе своего обучения - а вопросы пойдут ему на пользу. Нет ничего стыдного в том, чтобы задавать вопросы. Если кто-то на них реагирует недоброжелательно - то это он вредный человек, в нём и проблема. Главное, чтобы вопросы были осмысленными, а не «сделай за меня пожалуйста это задание».