Исправление чужого кода

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

Вред состоит в том, что:
- Ты мог ошибиться, и на самом деле всё с кодом было хорошо. Теперь придется пускаться в объяснения с разгневанным программистом, чей код исправили, и откатывать "исправления".
- Это неуважительно по отношению к другому человеку и его труду. Человек вложил определенное количество труда в написание кода, а ты молча идешь и меняешь его без какого-либо предупреждения. Не надо так
- Даже если ты прав, ты исправил код, ты сделал проект лучше - это непродуктивно. Если программист один раз написал плохой код и за ним молча исправили, то скорее всего он и второй раз так может сделать, и третий.

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

Уважайте чужой труд, разговаривайте с коллегами, делайте лучше и проект, и коллег.

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

Ссылка на тред https://twitter.com/_jeck/status/941352089103499264

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

Как я читаю книги
Продолжу прошлый пост о книгах.
Книг хочется прочитать много разных, но обычно то устал, то некогда, то атмосфера не та, то кошка рожает. Устав от такого откладывания, я решил попробовать "регулярночтение".
Читаю две книги параллельно. Чтобы легче, а иногда и желаннее было переключаться, беру одну художественную, одну образовательную.
Суть системы проста: читаю по 50 телефонных страниц от каждой, каждый день. Это примерно 20 книжных страниц. В итоге получается примерно 3 книги в месяц, 35 книг в год особо не напрягаясь.
Времени это занимает минут 40. 40 минут мне было довольно легко отнять от утреннего залипалова в интернете.

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

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

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

Моё личное мнение, что если вы удовлетворяете требованиям хотя бы на 3/4, то смело откликайтесь и не переживайте.

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

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

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

Если чувствуете, что большую часть требований вы покрываете - верьте в себя, откликайтесь, пробуйте, общайтесь, делайте тестовые, собеседуйтесь. Под лежачий камень вода не течет.

Как помогать коллегам

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

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

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

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

Как просить помощи у коллег
В прошлом посте я писал о том, как коллегам помогать, но не менее важно уметь правильно просить помощи.

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

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

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

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

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

Поблагодарите
Быть вежливым и благодарным - это просто. Человек отложил свои дела, потратил своё время, помог тебе. Не забудь ему хотя бы спасибо сказать.

Просите помощи правильно и потенциальных помощников у вас будет много, и никто не будет в обиде.

Войти в айти это надолго

Сейчас из каждого утюга рассказывают о том, что в айти много зарабатывают. Онлайн курсов для начинающих появилось море, начиная от инфоцыган и заканчивая программами хороших вузов или технологических компаний.
Практически каждый курс содержит в себе вступительную информацию, намекающую на то что "вот сейчас закончите и будете 60-100-150 тыщ получать. Вы только пройдите наш курс, длительностью 1-6 месяцев".

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

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

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

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

CV Driven Development

Отгремели свежие твиттерские баталии про инфантильность программистов. "Программисты не несут ответственность" VS "делаем что хотим, потому что можем, или менеджерить надо лучше".

CV Driven Development это когда разработчик без особой необходимости тянет в проект технологии и подходы к разработке, которые хочет заполучить к себе в портфолио.

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

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

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

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

Говнокод vs идеальный код
Недавно мой товарищ и подписчик прислал мне видео https://www.youtube.com/watch?v=-R455cuPsV4 которое предложил обсудить в канале.
Видео само по себе уже содержит довольно много рассуждений на тему того надо или не надо говнокодить, стоит ли вылизывать код до перфекционизма и т.д. Так что тут уже особо в обсуждениях я каких-то новых революционных мыслей не внесу. Могу лишь выразить свое мнение по этому поводу и рассказать как эти идеи эволюционировали в моей работе.

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

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

После этого я решил поумерить свой пыл, но продолжил разрабатывать так, что "а вот тут может понадобиться изменение логики, там расширение функционала, здесь увеличится нагрузка". И это неплохой подход, но делал я так везде. Во всех проектах, во всех задачах. А реально стреляло это где-то в 20% случаев. Так осталось много мертворожденных потенциальных фич, на которые было потрачено довольно много времени. Мне надо было читать Дональда Кнута, который говорит "преждевременная оптимизация — корень всех зол". Мое мнение, что потом дооптимизировать в 20% случаев - зачастую (не всегда) проще, чем поддерживать изделие, которое излишне переусложнено в 80% случаев.

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

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

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

