Архив недели
Понедельник
Всем привет, на этой неделе с вами Рома Неволин! Вы можете знать меня по DotNext, DotNetRu, Podlodka Backend Crew и прочим публичным активностям. А еще я занимаюсь DevRel в Контуре!
Темы недели:
Понедельник: о карьере программиста
Вторник: о программировании
Среда: что еще за DevRel?
Четверг: конференции и митапы
Пятница: как рассказывать истории
Суббота: сборная солянка про айти
Воскресенье: концерт по заявкам aka свободная тема
Итак, сегодня мы будем общаться о всяком карьерном! А если детальнее:
- Расскажу о собственном пути
- Поговорим, в чем плюсы и минусы работы без вышки
- Как расти и развиваться программисту?
- Как не свихнуться в процессе?
- И отдельный тред о собесах. Может два
Для начала — тред-введение о том, чем я вообще в этой жизни занимался и как я оказался здесь.
В 11 лет в моей жизни случилось страшное - закончилась детская библиотека. Не то чтобы совсем, но интересных мне книг в ней буквально не осталось. Деваться было некуда и я взялся за неинтересные — одной из таких оказался учебник по программированию.
Учебник рассказывал про Visual Basic на примере разработки какой-то простенькой игрушки с катающимися машинками — накидал формочек, написал какие-то простенькие методы и готово. Но тогда это ощущалось как абсолютная магия.
Этой магией программирование меня и купило. Изначально я планировал быть писателем, ведь ты можешь придумать штуку, описать ее и что-то существующее только у тебя в голове станет почти реальным. С программированием - то же самое, только без почти. Чистая магия и замки из песка.
Лет в четырнадцать я почти случайно заработал программированием первые деньги, лет в пятнадцать еще немного, а с шестнадцати фрилансил уже постоянно. И как-то случайно в фриланс программистский влился еще и фриланс журналистский (пару лет журналистики было даже больше, чем кода)
В это же время я учился в колледже по специальности. Формально. Фактически - курсу ко второму учеба оказалась совсем скучной, к третьему я совершенно забил на пары и возглавил неофициальный рейтинг прогулов (мама, папа, простите!). О плюсах и минусах этого еще расскажу.
До этого момента я ничего не говорил про конкретные языки, потому что писал почти на всем. Самым удобным для меня был C#, одним из самых популярных на фрилансе - PHP, встречалось много Python и Java. Бывала и экзотика вроде стартапа на Haskell.
К восемнадцати я решил, что хватит с меня фриланса и пойду-ка я поработаю на Настоящей Работе.
Первой моей постоянной компанией оказался здоровенный проект на PHP, с которого за месяц уволилось три PMа.
Вслед за ними, через три месяца моей работы, ушел и лид. А дальше произошел мем - каким-то достаточно случайным образом я стал на этом проекте лидом.
Вы смеялись над сеньором в 23? Получите лида в 18, господа!
Еще через три месяца я понял ушедших менеджеров и лида и уволился вслед за ними.
После пошла уже какая-то более понятная карьера с адекватной разработкой на .NET и Java. Кровавый энтерпрайз, продакшен и некоторая примесь машинного обучения.
Кстати, с машинного обучения начались мои выступления на конференциях. Пришел послушать Андрея Акиньшина на шестой что ли встрече SpbDotNet, рассказал Толе Кулакову о своих издевательствах с ML в дотнете и понесла…
Дальше была пара лет в EPAM с разнообразным Life Science, работа в Берлине над платежной системой, прекрасный проект в Revolut (команда процессинга, вы отличные!) и некоторые метания в период пандемии, закончившиеся переходом в DevRel и Контур.
Что мы имеем сейчас? Я развиваю DevRel (читай - коммуникацию с разработчиками) в Контуре. Делаю доклады, пишу статьи, помогаю делать все это другим и придумываю разной степени безумия проекты.
Ну и твиттер веду в рабочее время, разумеется.
Просуммируем: я самоучка, много кодил разного и на разных языках, выступал на конференциях, писал всякое (не только техническое), немного пожил за границей.
О тех выводах, которые я успел сделать из этого хаотичного опыта, я и буду рассказывать ближайшую неделю.
Очень забавно смотреть в уведомлениях, как лайкаются твиты в твоем аккаунте, с твоей фотографией - но написанные другим человеком!
Веселее только заходить в чаты разработчиков и видеть сообщения от Ромы Неволина. У нас их в компании два, понимаете ли. И все кодят.
Мы, кстати, когда-то уже посмеялись над этим и записали разбор задачи Advent of Code с Ромой Неволиным и Ромой Неволиным
youtube.com/watch?v=ytpWst…
Тред о вечном споре, что лучше - учиться в университете или потратить это время на работу и самообучение.
Сразу скажу — я не считаю один из этих вариантов однозначно лучше, а о плюсах и минусах каждого расскажу ниже.
Начнем с важного дисклеймера: без самообучения и кучи самостоятельной практики стать хорошим программистом невозможно.
Не помогут университет, платные курсы, обучение с гуру и астральные практики.
Второй момент - сочетать университет и практику можно.
Лучшие люди, которых я собеседовал в последние n лет, имели именно такой бэкграунд — хороший университет и много практики. Работать они начинали курсе на третьем.
Все ничего, но так можно легко сойти с ума или выгореть.
Итак, дальше о том, на что можно обменять четыре года обучения в университете.
На опыт работы с разными технологиями/архитектурами/языками и прочим в реальных условиях. Зачастую это будет жуть, ад и “никогда так не делайте” - факт. Но такой опыт помогает, например, научиться эту жуть рефакторить. Минусы у этого тоже есть, о них позже
На понимание работы бизнеса. Этому сложно научить в университетах (пока не получается) и для вчерашних студентов программирование - чисто техническая штука, тогда как на работе это инструмент для решения задач бизнеса.
С реальным опытом проще понять, что нужно бизнесу
Опыт коммуникации. Тоже очевидная и понятная штука, чтобы научиться общаться с людьми на работе, нужно общаться с людьми на работе.
А еще это профессиональные знакомства. Знать клевых людей, с которыми можно пообщаться за программирование это полезно.
Стаж лучше смотрится в резюме, чем университет.
Этот пункт очень спорный, понимаю и не настаиваю, но по моему опыту — человеку с четырьмя (или даже тремя) годами опыта гораздо легче найти интересный проект, чем человеку с дипломом и без опыта.
Важное уточнение к предыдущему пункту — есть хак для попадания в топовые компании, стажировки. Но там придется пройти через солидный отбор и некоторый период с не слишком-то большой зарплатой.
И последний пункт, самый интересный. Опыт работы в год дает тебе хорошие шансы понять, нравится ли тебе эта профессия. И уйти, если это не твое.
Я знаю много людей, которые отучились в универе, пришли на реальную работу и поняли, что им это вообще не заходит.
Что особенно грустно — люди после этого не уходят из программирования, потому что «зачем столько лет учился? Да и профессия солидная, платят отлично».
Результат — выгоревшие люди, работающие чисто за деньги. Ничего хорошего в этом нет.
А что хорошего в высшем образовании? Важный момент — тут я размышляю чуть более абстрактно, у меня-то вышки нет. Но зато я прямо сейчас преподаю в УрФУ и много собесил людей с университетским бэкграундом.
Дисклеймер — все написанное ниже относится к хорошим университетам и хорошим студентам.
Есть куча университетов, обучение в которых откровенно не стоит потраченного времени и есть куча студентов, которые не пытаются учиться. Тут обсуждать особо нечего.
В споры о том, где учиться хорошо/плохо и есть ли вообще хорошее айтишное образование в университетах я сейчас влезать не буду. Скажу только, что нравящиеся мне программы в университетах определенно есть.
Например, ФИИТ в УрФУ, где я преподаю сейчас, мне очень нравится.
У хорошего студента гораздо меньше случайных пробелов в знаниях.
Это — вывод, который я сформулировал по итогам собесов. Самоучки выделяются неровностью знаний, они потрясающе отвечают на одни вопросы и ужасно косячат в других.
Почему это важно? Так гораздо проще не привязываться к конкретному стеку, проекту и прочему. Хороший фундамент дает базу и обучаемость. Плюс это база для коммуникации, общий язык и бэграунд.
Второй момент. Восполнять базовые пробелы в знаниях, которые встречаются у самоучек — сложно. Например, я в какой-то момент обнаружил недостаточное знание у себя основ алгоритмов и долго с этим страдал. Потом с базами данных. Сейчас вот с пониманием сетей страдаю.
Другая проблема того же рода — помимо пробелов, кое-где программист с боевым опытом и без крепкого фундамента набирается вредных привычек.
Помните я говорил про опыт на реальных проектах? С этих проектов и набираются. Особенно с учетом того, что первые компании не слишком круты.
Третье. Развитие в университете проще и понятнее, чем развитие самостоятельное. Когда у тебя нет четкой направляющей — очень легко растерять всякую мотивацию, забрести в какие-то странные дебри и там остаться.
Четвертое — университет это социально полезная штука. Это возможность просто общаться с людьми, тусить, заводить друзей, влюбляться и прочее, прочее. Да, это можно делать без универа. Да, это труднее делать без универа.
Просуммирую. Правильное высшее образование формирует хороший фундаментальный набор знаний. В основном именно знаний, не навыков — их нужно вырабатывать самостоятельно. А еще позволяет сделать это без адского превозмогания.
Основной вопрос — стоит ли этот комфортный базис четырех лет обучения? И тут каждый решает сам.
Самое важное здесь — принять это решение осознанно. Выбор универа и программы важен, решение не учиться должно быть осмысленным и так далее.
Еще пара моментов.
В университетах есть стажировки, позволяющие посмотреть на реальность и узнать, как выглядит работа программиста.
Это хорошая штука, но почти всегда задачи на стажировке очень сильно отличаются от задач, которые придется решать большую часть жизни.
Как я говорил в начале, многие студенты начинают работать на третьем-четвертом курсе и получают классный сплав из фундамента и опыта.
Это отличный вариант для вашей карьеры, но не лучший для психики. Берегите себя.
Ну и напоследок. Помните, любые размышления на эту тему постоянно натыкаются на ошибку выжившего.
Я видел потрясающих самоучек без всех описанных проблем. Видел талантливых студентов клевых вузов, убитых шаблонностью обучения.
С любым бэкграундом можно стать отличным спецом
И еще на тему! Мы тут недавно записывали подкаст с
@xoposhiy, который делает тот самый ФИИТ в УрФУ и много там общались про образование и связанные с ним темы. Кому любопытно — вот тут можно послушать.
youtube.com/watch?v=sxAq-a…
Дисклеймер — все написанное ниже относится к хорошим университетам и хорошим студентам. Есть куча университетов, обучение в которых откровенно не стоит потраченного времени и есть куча студентов, которые не пытаются учиться. Тут обсуждать особо нечего.
Важный вывод вот из этого дисклеймера. Вы не смогли поступить в хороший университет? Не поступайте никуда.
Учитесь самостоятельно, работайте, беритесь за любые проекты, даже если вам за это не заплатят. Берите свое практикой. twitter.com/itunderhood/st…
Помните, что заваленный ЕГЭ не делает вас плохим специалистом, не показывает ваш уровень интеллекта и не рушит ваши шансы построить клевую карьеру.
А вот четыре года в плохеньком университете отбирают много времени и могут похоронить всякую мотивацию.
Итак, время для огромного треда о развитии программиста. Как расти и получать новые знания? На что обращать внимание на каждом из этапов развития? Как расти в сеньоры и кто они вообще такие?
Важное. Я всю жизнь пишу код для бизнеса (в разном виде) и хорошо понимаю развитие именно такого разработчика, делающего инструменты для бизнеса. Учтите и примите это перед прочтением.
Начнем с момента, когда вы умеете совсем мало. Написали несколько простеньких программ и базово освоили какой-нибудь язык программирования. Что дальше?
Первое и самое очевидное - пишите код. Да, вы знаете мало. Да, код будет плохой и что-то постоянно будет идти не так. Единственный способ с этим справиться — постоянно писать код. И это иногда будет не так просто делать.
Какой код писать? Я пытался автоматизировать рутинные задачи. Например, писал штуку, которая парсила сайт с новостями и выдавала уведомление, когда появлялась новая запись.
Не, RSS у них не было, увы.
Другой кандидат — простенькие сайты. Свои первые деньги я зарабатывал, делая сайты для кланов в одной онлайн-игрушке. Причем помимо верстки периодически появлялись и более интересные задачи.
Или делать собственный сайт, там вы можете придумывать задачи сами.
Влезайте в безумные идеи ваших друзей, коллег и одногруппников. Тут очень сложно, потому что будет страшно бить синдромом самозванца и «я же ничего не знаю!».
Не переживайте, обычно предлагающие либо знают примерно столько же, либо осознают ваш уровень.
Второе, что важно на этом этапе. Задавайте вопросы. У вас должно быть много вопросов, очень много вопросов, бесконечное-блин-множество-вопросов. Бомбардируйте этими вопросами старших коллег и преподов вообще не стесняясь. Кто-нибудь всегда будет рад объяснить.
Помимо людей бомбардируйте вопросами гугл. Самое важное, чему вы должны научиться на этой стадии развития это находить ответы, потому что вопросы у вас будут появляться каждый день всю дальнейшую карьеру.
Какие могут быть вопросы? Я бы выделил вот такие категории:
- Что сделать, чтобы … (как распарсить сайт, например)
- Как и почему это работает?
- ПОЧЕМУ ОПЯТЬ НИЧЕГО НЕ РАБОТАЕТ?!
Пройдемся по ним.
«Что сделать, чтобы» - один из самых решаемых гуглом вопросов. Почти всегда запрос вида «как сделать x $название языка$» дает вам необходимую информацию.
Иногда ответ содержит непонятные слова, в таком случае нужно действовать рекурсивно и гуглить уже их. Поиск может затянуться.
А что делать, если гугл ничего не выдает, а понять хочется. Берешь программиста поопытнее, задаешь ему вопрос вида «я хочу сделать x, но не знаю как. Что мне вбить в гугл, чтобы получить нужную информацию?».
Дергать людей - можно. Если нет знакомых - можно спросить в интернете
«Как и почему это работает» — вопрос, очень важный для дальнейшей карьеры. Он не про практичность, он про детское любопытство в духе «а почему летают самолеты?».
Можно жить, не зная, как летают самолеты. Но если вы пилот — лучше бы разобраться.
Почему этот вопрос важен для карьеры? Именно он позволит вам собирать хаотичные знания во что-то цельное. Задаваясь вопросом, как работает некоторая штука, вы начинаете понимать некоторые общие принципы.
А еще это бывает попросту интересно.
Как задавать такие вопросы? Их уже куда сложнее находить в гугле, но вы все же пытайтесь. Если не вышло — спрашивайте у людей. Если никто не может/не хочет отвечать — запишите вопрос и спросите при случае, если найдется эксперт.
Иногда еще на stackoverflow отвечают.
И самое актуальное, самое больное — да почему, блин, опять все сломалось?
Так вот, отвечать на него будет сложно всегда. Вообще всегда.
Можно гуглить тексты ошибок. Да, ссылки будут вести вас в малопонятные обсуждения десятилетней давности - это норма.
Можно спрашивать у всех вокруг. Да, вы будете всех отвлекать и вам будут отвечать загадочным «а вот хрен его знает» — это норма. Все так живем.
Можно решать проблему методом научного тыка. Убирать случайные вызовы, заменять вызовы функций, копипастить случайный код со stackoverflow — на текущем этапе это тоже норма.
Самое важное здесь вот что. Вы решили проблему, но так и не поняли, что это было?
Запишите, запомните, попытайтесь узнать. Отныне вы детектив и это ваше нераскрытое дело. Если вы поймете, что это было — станете немного лучше как программист.
Теперь — о том, чего не стоит делать.
Личное мнение. На этом этапе не пытайтесь досконально изучить некоторый язык программирования. Во-первых, пользы от этого будет мало. Во-вторых, вы столкнетесь с кучей непонятных концепций и просто утонете в них.
Язык - это ваш инструмент, и у этого инструмента огромное количество возможностей. Изучайте новые возможности по мере необходимости.
Попытки же сначала досконально изучить язык, а потом начать его использовать приводят к ступору и «а зачем мне вообще нужна эта штука?».
Следующий момент. Не пытайтесь держаться до победного за некоторый язык, технологию или проект, если вам не нравится.
Не идет? Бросайте. Да, так можно. Нет, всегда не будете, что-нибудь да зацепит. Бросаете вообще все? Есть шанс, что вас не цепляет программирование.
Просуммирую. Ваша цель на этом этапе — научиться делать работающие штуки и задавать вопросы. Штуки будут кривые и косые, а вопросы зачастую останутся без ответа.
Но именно здесь вы поймете, что вам нравится, что вы хотите делать и какие вопросы вас интересуют.
Этап второй — от джуниора к крепкому мидлу.
Итак, вы уже умеете писать работающие штуки, можете выполнить простенькое тестовое задание и устроились в некоторую компанию. Как расти дальше — ну кроме «просто делать рабочие таски»?
Для начала разберемся с определениями. Для меня главная характеристика мидла — способность самостоятельно выполнить техническую задачу. Взять таску из жиры, вооружиться кодом, гуглом и такой-то матерью и выдать в результате приличное решение.
Основные нюансы начинаются вокруг определения «приличности» решения, но об этом поговорим завтра. Основной вопрос сейчас — какие навыки есть у мидла и как джуну эти навыки обрести?
Мидл знает свой инструмент. Значительная часть вопросов на собеседованиях будет про используемый вами язык и фреймворк, смиритесь с этим. Вы должны понимать, что ваш язык умеет и как решить поставленную задачу наиболее оптимально.
Как приобрести эти знания?
Всегда задавайтесь вопросом «а нельзя ли сделать лучше?». Код дублируется? Часто случаются дурацкие ошибки? Слишком сложно читается? Слишком медленно работает? Погуглите и поспрашивайте, вдруг можно лучше.
Кстати, к уже написанному до вас коду стоит задавать те же вопросы. И если вы вдруг узнаете, как можно лучше — обсудите это с командой и попробуйте порефакторить. Предварительно покрыв все тестами (о тестах и рефакторинге будет тред завтра).
Обращайте внимание на фидбек. Вам будут писать МНОГО комментариев — в ревью, в личку, в чатиках, как угодно. Это офигенно сложно и создает постоянное ощущение собственной никчемности.
И тем не менее — пытайтесь думать над комментариями, а не просто исправлять.
У каждой технологии есть свои священные книги — прочитать их будет не лишне. Для дотнета, например, это CLR via C# от Рихтера.
Не знаете, что читать? Поспрашивайте у коллег или погуглите. Как можно заметить, это ответ на любое «я не знаю».
Конференции по технологиям — классный способ вникнуть в контекст. Разумеется, билет стоит дорого, а ехать может быть далеко, поэтому дальше будет простой лайфхак.
Открываете сайт конференции
Находите версию годовалой давности (например, 2020.dotnext-piter.ru)
Выбираете интересные доклады в программе и смотрите записи. Они либо будут на сайте, либо найдутся гуглом.
Готово! Работает почти всегда.
При этом постарайтесь не закапываться в конкретную реализацию — обращайте внимание на идею, а не на инструмент. Поймите, как работает ООП, ФП, АОП и прочие концептуальные вещи. Это даст вам большую свободу в выборе и использовании инструментов.
Увидели интересный инструмент, с которым хочется разобраться? Пробуйте. Сделайте абсолютно дурацкий пет-проект, чисто потестить. Поковыряйтесь. Попробуйте применить его к своему проекту, даже если этот код придется выкинуть.
Другой важный технический навык — на этом этапе вы обязаны базово понимать алгоритмы. Сложность алгоритма, затраты по времени-памяти и так далее, хотя бы интуитивно. Просто чтобы не фигачить кучу вложенных циклов.
Дальше идут навыки работы с большими проектами. Перед вами — здоровенная штуковина, работающая непонятно как, делающая непонятно что и раздражающая самим фактом своего существования.
«У пользователя кнопка не работает, надо пофиксить» - ну офигеть теперь!
А делать-то что?
Важнейший навык — декомпозиция. Разбивайте любую большую задачу на маленькие и более понятные. Минимальная задача — это та, которую вы можете выполнить без особых размышлений, почти механически.
«У пользователя не работает кнопка»
- А какая кнопка?
- Как мне найти эту кнопку?
- Как мне попасть на этот экран?
- Понятно, нажать на это меню, ввести вот это, на следующем экране будет кнопка
«А в каком случае она не работает»?
- Ага, вот при таком наборе данных?
- А как мне их получить?
- Хорошо, нужно ввести вот эти три числа в форму и поставить вот такой тип пользователя.
И так далее. У вас большая задача, с которой непонятно что делать? Разбейте ее на много маленьких. Поначалу это будет чертовски сложно, но этот навык тренируемый и является одним из основных в каждодневной работе.
Дальше. Большой проект — это множество взаимосвязанных кусочков. Вам нужно привыкнуть понимать, как они взаимодействуют между собой. Задавайтесь вопросами «а зачем здесь этот вызов? А зачем инжектится этот модуль? А что делает вот эта функция?».
Разбираться с этим сложно, долго и взрывает мозг. Два момента - не переживайте о затратах времени и смиритесь со сложностью, эти усилия окупятся позже.
С каждым годом я трачу все больше времени на интеграцию в новый проект и это ок.
А еще — учитесь взаимодействовать с командой. Пытайтесь понять, какой код люди понимают лучше, а какой хуже. Узнавайте, почему люди делают ошибки и как это предотвратить. Учитесь доносить свои мысли.
Конкретных советов не будет, просто обращайте на это внимание.
Последнее на этом этапе. Зачастую у вас не будет насущной необходимости изучать что-то кроме используемых вами языков и фреймворков.
И все же постарайтесь обращать внимание на технологии за пределами проекта. Сохраняйте любопытство, оно окупается.
Просуммирую. Необходимые навыки на этом этапе — работа с большими проектами, понимание возможностей своих инструментов и умение коммуницировать с командой (через код и ртом).
Итак, мы добрались до сеньорства! Кто такие сеньоры и как ими становится?
Здесь важный дисклеймер — все написанное ниже относится к бизнес-разработке. У рисерча, например, несколько иные задачи. У узких специалистов — тоже.
Для меня сеньор это полностью самостоятельный разработчик, автономная единица. Ему не обязательно давать конкретную задачу, достаточно выделить область ответственности, в которой он должен приносить пользу.
Как таким стать?
Зачем вы делаете задачки? Чтобы сделать бизнесу хорошо. У бизнеса есть некоторые задачи — программист решает их с помощью кода. Чтобы быть автономной единицей вам важно понимать, что нужно бизнесу.
Вдумывайтесь в смысл каждой задачи. Спрашивайте, зачем вы делаете конкретную штуку. Вникайте в задачи вашего продукта, в задачи конкретно вашей команды и так далее. И пытайтесь понять задачи ваших коллег — не только разработчиков, но и менеджеров, дизайнеров, etc.
Изучайте разные ситуации и решения в чужих проектах, по статьям, докладам и просто рассказам на кухне. Постепенное накопление таких идей сформирует у вас набор вариантов «а как можно сделать лучше?»
Вы хотите что-то поменять в проекте? Думайте об этом с позиции бизнеса. Не «говнокод, переписываем», а «вот здесь у нас постоянно возникают баги, если перепишем — не будет тратить на них время. А вот тут мы тратим много времени на добавление функционала».
Учитесь расставлять приоритеты. Отвратительный кусок кода, который хочется переписать? Окей, а как это влияет на наше приложение, а какие от него проблемы прямо сейчас?
Плохой перфоманс? А насколько это сейчас критично?
Следующий важный момент — чем старше вы как разработчик, тем важнее становится умение коммуницировать.
На собесах в топовых компаниях очень активно оценивают навыки коммуникации, помните об этом.
Как улучшать эти навыки? Обращайте внимание на то, что вы говорите. Вас не понимают, люди делают какую-то фигню и совсем вас не слышат? Разберитесь, почему. Соберите фидбек, отнеситесь к нему спокойно, поработайте над слабыми местами.
Записывайте и анализируйте все проблемы, это офигеть как эффективно. Что-то продолбалось в коммуникации? Записали, подумали, пробуете исправить. Два часа спорили с коллегой из-за фигни и разошлись недовольные друг другом? Записать, подумать, попробовать исправить.
Учитесь понимать интересы вашего собеседника и сопоставлять их со своими. Я понимаю, что это не звучит как важные навыки для программиста, но разработка — командная игра. Чтобы стать классным и востребованным программистом, вы должны быть полезной частью команды.
И последнее — расширяйте кругозор. Разные языки, технологии, проекты, идеи, безумные идеи, опенсорс, в ход идет все что угодно. Чем больше разного вы знаете - тем больше ваше пространство идей, тем больше полезного вы можете придумать. Повторюсь, любопытство окупается.
На этом все! Основной вывод, который мне хотелось бы сделать — будьте любопытными, именно любопытство и желание узнавать новое делают программистов лучше. Накапливайте знания, анализируйте их и пытайтесь использовать на практике.
Оглядываюсь на количество твитов за день и понимаю, что краткость - вообще не мое.
А я ведь еще один тред сегодня планирую написать…
А пожалуй нет, уже не планирую. Писать тред о work-life balance и всяком душевном покое вместо отдыха — это иронично, но не сегодня.
Так что до завтра! А вышеупомянутый тред уходит на выходные.
Вторник
Второй день и сегодня мы будем общаться о программировании!
Как писать код просто и комфортно, как выбирать инструменты, тестировать, рефакторить и вообще создавать максимально комфортную рабочую среду — обо всем этом и поговорим.
Пойду сделаю завтрак и начнем.
Для затравки - начнем с треда о программировании как инструменте для бизнеса. Почему это важно и что из этого следует?
Большая часть разработчиков работает на бизнес. Мы пишем программы для клиентов, сотрудников, исследователей, разные промежуточные модули и так далее. Очень много разного с одной целью - увеличить прибыль бизнесу.
Программирование - просто один из инструментов, которым бизнес пользуется для этого. А разработчики — это чуть больше чем люди, умеющие программировать. Разработчики решают проблемы бизнеса с помощью кода.
Все это ведет примерно к тем же мыслям, о которых я говорил в прошлом треде.
Ваша работа должна быть полезной для бизнеса и ваша работа — это чуть больше, чем «просто писать код».
Дальше о том, что и почему может быть полезно для бизнеса.
Почему может быть полезен рефакторинг?
- Он может упростить читаемость, тем самым ускорив разработку и интеграцию в проект;
- Он может упростить внедрение нового функционала;
- Он может уменьшить вероятность ошибки.
Почему может быть необходимой работа над перфомансом?
- Она может улучшить впечатления пользователей приложения;
- Она может сэкономить машинные ресурсы (то есть деньги);
- Она может быть критически необходима для дальнейшей работоспособности;
Почему может понадобиться новый инструмент?
- Преимущества в реализации некоторой большой задачи;
- Он может лучше поддерживаться/приносить меньше проблем;
- Он может упростить найм/уменьшить текучку.
Зачем я все это расписываю? Мы как разработчики должны уметь оценивать эти факторы перед принятием решений. Всегда считайте, сколько денег/времени бизнес потеряет, а сколько получит. А через сколько он их получит? А с какой вероятностью?
Понятно, почему это нужно бизнесу. А зачем вам это?
- Куда проще «продавать» свои решения, если вы понимаете их пользу для бизнеса;
- Эти навыки делают вас более полезным (читай - дорогим) специалистом;
- Вы начинаете понимать, чего ради делать эту огромную тупую задачу.
И еще один момент. В такой формулировке начинает казаться, что ваши интересы (формата «как же бесит этот чертов кусок кода/фреймворк/anything» задвигаются куда-то очень далеко.
Нет, вовсе не так. Ваши интересы это важная штука для бизнеса.
Чем более вы удовлетворены качеством кода — тем лучше вы разрабатываете. Чем больше вам нравится инструмент — тем лучше настроение на проекте, выше производительность и ниже текучка.
Ваши хотелки важны для бизнесу, просто нужно уметь ему об этом рассказать.
Например, я когда-то продал компании идею делать здоровенный сервис на Котлине именно через мотивацию команды.
Команда была собрана из людей с самым разным опытом, всех подбешивала Java и всем было интересно потыкать Котлин.
По итогу действительно вышло, что мотивация команды заметно подросла и проект пошел достаточно классно. А в комбинации с некоторыми технологическими преимуществами выбор оказался совсем отличным.
Хотя изначальная причина была «бесит, блин, Java»
На этом все! Думайте об интересах бизнеса, но не забывайте и о своих. Если найти точки пересечения ваших интересов и интересов бизнеса — рабочие дни станут куда проще и приятнее.
Тред с несколькими простыми советами, делающими жизнь программиста легче
Настройте IDE.
Первый, очень очевидный и частенько забываемый момент. IDE может сделать вашу жизнь намного проще, иногда вы даже не представляете, насколько. Можете выделить на это целый день, просто на ковыряние в настройках и возможностях IDE.
Настройте стили.
Настройте шаблоны.
Разберитесь с плагинами (например, для помощи в работе с вашим фреймворком или кодогенерации).
Хорошим подспорьем для использующих IDE от JetBrains может стать вот этот доклад (не только для IntelliJ)
youtube.com/watch?v=eq3KiA…
Приучитесь думать и декомпозировать перед работой с кодом.
У меня есть железное правило. Я не начинаю работать над задачей, пока не подумаю над ней. Без кода, без гугла, просто с блокнотом или заметками в маке.
Программистам всегда хочется сразу писать код, но не стоит.
Причин и преимуществ много. Ковыряние в коде заставляет вас думать о ненужных деталях реализации, в заметках вместо кода куда проще думать о более высокоуровневых вещах и декомпозировать их.
Это позволяет сделать задачу понятной, как следствие - перестать стрессовать.
Формируйте общие гайды по стилю для команды.
Обязательно, просто обязательно. Это позволяет избежать кучи споров в ревью (а результаты любого нового спора должны отразиться в гайде), снимает с вас необходимость что-то выбирать, решать и так далее.
Это вообще хорошее общее правило — любое решение должно приниматься один раз. Спорили в ревью или на созвоне? Отразите это в некотором гайде, документации и так далее.
Мыслите инфраструктурно.
Старайтесь делать придуманные вами решения доступными для всего проекта. Всякие маленькие функции-хелперы, работающие на уровне одного класса, могут очень сильно помочь всему проекту.
А еще это заставляет лучше их писать и тестировать.
Это относится к разным конверторам, валидаторам, энкрипторам и чему угодно еще. Проверка некоторого поля на допустимость значения, кидающая исключение? Билдер для большой штуки? Трансформация значения по хитрым правилам? Подумайте, как это может стать общим инструментом.
Затык, часто возникающий с этим советом - для общего инструмента хочется предусмотреть все возможные варианты использования и расширения.
Не надо. Ваш небольшой инструмент будет не так сложно расширить, как кажется. Рефакторинг в IDE творит чудеса.
И в тестах. Особенно в тестах.
Пишите инфрастуктуру для тестов. Всегда, обязательно, непременно пишите. Генераторы тестовых данных, валидаторы, константы, фикстуры для инициализации и прочее.
Придется заморочиться в начале, но до чего проще жить потом!
Вы еще не пишете тесты или пишете их от случая к случаю? Зря!
Тред (очевидных) причин писать тесты.
Хорошие тесты делают написание кода куда менее нервным делом.
Я работал на проектах с реально классным покрытием и это восторг. Да, баги проползали, но большую часть времени прошедшие тесты означали работающий код. Серьезно, после этого жить без тестов не хочется.
Время на написание тестов окупается, причем практически сразу.
По сути, тесты всего лишь автоматизируют то, что вы и так будете делать. Вы же тестируете написанную вами логику, правда? Очень на это надеюсь.
Написание тестов занимает не слишком много времени при условии предварительно созданной инфраструктуры.
На новых проектах я обычно тратил на тесты много времени, но только один раз. На тестовые данные, хелперы, валидаторы, фикстуры и прочие вещи.
Написание тестов заставляет вас писать лучший код.
Если вы не можете протестировать написанную логику — вы что-то сделали неправильно. Неоднократно проверял это правило, исключения бывают, но редкие.
Если код в текущей его версии сложно покрыть юнит-тестами, а на переписывание нет времени - пишите функциональные тесты и выносите новую логику в тестируемые модули.
Функциональные тесты не так требовательны к правильной архитектуре, а рефакторить будет легче.
Функциональные тесты позволяют понять, что делает сервис/модуль. Юнит-тесты позволяют понять контракт метода.
Тысячу раз была вот такая ситуация: вижу метод, ищу ссылки на него, нахожу использование в тестах, понимаю суть происходящего. Сильно упрощает жизнь.
Хорошее тестовое покрытие развязывает вам руки.
Рефакторинги, перфомансные оптимизации, новые библиотеки и любые другие милые сердцу вещи куда лучше ложатся на протестированную систему. У вас появляются какие-то гарантии, что все не ляжет к черту.
Существует целая куча отличных инструментов для тестирования.
Testсontainers, разные либы для моков, либы для тестирования API вроде REST-assured и огромное множество других инструментов сильно упрощают написание тестов, посмотрите на них внимательнее!
Просто попробуйте. Как будете стартовать очередной сервис — попробуйте покрыть его тестами целиком и полностью. Написать классные функциональные тесты, а лучше с них и начать (заодно и спланируете фронт работ). Написать инфру для тестов.
Серьезно, классно получится.
Как трудно смотреть на опечатки, которые не можешь исправить……
Твиттер, ты жесток
Небольшой тред об избыточной абстракции. Вы же видели проекты с адской абстракцией, да? Что-то в духе вот этой прекрасной шутки?
github.com/EnterpriseQual…
Такая абстракция — последствие программистских травм.
«Вот я на прошлом проекте не сделал эту операцию абстрактной и потом пришлось половину логики переписывать! И связанность меньше»
Валидный же аргумент, да? Ну логика будет чуть сложнее, зато изменения проще вносить.
Но это не совсем правда. Легче вносить некоторые конкретные архитектурные изменения и сложнее любые другие.
Каждый новый уровень абстракции делает понимание кода чуть сложнее и вы должны учитывать это при расчетах
Математика следующая:
«Допустим, у меня нет этого уровня абстракции. Сколько времени я потрачу на внесение изменений?»
«А насколько сложнее будет адаптироваться в коде с этим уровнем абстракции?»
Умножаем первое число на примерную вероятность, вычитаем из него второе.
Мораль простая. Не ориентируйтесь на «а вдруг поменять придется», пытайтесь прикинуть вероятность таких изменений. Задавайте соответствующие вопросы PM’ам и аналитикам, они ближе к заказчику. И оценивайте накладные расходы на дополнительный уровень сложности.
Среда
Доброе утро! Я сонный, с чашкой кофе в руке и бутербродом сбоку от ноута сижу на конференции по бэкенду.
Самое время рассказать, чем я занимаюсь на работе и зачем это кому-то нужно!
Сегодня у нас будет день про всяческий DevRel.
Что это? Кто этим занимается, откуда берутся деврелы, зачем они вообще кому-то нужны? Зачем это нужно айтишной компании, ничего не продающей разработчикам?
И всякое другое, приходящее в голову по ходу дела. Как обычно.
И, конечно же, вечное «почему DevRel не человек?»
(пользуясь случаем передаю привет @jbaruch)
Небольшой вводный тред: что за DevRel и зачем это нужно?
Вы же все видели странную коммуникацию с программистами, да?
Вроде текстов вакансий, в которых на кучу текста нет никакой полезной информации
Или маркетинговые статьи от компаний - вроде для разработчиков, а вроде бы и не сказали ничего по делу
Ситуация.
Есть люди, отвечающие за коммуникацию. Они умеют писать тексты, общаться с людьми, доносить некоторые мысли и идеи.
Есть люди, разбирающиеся в разработке. Они понимают технологии, задачи, проблемы разработчиков и прочее.
И как правило это разные люди.
Проблема в том, что коммуницировать с программистами очень важно — но делать это без специфической экспертизы получается достаточно криво.
Выходит что нам нужны люди, умеющие коммуницировать с программистами. Привет, соответствующая область экспертизы называется DevRel, Developer Relations!
Зачем это нужно компаниям? Вариантов может быть много:
- Для продаж, если ваши клиенты - разработчики (привет, JetBrains!)
- Для найма, если вы строите бренд работодателя
- Для внутренней коммуникации с разрабами, если вы строите внутреннее сообщество
Случается и все вместе
Зачем это нужно сообществу?
- Чтобы получать более релевантную информацию о компании. В вакансиях, статьях, анонсах и чем угодно еще;
- Для обмена знаниями в сообществе (вроде конференций и митапов);
- Для построения культуры в компании с учетом важных штук для программистов.
И на этом месте я ушел заниматься непосредственными обязанностями! О том, в чем они заключаются и какой выхлоп из этого можно получить напишу примерно через пару часов
А теперь о том, чем занимается DevRel направление в Контуре и почему деврельство нам нужно.
Для начала, Контур — большой. У нас в управлении разработки больше тысячи человек, а нужно еще больше. Продуктов много, задачек много, разработчики нужны.
А за лучших разработчиков борьба, их все хотят.
И вот мы коммуницируем с разработчиками.
Внутри Контура — чтобы узнать, чего им не хватает, помочь в каких-то внешних активностях и организовать обмен опытом.
Снаружи — чтобы рассказывать всякое техническое, делиться опытом и участвовать в сообществе.
Коммуникация бывает разная. Статьи на Хабре, выступления на конференциях, подкасты, заметки в соцсетях, каналы в телеге, пары в универе, пьянка с сообществом. Коллективный твиттер вот веду, кхем.
Вариантов миллион и это очень классно. У меня прям МНОГО свободы в работе.
Надо заметить, что это не коммуникация формата «Контур самый клевый». Это как минимум неэффективно, да и правдой быть не может. Это компания со своими плюсами и минусами.
Моя цель — сделать так, чтобы Контуром заинтересовались именно те люди, которым Контур подойдет.
Соответственно, говорить о проблемах — тоже важно. Например, я сейчас потихоньку помогаю готовить доклад об одном нашем веб-приложении, где есть прям очень старый код.
Интересная же тема на поболтать, как жить на проекте с кучей старого кода и не страдать?
Я когда-то в телеге писал пост на тему «рассказывайте о ваших проблемах, это полезно для репутации компании». Как говорится, пусть лучше от вас узнают, чем пацаны в подъезде расскажут.
Отличный пост на эту тему был в канале Линор Горалик, кстати
t.me/thecontentisth…
Если просуммировать, то мой основной тезис в коммуникации с сообществом «нормально делай - нормально будет».
Делай полезные для сообщества ивенты, рассказывай интересные технологические вещи, честно говори о проблемах и тебя будут слушать.
Иронично — в день, когда я решил писать непосредственно о работе, у меня нет времени писать о работе
У меня вообще ироничная выходит неделя.
Тред о work-life balance был принесен в жертву отдыху
В день о программировании я полдня не мог собрать здоровенный проект
А в день о работе я настолько ей загружен, что на твиттер нет времени!
С любопытством жду, какой будет шутка завтрашнего дня!
(звучит как краткое описание моей жизни)
Четверг
Сегодня будет общаться про конференции и митапы!
Как и зачем на них выступать, что можно вынести из участия на конференции, какие бывают доклады и на кой черт эти доклады вообще нужны.
(причем на конференции я сижу вот прямо сейчас, здравствуйте)
Иииии я наконец-то это сделал — перепутал личный твиттер и коллективный!
Запостил случайно тред в личном твиттере. Удалять его по одному сообщению было ну очень лениво.
#твиттердобавькнопкуудалитьтред!
Конференции — это классно, конечно. А на кой черт на них нужно выступать?
Тред причин, почему. С личным и не очень опытом.
Личный бренд — это выгодно (не только в смысле денег), а конференции один из самых эффективных способов его прокачать.
Проверено на мне и большом количестве других людей. Кстати, на тему бренда - вот отличный доклад от небезызвестного @jbaruch
youtu.be/sEexbEv2iGc
К слову о личном бренде — юзернейм Баруха в твиттере я набрал по памяти, в заметках и без автодополнения. Не то чтобы мне часто приходится его писать, просто примелькался.
Вот вам и бренд.
Спикеры на конференции неформально общаются с другими спикерами и это ОЧЕНЬ важно.
Вот прикиньте, вам 19 лет, вы восторженно читаете всякие клевые книги по программированию и слушаете доклады, а справа от вас за столом сидит автор прочитанной вчера книги. Кексик кушает.
Про «вам 19 лет» - это не из головы, это про мою первую конференцию и Сашу Гольдштейна, автора книги Pro .NET Performance. Буквально, за день до первой конференции читал его книгу, даже не знал что он выступает, а на следующий день он рядом со мной за столом сидит.
Как следствие, вы много знакомитесь с классными людьми. Они сами подходят, общаются, спорят на какие-то темы, обсуждают доклад, пьют с вами кофе и зовут работать. Первую действительно нравившуюся мне компанию я нашел именно на конференции, вторую - тоже.
Доклад — это отличный способ собрать имеющиеся знания в кучку и углубить их.
Про собрать в кучку вроде понятно. В процессе подготовки вам нужно будет уложить в стройную схему некоторые хаотичные знания, иначе внятного рассказа не выйдет.
Про «углубить» бывает чуть менее очевидно, но это тоже работает.
На любой конференции есть программный комитет — опытные разработчики из сообщества, которые ревьювят доклады. И они сидят именно для того, чтобы помочь вам сделать доклад лучше.
Как следствие, вы получите вопросов и комментариев от них, получите вопросов и комментариев от аудитории и…
И будете сидеть с ощущением «боже, да я же тупой», да. Но без этого ощущения роста не бывает.
И нет, ваш доклад не будет ужасным. Ужасный доклад ПК не пропустит
Вы получаете возможность легко пошарить ваши знания
В какой-то момент я джунам вместо лекций на какую-то тему стал слать записи докладов (или статьи).
Скорее всего на конфе вы будете рассказывать о чем-то, что вы и так часто рассказываете людям. А тут будет хорошая запись.
Выступать — весело
Видели список причин сверху? Так вот, многие спикеры выступают просто потому что в кайф, игнорируя все вышеописанное.
Многим (вот мне) выступать просто нравится. Понравится ли вам? Сходите да проверьте, вдруг зайдет.
Тред ответов на следующий логичный вопрос — а зачем участвовать в конференциях? А то долго, дорого и выхлоп непонятен.
Расширение кругозора.
Важный момент - именно расширение кругозора, не углубление знаний. Если, допустим, я хочу получше знать некоторый фреймворк - у меня есть миллион вариантов.
А что если я хочу просто иметь больше инструментов для решения проблем?
Тут же как. Я вообще-то не знаю, что именно мне нужно. Просто хочу чтобы следующую задачку я решал с большим инструментарием — в смысле подходов, библиотек, фреймворков и вообще идей «как бы так получше сделать»
И я не могу прийти в гугл с запросом «хочу знать больше», трудно гуглу на такие вопросы отвечать. А вот если бы всякие умные люди подобрали для меня тем, да разнообразных, да актуальных и новых, и чтобы про все хорошо так рассказывали, умно…
Ага. Ага!
Следствие из этого номер раз. Старайтесь ходить на доклады по незнакомым для вас темам. Про знакомые вы и так можете найти информацию, а тут может что новое расскажут.
Следствие и причина номер два. Конференция может стать отличным способом нырнуть в новую область.
Вот допустим вы опытный разработчик, который хочет перейти с дотнета на Java. Поход на конференцию по Java — хороший способ вникнуть в актуальные инструменты и подходы.
Кстати, прошлый пример реалистичный и я именно так и переходил на Java. У меня был долгий опыт работы в основном с .NET, а потом — резкий переход и три подряд стартапа-единорога именно на Java.
И вот конференции мне в этом переходе ОЧЕНЬ помогли.
Причина третья, уже знакомая. Нетворкинг, знакомства, поиски работы, успех, деньги, женщины…
Кхем. В общем, очевидный и надоевший аргумент, но рабочий. На конференции ходит много классных слушателей и докладчиков, знакомиться и дружить с ними всегда полезно.
Четвертое. Простой способ узнать, чем живет люди.
По сути это сумма всех предыдущих причин. Работая в своей компании мы иногда оказываемся в пузыре и упускаем ряд вариантов. Как работать, какую архитектуру выбирать, как развиваться и прочее. Выползать из пузыря полезно.
Ну и конференции вдохновляют (как минимум меня).
Пообщаться с людьми, которые делают реально классные штуки, пишут книги, реализуют фреймворки и обо всем этом рассказывают — это вдохновляет. Звучит банально, но без таких вещей иногда становится грустно.
Обязательно ли ходить на конференции? Вовсе нет.
На это нужно время, это стоит денег и не дает каких-то конкретных гарантий. Это не интенсивный курс, где вас за n времени научат технологии x.
Но я уверен, что затраты на конференции всегда окупаются на дистанции.
Так, с абстрактной продажей разного участия на конференциях я закончил. Небольшой перерыв на поесть и приступлю к тредам о докладах.
Как делать доклады, какие бывают доклады, что стоит рассказывать и как подобрать тему — все это будет дальше!
Тред на вечную тему — «я хочу выступать, но мне нечего рассказывать».
Фигня вопрос, еще как есть. Сейчас разберемся.
У вас есть каждодневные задачки.
Код какой-то кодите, баги дебажите, тестами все это тестируете. Тоска, да? Рассказывать вообще не о чем. Более того — у вас же куча проблем, боли и легаси. Наверняка, да?
Как и зачем это людям показывать?
Первое. Ваши проблемы — это интересно.
Особенно когда эти проблемы у многих. У всех баги, у всех легаси, у всех жуть и развал на проекте. Но все по-разному с этим живут и работают — расскажите именно про ваш опыт!
Например, вот про легаси рассказывает Виктор Полищук. Не первый год уже про это рассказывает, кучу людей на доклады собирает. И отличные доклады получаются!
youtu.be/Cc-PeFXY0ZY
Второе. В программировании настолько много областей, что ваш опыт всегда для кого-то будет новым.
Вот работаете вы в банке, например. Что об этом рассказывать? Куча людей в банках работает! И пилите сервис авторизации. Ну тоже банальщина, да?
Но нет, не банальщина. Скорее всего, на всей конференции авторизацией в нагруженной системе занималось совсем мало людей. А для остальных это будет новая информация и расширение горизонта знаний.
Причем на эту абстрактную тему я только что не нашел ни одного доклада на русском.
Синтетический пример?
Сделал перерыв и провел исследование. Написал рандомно друзьям в телеге сообщение вида «Привет! А можешь рассказать, чем ты сейчас на проекте занимаешься? Ну, предметная область/стек»
По трем из четырех ответов я бы принял доклады.
Третье. Поковыряться в некоторой области и сделать об этом доклад - нормально.
Есть мнение, что для выступления на какую-то тему вы должны лет десять с этим инструментом поработать, прочитать все существующие книги и желательно написать свою.
Ну… нет.
Разобраться с некоторой модной библиотекой и рассказать об этом на митапе будет нормально и полезно.
А еще поковырять изменения в новой версии фреймворка и рассказать, что там произошло.
Или попробовать внедрить технологию на проект и рассказать о результатах.
Ключевое здесь это обозначить уровень доклада в названии и описании. Если вы позиционируете свой доклад как вводный или обзорный — никто не требует от вас знания всех кишочков.
Разберитесь на том уровне, который вы обещаете в докладе. Не обещайте лишнего.
Четвертое. Узкая и специфичная история — это нормально, вопрос только в подаче.
На ближайшем DotNext будет доклад о поисках проблемы, приводившей к медленной работе интеграционных тестов. Ситуация специфичная, но доклад подан так, что он точно будет в топ-10 конференции.
Кстати, завтра я весь день буду рассказывать именно об историях и подаче информации, так что ответ на вопрос «а как правильно подавать» будет разобран максимально подробно.
Пятое. Тема, кажущаяся вам простой и очевидной почти наверняка неочевидна для других.
Если вы много работаете с некоторой темой, она всегда будет казаться вам очевидной. Всегда. Вообще всегда. И это ощущение нужно душить, потому что для кучи людей это что-то новое.
Пример из практики.
На одном из прошлых DotNext я делал доклад про идеи, которые типичное приложение может позаимствовать из ФП. Всю подготовку боролся с ощущением банальности, под конец подготовки ПК дружно сказал, что доклад капитанский.
А второе место занял по рейтингу.
Причина понятная — я делал доклад на миддлов, весь ПК - опытные разработчики, для которых все эти идеи интуитивно понятны. Помните об этом, ведь именно такие очевидные доклады зачастую оказываются самыми крутыми и полезными.
Просуммирую. Посмотрите на вашу предметную область, рабочие проблемки, интересные вам технологии, прикольные модные штуки и забавные ситуации из работы. Что угодно из этого может стать темой для топового доклада.
А если сомневаетесь - пишите в личку, я и выступление организую :)
(личка @nevoroman, кстати. В твиттере, телеге, вк и где угодно еще, хоть голубю к лапе юзернейм привязывайте, дойдет)
Пятница
Доброе утро всем! Я вчера планировал еще запилить тред «что такое хороший доклад и как его сделать», но выбрал жизнь и поспал. Постараюсь найти время и закинуть его на выходных ^^
А сегодня мы будем общаться про истории!
Для меня история — это то, что лежит в базе любого повествования и сегодня я буду рассказывать, что это и как их писать. Как искать истории, подавать их, какие бывают типы сюжетов и как это все использовать на практике.
Начинаем общаться про истории! Тред «что такое история и зачем это нужно».
Разбирать буду на примере подготовки технического доклада, но для любого другого формата повествования это работает примерно также.
Итак, представим, что вы хотите сделать доклад. Ну например про функциональное программирование. Вот вы собрали целый загашник примеров использования, рассказали, почему это классно и правильно. Огонь.
Все, доклад готов?
Можно на этом и впрямь закончить. Но в таком случае сложно будет связать информацию чем-то, кроме общей темы.А еще сложно удерживать внимание слушателя.
А еще это не поможет привлечь аудиторию, которой пока не интересна тема.
Для решения задач выше можно использовать разные инструменты и один из них — это истории. Хорошая история помогает связать сюжет, удерживает внимание аудитории долгое время и цепляет слушателя эмоционально, усиливая эффект.
Правильная история обладает рядом свойств. Это не спокойный нарратив, не хронология событий, не процесс. История обладает динамикой, история имеет некоторое начало и конец, история к чему-то приводит слушателя, история вовлекает эмоционально.
У истории есть действующее лицо, главный герой.
За ним мы следим, он ведет нас по истории. А еще именно происходящее с ним вызывает у нас эмоциональный отклик. Это можете быть вы, может быть некоторый абстрактный инженер, может быть проект (но это сложнее)
У истории есть стартовый импульс. Что-то случилось и…
И. И вдруг приложение больше не запускается, вдруг не хватает мощностей серверу, вдруг уволился тимлид, вдруг что-то случилось. И это запускает цепочку событий, которые проведут нас по теме доклада.
У истории есть динамика.
История не статична и не монотонна, динамика, изменчивость истории — это одно из ее важнейших свойств. Найденная причина утечки памяти оказалась неверной, фикс не помог, а новый фреймворк внезапно показал свои недостатки.
У истории есть основная ценность.
За что мы боремся? За производительность, за читаемость кода, за расширяемость, за мир во всем мире? Это важная часть для понимания и сопереживания.
У истории есть конфликт.
И это важный момент для технического доклада, потому что сюда мы упихиваем неизбежный трейд-офф. Оптимизированный код хуже расширяется, на внедрение новой методологии мы потратили кучу времени, а на наш клевый функциональный язык никого не схантить.
В хорошем техническом докладе всегда есть трейд-офф, ведь идеальных решений не бывает. Трейд-офф, показанный в виде истории, куда легче понять и принять.
А еще основная ценность и конфликт являются главными двигателями истории, обеспечивают ей объем и динамику.
История приводит к трансформации.
Мы прошли путь от некоторого стартового состояния к конечному. Что-то потеряли, что-то получили, так или иначе — изменились. Трансформация делает историю осмысленной, без нее это действия без всякого результата.
История эмоционально воздействует на аудиторию.
И это один из важнейших ее эффектов. Сухой рассказ о технологиях не цепляет за эмоции, а вот история борьбы и преодоления, да с примерами, да понятная и «блин, у меня такая же фигня на проекте была» — еще как.
Все это кажется абстрактным? Но нет, вы постоянно встречаете элементы этого в технических докладах.
- Примеры из жизни дает персонажа;
- Трейд-оффы дают конфликт;
- Эксперименты и попытки решить проблему дают динамику;
- А хорошие выводы - это трансформация.
У хороших докладов постоянно есть как минимум элементы истории и зачастую их нужно только объединить воедино, собрав разрозненные кусочки в цельное повествование.
Кстати, о сюжетаж и способах «собирания» историй еще будет тред чуть позже
Теперь поговорим о нюансах.
Первый напрашивающийся вопрос — «а что, это всегда одна история на доклад? А если у меня их много?»
Вовсе нет. Это может быть одна история, может быть несколько последовательных, а может и несколько параллельных.
История может использоваться и как небольшая часть доклада. Частый пример — это вступление, историей очень удобно вовлечь слушателя перед накидыванием технических примеров.
Еще история — это хороший способ собрать доклад, в котором вы хотите выразить одну конкретную идею.
Такие доклады очень сложно подавать, потому что завлечь и удержать аудиторию всего лишь одной идеей - та еще задачка.
Мой любимый пример это доклад Hadi Hariri с посылом «идеального решения нет, но сам его поиск важен». Очень простая идея. но история сделала доклад великолепным.
youtu.be/zshDD34-Tgs
И, конечно, история — это лучший способ подать кейсовый доклад, рассказать о некотором вашем опыте. Если ваш доклад посвящен истории некоторого проекта или чего-то подобного — постарайтесь выстроить его как правильную историю.
Но откуда вообще-то брать эти истории и как их подавать, вокруг чего строить?
Обо всем этом мы обязательно поговорим. Но сначала обед
Кстати, за этот и последующие сегодняшние треды спасибо курсу от @batenka_onfire по журналистскому тексту, очень классно уложили мне знания в голове.
И отдельное спасибо автору лекции про истории @n_berezovaya и @scherbakova7, с которой мы постоянно общаемся про тексты.
На закрытии конфы от @Podlodkacrew организовали бар, так что я постановил, что у меня пятница и намешал джин-тоник.
Всех с пятницей!
Суббота
И наконец-то суббота! Поздравляю всех, мы дожили до выходных.
По этому случаю сегодня будет день тредов о work-life balance, заботе о себе и прочих добрых вещах. О работе и достигаторстве мы уже пообщались - время поговорить о том, как жить и не страдать.
Айти — это интересно, весело, денежно и вообще с кучи сторон хорошо. Настолько хорошо, что частенько хочется нырнуть в работу с головой и забыть обо всем остальном.
Тред личного опыта ныряния в работу с головой, последствий и способов вылезания из этого.
Здравствуйте, меня зовут Рома и я трудоголик.
Как-то так вышло, моя самооценка всегда была очень жестко привязана к рабочим достижениям. Как следствие, лет с шестнадцати и до двадцати я занимался только работой, исключительно работой и ничем другим.
Где-то лет в восемнадцать это достигло пика и у меня был год, когда я спал по три часа в день. Мне просто не хотелось спать, было слишком много отличных-интересных занятий. Тут проектик, тут митап, о, пойду на Хаскеле попишу, прикольно же!
Со стороны это выглядело достаточно эффектно — продуктивность, карьера, знания, зашибись же!
До какого-то момента мне тоже казалось, что все зашибись. А потом я внезапно расплакался, потому что за две недели не выучил ничего нового и ну, карьера стоит на месте, я бесполезен!
С эмоциями вообще начало твориться что-то странное. Я срывался на людей, нервничал из-за любых неудач, неспособность в чем-то разобраться вызывала у меня ужас и панику. Буквально, блин, панику.
А еще я осознал, что у меня куда-то потерялись все друзья. И любые старые хобби.
Я сменил работу — просто чтобы вырваться из рутины. Стал с большими трудностями искать себе терапевта. Перестал заниматься айти вне работы. Стал пытаться искать людей и занятия — хаотично перебирая разные компании и хобби, просто чтобы хоть как-то заполнить появившееся время.
Кажется, это были самые пустые полгода моей жизни. Я чувствовал себя совершенно бесполезным, настолько же бесполезным было все вокруг. Эдакое ощущение жизни по инерции, «потому что так надо», без внятных целей и мотивации.
Но я продолжал случайно перебирать занятия, начинать их и бросать. Попытался научиться рисовать, пошел заниматься шахматами, ковырялся в истории и разных научных областях. С неизменным ощущением бессмысленности происходящего.
А потом… наверное, я не могу сказать «в один момент все стало лучше». Все становилось лучше постепенно.
Какие-то занятия прижились в моей жизни, у меня появились дела по вечерам. Случайно встреченные люди стали друзьями. Не было ничего конкретного, просто заполнялась пустота.
Дальше — лучше. Очередное случайное занятие превратилось в любовь к танцам и еще одну здоровенную влюбленность, за которой я уехал в Германию. Влюбленность на пару с разнообразными хобби приносили мне силы и я начал делать классные доклады.
И работа как-то сильно лучше пошла.
После было много всякого. Много проблем, много сложных периодов, расставания, увольнения и переезды. Но никогда больше не было вот этого ощущения, что у меня есть только работа и моя жизнь держится только на ней.
А теперь к выводам — что это было и как такого не допускать?
Первое. Очень общее, не только по теме треда.
Если вы чувствуете, что в вашей жизни есть какой-то один важнейший элемент и без него жизнь будет бессмысленна — что-то пошло не так. Это очень шаткое и опасное положение, в котором угроза этому чему-то страшно бьет по нервам.
Поэтому второе. Всем необходимы увлечения (кроме работы), хорошие друзья и что-то, чем вы можете заняться наедине с собой.
Как найти хобби? Случайным перебором занятий, главное не бойтесь бросать. Записывайтесь на случайные занятия, даже без всякого желания, просто через силу.
Как искать друзей? Ровно также.
Для этого придется общаться с вроде бы чужими людьми. Тоже через силу. Для этого придется соглашаться выходить из дома, когда «да нууууу его…», чувствовать себя неловко. И очень часто придется переставать общаться. Но найти своих людей — важно.
Третье. Ваша рабочая продуктивность ограничена.
Работая по двенадцать часов вы сильно снижаете свою способность воспринимать информацию, думать и учиться. Отдых, увлечения и всякие физические активности делают вас продуктивнее.
То есть возникающее ощущение «я непродуктивен и ничего не успеваю, мне нужно работать больше» - ложное.
Переработки делают вас менее продуктивным, а не более. Карьера — это марафон, а не спринт. Заботитесь о карьере? Позаботьтесь в первую очередь о себе, это окупится.
Ведь не просто же так компании все больше начинают переживать за work-life balance и заботиться об отдыхе сотрудников?
Компаниям попросту не выгодны перерабатывающие трудоголики — в долгой перспективе, во всяком случае.
Четвертое. Обращайте на себя внимание.
Стали часто болеть? Постоянно чувствуете себя устало? В целом как-то все… никак?
Подумайте, а не много ли вы работаете. А друзей часто видите? А в отпуске когда были? Возможно, стоит выдохнуть и что-то поменять.
Пятое. Вас заставляют перерабатывать? Уходите к черту.
Тут важно именно слово «заставляют». Бывает всякое — авралы, срочные починки прода и так далее. Но это именно исключения и именно попросить. Если вы чувствуете, что вас вынуждают перерабатывать — уходите без раздумий.
Выводы. Смотрите на свое состояние. Вы не должны чувствовать себя плохо (или просто никак), у вас должны быть занятия кроме работы, вы не должны перерабатывать, вам нужны хобби и друзья, все это можно намеренно искать.
Заботьтесь о себе, пожалуйста. Это полезно и выгодно.
P.S. Звучит как история героинового наркомана и, блин, это не случайно. Трудоголизм — такая же зависимость, как и любые другие
@itunderhood А как переключиться? Я даже во време бега думаю про код
Нужно случайным перебором искать занятия, которые точно также захватят. Чувствуешь, что не цепляет? Можно бросать и искать другое.
Ощущение «да я же так вообще все брошу!» — ложное, впихнутое в нас родительским подходом «лучше не дергаться и не рисковать». twitter.com/NUM13RU/status…
P.P.S. Самый успешный период в моей карьере наступил именно тогда, когда я жестко ограничил затрачиваемое на работу время и завел кучу других занятий.
Выводы делайте сами.
@itunderhood Вот как бы остальной мир приучить к более спокойному течению жизни, без этих "бегом-бегом"? Китай уже вряд ли - не захочет, даже если весь мир будет придерживаться w-l balance.
Вот, теперь можно и отвечать. Не нужно его приучать, сам приучится. Европа не просто так пришла к спокойному течению жизни, это эволюционный результат.
В долгой перспективе спокойный темп выгоднее. Просто в масштабе стран эта «долгая перспектива» дольше. twitter.com/evgeniy007/sta…
То есть возникающее ощущение «я непродуктивен и ничего не успеваю, мне нужно работать больше» - ложное. Переработки делают вас менее продуктивным, а не более. Карьера — это марафон, а не спринт. Заботитесь о карьере? Позаботьтесь в первую очередь о себе, это окупится.
Накосячил с порядком твитов, продолжение тут
twitter.com/itunderhood/st…
После треда о трудоголизме у @xaski_2000 возник закономерный вопрос: а что делать в обратной ситуации, когда нет никакой мотивации заниматься всякими полезными штуками?
Время для треда о поисках мотивации!
Дисклеймер. По природе мотивации проведено куча исследований, написано бесконечное количество книг… которые я не читал. В треде описывается мой опыт и мои личные лайфхаки, а научную сторону вопроса я изучал только косвенно.
Классическая ситуация. У вас есть рабочий проект, вроде бы неплохой. Платят прилично, код адекватный, люди хорошие. Язык вам тоже нравится, вы даже кучу книжек по нему накупили и статей всяких в закладки добавили.
И есть куча полезных дел, но как-то не прет. А почему?
Начнем с самого нижнего уровня.
А вас сейчас вообще что-то радует? Какие-то эпизоды в жизни, люди, увлечения, яркие эмоции?
Если вы ощущаете, что жизнь равномерно серая — запишитесь на психотерапию. Без этого все советы ниже помогут на уровне известного мема.
Допустим у вас есть штуки, которые вам нравятся. А что именно вам в них нравится?
Порефлексируйте, попробуйте разбить приятность на компоненты. Вам нравится процесс или результат? А в каком случае вы получаете больше удовольствия? А какие моменты вам особенно запомнились?
Пример. Итак, мне нравится программировать. А что именно мне нравится?
Нравится момент, когда я нашел-таки баг. Почему? Ну… ощущение победы что ли. Да, мне нравится побеждать!
Еще нравится строить цельные, работающие штуки. Тут удовольствие эстетическое.
Ваша задача — разбить простое «нравится делать x» на маленькие детальки, чтобы выделить из большого увлечения (люблю программировать) отдельные приятные моменты.
Это долгая задача, не на один вечер. Постоянно наблюдайте за собой. Помогает, кстати, вести дневник.
Внутри профессии есть много разных работ и много способов обучения. Постарайтесь подобрать те, в которых будет максимальное количество приятных для вас моментов.
Например, я не люблю низкоуровневые вещи, но люблю рефакторить, писать всякие удобные обертки и делать код удобным.
Итак, вот мы нашли вещи, которые приятно поделать. А что с вещами, которые нужно делать, но не хочется?
Для начала стоит ответить на самый важный вопрос. А почему нужно?
Вариант «нужно, чтобы дальше было клево». Чтобы работать в классной компании, чтобы стать известным, чтобы что-то.
В таком случае помогает план. Выберите вот эту дальнюю цель (важный момент — реалистичную) и распишите конкретные шаги по ее достижению.
Цель должна мотивировать и зажигать, чтобы думали об этом и «эх, хочу!». Шаги по достижению этой цели должны быть понятными и реалистичными. Вы должны понимать, как вот эта прочитанная книжка приближает вас к результату.
А что делать, если цели нет, но вроде как-то абстрактно хочется?
Поищите то, что может зажечь вас работой. Сходите на конференцию, пообщайтесь с людьми, которые горят своим делом. Вспомните, что вас раньше зажигало.
Есть некоторый шанс, что ничего зажигающего не найдется . И если так — подумайте, не стоит ли поискать что-то зажигающее в других областях. Смежные и не очень профессии, например. А может вы хотите заняться каким-то из ваших хобби профессионально?
Менять профессию можно.
Вариант «надо сделать, иначе беда». Так часто бывает с врачами, горящими дедлайнами и прочим.
С таким я и сам плохо справляюсь. Лайфхак прямо сейчас — примешивать в неинтересные занятия интересные. Я вот мою посуду под музыку, а в качестве физической активности выбрал танцы
Вариант «надо сделать, но я не уверен, почему».
Приглядитесь к этому варианту повнимательнее. Есть шанс, что вообще-то это делать не нужно. Хорошенько порефлексируйте и разберитесь — для чего это нужно делать? Что произойдет, если нет? А что, если да?
И важный момент напоследок. Иногда у вас нет мотивации заниматься полезными-профессиональными штуками, потому что тревожат другие проблемы. Когда вокруг все в огне, денег нет, жить негде и отношения разваливаются — не до работы.
Это окей. Разберитесь сначала с этим.
Итак, выводы
- Поймите что вас увлекает
- Поставьте долговременные цели и пропишите путь к ним
- Посмотрите, что из не-увлекательного в рутине можно заменить на увлекательное
- Примешивайте приятное в неприятное
@itunderhood Часто достаточно иметь месяц каественного сна. Одна из главных бед человечества - что оно не высыпается, и даже не осознает это как проблему. Даже один час недосыпа каждый день уничтожает любую мотивацию. Люди делают ерунду. Усталость накапливается и убивает весь интерес к жизни.
Д А
(можно десять лайков поставить?) twitter.com/graninas/statu…
Как-то так выходит, что мы много думаем о работе, карьере, других людях и обо всем в мире — но мало думаем о себе.
Тред заботы о себе.
Если вам плохо — это не нормально, никогда.
Вас раздражает работа? Или отношения? Или город, в котором вы живете? Люди, с которыми приходится общаться?
Это не нормально. Решения могут быть разные, но никогда не считайте, что это норма.
Ваше мнение о себе первично.
Ни один человек в мире не знает лучше вас, что вам нужно. Если вы хотите одеваться в рванину и красить волосы в зеленый или тихо читать дома книжки и торговать мороженным — делайте это. Люди от вас не разбегутся, кстати. Я проверял.
Любить себя можно. Нужно!
Знаете вот эту ситуацию, когда вы влюбились и очень хотите понравиться объекту обожания? Книжки правильные читаете, одеваетесь как она любит, вот это все?
Сделайте то же самое по отношению к себе. Старайтесь себе понравиться! Жить станет приятнее.
Вы не должны ничего заслуживать.
Чтобы отдохнуть, вкусно покушать, посмотреть сериальчик или сделать что угодно еще приятное вы не должны это «заслужить». У вас просто есть право на все эти приятные вещи. Всегда, базово.
Ошибаться - можно.
Вы всегда будете ошибаться, это нормально. Все ошибаются. Да, и воооон тот сверхчеловек тоже, по три раза в день!
Хотите сделать что-то полезное после ошибки? Разберитесь, почему так случилось, запишите, больше не думайте об этом.
Найдите себе физическую активность по вкусу
Я не люблю заниматься спортом (и физуху вообще) но вынужден признать — без всякого шевеления туловищем жить сильно хуже. Причем зачастую незаметно хуже, просто как-то немного грустнее и чувствуешь себя похуже.
Высыпайтесь
Это со всех сторон хорошо и правильно! Настроение будет лучше, здоровье крепче, думать будете намного быстрее и вообще со всех сторон производительнее.
Недосып НИКОГДА не окупается. А бессонница это повод сходить к врачу.
(автор совета @graninas)
Займитесь питанием
Хорошо кушать — это важно на уровне сна и физухи. Погуглите, изучите тему, подберите (методом проб и ошибок зачастую) приятное и полезное питание для вас. Поищите магазины с хорошими продуктами, доставки продуктов.
Меню себе придумайте
Сходите наконец к психотерапевту
Нет, психотерапевт не для больных людей, он для всех. Нет, не «я сильный и сам разберусь» — это не про силу, это про искажения. Вы же не можете посмотреть на себя без зеркала, даже с отличным зрением? Психотерапевт — зеркало для психики.
Вы достойны чего угодно.
Классных отношений, самой лучшей работы и хорошего отношения к себе. Пожалуйста, не думайте что это не так. Вы достойны и вы можете.
Take care.
Ииии поздравляем канал с круглой цифрой в 5к подписчиков!
Воскресенье
Доброго всем утра! В Санкт-Петербурге солнечно и поют птички, а у автора этой недели нет никаких планов на день. В том числе и на этот твиттер!
Так что — концерт по заявкам. Предлагайте темы и просто задавайте вопросы в реплаях, а я пойду искать завтрак в солнечном Питере.
Вроде бы в воскресенье часто о хобби говорят? Небольшой тред «смотрите, что могу» с моими фотографиями :)
Я повыпендривался, всем спасибо! Если кому интересно следить за моими фотографиями — вот инст
instagram.com/nevoroman/
P.S. Возможно, расскажу сегодня что-нибудь интересное про фотографию, но я про это мало рассказываю и не выходит сходу уложить мысли во что-то стройное. Но можете задавать вопросы!
@itunderhood Бывают интересные баги, неожиданные открытия в ежедневной работе. Проблема в том, что большинство из них тянет на тред в твиттере, редко на статью на Хабре и крайне редко это можно растянуть на часовой доклад, чтобы воду не лить.
А тогда их можно объединять и рассказывать сразу про несколько! Собственно, как в твоих докладах про стримы :)
youtube.com/watch?v=TPHMyV… twitter.com/tagir_valeev/s…
Другой вариант — рассказывать про методологические вещи. А как подобные баги отлавливать, а как лучше исправлять/обходить?
@itunderhood вопрос: как выкатиться из локального снг-рынка на глобальный? с чего начать, на что обратить внимание, какие подводные камни, что с налогами и как это всё оформляется? ) //привет от Ариэля )
Попытка вторая ответить на вот этот вопрос — он про «а как удаленно работать на компании вне России».
Если вкратце, то сложно! Но несколько вариантов сейчас опишу twitter.com/Modzh_/status/…
Искать контракты на сайтах вроде Upwork.
Начинаешь как фрилансер/контрактор, оформляется это добро как контракты с ИП, периодически выливается в долговременное сотрудничество
Минусы: сложный старт: первые заказы приходится прям долго искать, на поиски заказов уходит много времени, платят изначально мало, нет ощущения стабильности. А, и там есть трекер.
Плюсы: после наработки репутации, при хорошем уровне рейтинга можно классно заработать.
Аутстаф-компании.
Я через такое работал. По сути, компания является просто посредником между тобой и некоторой зарубежной компанией, ищущей контракторов. Нанимаешься к ней, работаешь на зарубежного партнера.
Похоже на аутсорс, но менеджмент на стороне зарубежной конторы.
Плюсы: платят за это добро лучше, чем за тот же аутсорс (как правило). А если контракт захотят расторгнуть — тебе постараются найти новый с сохранением зарплаты (а вот это не всегда работает)
Минусы: сложнее с карьерным ростом, задачи бывают скучнее, короче минусы контракта
Поиски зарубежной компании, которая готова работать с тобой удаленно.
Идешь на LinkedIn/StackOverflow Jobs/куда угодно еще и пишешь всем компаниям, которые нанимают на Remote. Самый долгий вариант, в перспективе самый лучший. Дальше о нюансах и трудностях
- Очень часто remote в описании вакансии — это «remote, но живешь ты внутри страны». Чаще всего в Штатах. Причин много — общие сборы дешевле, юридически все намного проще и так далее.
Уточняйте это СРАЗУ. Я, бывало, узнавал после трех этапов собеса, релокацию предлогали, блин
- Не факт, что это будут огромные зарплаты из мечтаний и рассказов.
Требование «вне России» приведет вас к бесконечным компаниям, расположенным в MENA, в Азии и так далее. И зарплаты там будут норм. Не космос, не то чтобы больше, чем в России. Норм.
- Собесы бывают долгие и сложные, потому что у компаний с честной удаленкой и хорошими зарплатами большой поток кандидатов
Советую не подаваться везде, а посмотреть предложения, выбрать 2-3 лучших и подготовиться. Написать клевое сопроводительное письмо, поковыряться в их стеке
- Самые клевые предложения я находил по знакомству
Банально, но да. Тут помогает как раз LinkedIn и попытки вести там какую-то социальную жизнь — статьи шарить, в комментах отвечать и так далее. Ну и меня вытаскивал личный опыт жизни в Европе, там знакомился с рекрутерами
@itunderhood А про язык ещё расскажите, какой уровень для собеседования нужен, как лучше подготовится ?
Языка хватает на уровне B1-B2. Как готовиться — честное слово, не знаю, я доучил до этого уровня английский чуть ли не в школе. Но нынче есть миллион интенсивных курсов и среди них много хороших.
twitter.com/flyingholland/…
@itunderhood Вроде как можно гораздо проще — сейчас есть куча телеграмных каналов с вакансиями, где обычно ~80% вакансий — от зарубежных компаний, берущих к себе через фирму-прослойку или просто как аутстафф (чаще всего через ИП).
Это правда, да. Просто мониторить компании внутри страны сейчас очень полезно. Даже банально на HH сейчас есть классные вакансии от зарубежных компаний
twitter.com/shaukote/statu…
Итак, неделя походит к концу и время для метатреда aka «пакет с пакетами»! Давайте посмотрим, что мы успели за неделю наплодить.
Для начала — тред-введение о том, чем я вообще в этой жизни занимался и как я оказался здесь.
Вводный тред «кто за Роман Неволин и как он здесь оказался?»
twitter.com/itunderhood/st…
Тред о вечном споре, что лучше - учиться в университете или потратить это время на работу и самообучение. Сразу скажу — я не считаю один из этих вариантов однозначно лучше, а о плюсах и минусах каждого расскажу ниже.
Тред на тему «что лучше — быть самоучкой или пойти в универ?»
twitter.com/itunderhood/st…
Итак, время для огромного треда о развитии программиста. Как расти и получать новые знания? На что обращать внимание на каждом из этапов развития? Как расти в сеньоры и кто они вообще такие?
Мегатред о развитии программиста. Как расти на новую ступеньку и становиться лучшим специалистом?
twitter.com/itunderhood/st…
Для затравки - начнем с треда о программировании как инструменте для бизнеса. Почему это важно и что из этого следует?
Тред о программировании как инструменте для бизнеса
twitter.com/itunderhood/st…
Тред с несколькими простыми советами, делающими жизнь программиста легче
Тред простых советов для программиста
twitter.com/itunderhood/st…
Вы еще не пишете тесты или пишете их от случая к случаю? Зря! Тред (очевидных) причин писать тесты.
Тред причин писать тесты
twitter.com/itunderhood/st…
Небольшой тред об избыточной абстракции. Вы же видели проекты с адской абстракцией, да? Что-то в духе вот этой прекрасной шутки? github.com/EnterpriseQual…
Мини-тред об избыточной абстракции
twitter.com/itunderhood/st…
Небольшой вводный тред: что за DevRel и зачем это нужно?
Небольшой тред-пояснение «что такое DevRel и зачем оно нам нужно?»
twitter.com/itunderhood/st…
А теперь о том, чем занимается DevRel направление в Контуре и почему деврельство нам нужно.
Тред «чем занимается DevRel в Контуре?»
twitter.com/itunderhood/st…
Конференции — это классно, конечно. А на кой черт на них нужно выступать? Тред причин, почему. С личным и не очень опытом.
Тред причин выступать на конференциях
twitter.com/itunderhood/st…
Тред ответов на следующий логичный вопрос — а зачем участвовать в конференциях? А то долго, дорого и выхлоп непонятен.
Тред причин участвовать в конференциях
twitter.com/itunderhood/st…
Тред на вечную тему — «я хочу выступать, но мне нечего рассказывать». Фигня вопрос, еще как есть. Сейчас разберемся.
Тред «я хочу выступать, но мне нечего рассказывать» - ищем темы для докладов
twitter.com/itunderhood/st…
Начинаем общаться про истории! Тред «что такое история и зачем это нужно». Разбирать буду на примере подготовки технического доклада, но для любого другого формата повествования это работает примерно также.
Тред об историях: что это и зачем они в технических докладах?
twitter.com/itunderhood/st…
Айти — это интересно, весело, денежно и вообще с кучи сторон хорошо. Настолько хорошо, что частенько хочется нырнуть в работу с головой и забыть обо всем остальном. Тред личного опыта ныряния в работу с головой, последствий и способов вылезания из этого.
Тред о трудоголизме и отходе от него
twitter.com/itunderhood/st…
После треда о трудоголизме у @xaski_2000 возник закономерный вопрос: а что делать в обратной ситуации, когда нет никакой мотивации заниматься всякими полезными штуками? Время для треда о поисках мотивации!
Тред о поисках мотивации
twitter.com/itunderhood/st…
Как-то так выходит, что мы много думаем о работе, карьере, других людях и обо всем в мире — но мало думаем о себе. Тред заботы о себе.
Самый важный тред за неделю, тред заботы о себе
twitter.com/itunderhood/st…
Попытка вторая ответить на вот этот вопрос — он про «а как удаленно работать на компании вне России». Если вкратце, то сложно! Но несколько вариантов сейчас опишу twitter.com/Modzh_/status/…
Небольшой импровизированный тред про удаленную работу на зарубежные компании
twitter.com/itunderhood/st…
А порядочно успели наплодить, я вам скажу!
Ну что ж, будем прощаться!
Большое спасибо всем кто читал, лайкал, репостил, комментировал и вообще следил за происходящим. Было сильно больше активности и поддержки, чем я ожидал. Почувствовал, что не зря это все писал :)
Если вам хочется что-то мне написать или просто продолжать читать мои излияния - мой ник @nevoroman, подписывайтесь здесь и в любых других соцсетях.
А еще есть канал в телеге. Он в легкой спячке, но я за эту неделю набрал клевых тем для постов :)
t.me/devrel_russia
P.S. Кстати, всю эту неделю я писал твиты в рабочее время (на любые темы, без модерации и контроля), да и в другие дни занимаюсь кучей веселых вещей.
Я это к чему? Мы еще одного деврела ищем, так что пишите в личку, обсудим…