Нужны ли тимлиды?

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

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

Сфера ответственности тимлида в ИТ немного размыта, но в общем случае он гарант успешной работы многих компонентов рабочей экосистемы.

Он следит, чтобы разработка шла в нужном ключе технически, чтобы без hype, cv, костыль driven development.

Следит за сроками проекта. Чтобы команда успевала вовремя, заказчик не шибко давил и т.д.

Принимает финальные решения при найме новых сотрудников. А кто ещё так хорошо определит, подойдёт ли человек в команду? Не эйчар же)

В целом смотрит за мотивацией и настроением команды. Держит руку на пульсе, так сказать.

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

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

Хороших вам тимлидов. А если можете обойтись без них, то я за вас искренне рад 👍

Курсы в ИТ. Инфоцыгане или польза?
Сейчас из каждого утюга вещают о том, как вас готовы научить программировать всего за N денег, и после прохождения этих чудесных курсов вы сможете зарабатывать Nx2 КАЖДЫЙ МЕСЯЦ!
Хотелось бы предупредить потенциальных жертв маркетинга, что всё немного не так, как сообщается в рекламе.
Далее последует моё личное мнение, основанное на собственном опыте (у меня его хватает) и опыте знакомых, коллег, товарищей.

Нужны ли вам курсы, чтобы "вайти в айти"?
Насколько я знаю статистику по нескольким площадкам и курсам, до конца доходит в среднем четверть. А трудоустраивается потом тоже не сильно много людей из этой четверти.
Так что если вы увидели рекламу о том, как поучитесь 2 месяца, а потом будете зарабатывать стотыщ, то прочитайте мой прошлый пост https://news.1rj.ru/str/general_it_talks/9 и крепко задумайтесь, надо ли оно вам, готовы ли вы вложить столько труда, времени и денег.

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

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

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

Много ли сомнительных курсов?
На мой личный взгляд - много. Большинство. Процентов 80-90.

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

Учитесь новому, получайте пользу, берегите своё время и деньги.

Сертификация в ИТ. Стоит ли тратить время и деньги?

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

Сертификатов я имею несколько разных. Одни давались после окончания каких-либо курсов, другие за отдельную сертификацию по той или иной технологии. Сертификаты у меня есть как бесплатные, так и платные. Максимальная сумма, которую я платил за сертификацию - 200$.

Выражу своё мнение по нескольким критериям.

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

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

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

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

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

Тимлид. Круто? Гемор? Всё сразу

Недавно в чате подкаста "Цинковый прод" (заходите, общайтесь https://news.1rj.ru/str/ZnProd) имел разговор про тимлидство. Круто это или не круто, сколько гемора и сколько радости приносит. Поговорил там, а подведу итог в одном посте тут:) Буду описывать это на своём опыте.

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

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

Минусы:

Больше ответственности
Когда ты рядовой разработчик - ты несешь ответственность только за свой код (да честно говоря и то не всегда). Когда ты тимлид - с тебя спрос за всё, что сделала твоя команда. И не только как она написала код, а как это отражается на бизнес показателях. Приходится переключать мышление от "Ну вот этот код смотрится красивее. Вчера на конфе услыхал про технологию N - надо всё переписать" на "ДЕНЬГИ! СРОКИ! ЗАКАЗЧИКИ! ПОДДЕРЖКА! ЛЮДИ!".
Иными словами, всё как в армии. Рядовой опиз**ляется за себя, а сержант за весь взвод.

Больше работы, больше тоски
В моем варианте "играющего тренера" надо уделять время и процессам, и команде, и заказчикам. Однако код писать тоже надо. Тут появляется неприятное чувство, когда весь день у тебя встречи, планерки, письма, обсуждения, а к вечеру кажется, что раз код не написал, то будто ничего и не сделал. Садишься в мыле писать код, час-два пописал, день кончился, и ты думаешь: "блин, да как так мало-то?".
На этом этапе многие технари сильно приунывают, и некоторые с облегчением идут обратно в разработку.

Больше работы с людьми
Я думаю, тут не надо объяснять, что когда ты пишешь код, он работает достаточно предсказуемо, понятно и покладисто. Когда ты работаешь с людьми - это невероятный рандом и тут нужно запастись хрустальным шаром, валерьянкой и большим запасом терпения. Вот вам классическая картинка про это https://cs4.pikabu.ru/post_img/big/2015/06/22/9/1434981752_1194744087.jpg

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

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