Что айтишнику не стоит делать в 2020?

    Хабр полон прогнозов и советов о том, что делать в следующем году — какие языки учить, в какие сферы сворачивать, как поступать со своим здоровьем. Звучит вдохновляюще! Но у любой медали две стороны, и мы спотыкаемся не только в чём-то новом, а по большей части в том, что делаем каждый день. «Ну почему меня никто не предупредил!», — раздражённо восклицаем мы, обычно обращаясь к самому себе. Вызываем огонь на себя — мы собрали для вас список того, что НЕ стоит делать в 2020 году (а может, и всегда). 


    А гравитацию-то и не спросили

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

    Не надо идти в айти, если всё хорошо


    Не изучайте новую технологию, чтобы сменить профессию или начать с нуля. Наше время прекрасно тем, что можно обучаться, менять работу, в корне менять сферу — и так хоть до самой пенсии. Это классная, соблазнительная штука. Но если вам больше 28-30, не стоит бросать всё ради того, чтобы войти в IT или уйти в новый стек (например, вы пишете высоко нагруженные системы на Java и внезапно решаете уйти в нейросети на Python). Причина простая: вам будет непросто. Во-первых, высока конкуренция со стороны специалистов, которые «сидят» на этом стеке с начала своей карьеры, во-вторых, вам придётся снова стать джуниором с низкой зарплатой, в-третьих, вам будет морально непросто стать подчинённым самого низкого уровня иерархии. Поэтому, если хотите двигаться в другую сторону, старайтесь это делать либо в русле текущей работы и текущих задач, либо развивайте новое знание как хобби, пилите пет-проект, чтобы прийти на новую работу уже не джуниором. 

    Стек на стек менять — только время терять


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



    Не нужно стоять на своём и бронзоветь


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

    Своя голова хорошо, всегда хорошо


    Не думайте чужими головами, своя — лучше. Увы, некоторые разработчики сидят и ждут, когда им поступит задание кодить от предыдущего error-а и до end-а, не пытаясь внести в проект что-то своё, разработать новую функцию, протестировать и предложить в продакшен. Зачем утруждаться, когда есть голова тимлида или руководителя компании, которые сами всё решат? Если вы узнали себя, то у нас плохие новости: пассивная позиция не поможет ни в карьере, ни в развитии. У вас есть шанс попробовать свои силы инженера-разработчика, а не кодера в настоящем боевом проекте и понять, куда двигаться, чего не хватает, но вы предпочитаете потратить своё время на что-то другое и делать ровно «от сих до сих». Такие в современном айти выживают всё хуже, выходите из анабиоза. 

    Пользователи — страшные люди


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



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

     

    Хватит гуглить!


    Перестаньте обращаться к одному только Google. Даже спорить не будем — в сфере разработки прямым запросом к поисковику можно найти очень многое. Чем глубже вы закопаетесь в поисках информации, тем больше «боковых» данных вы получите и больше узнаете, потому что будете узнавать что-то новое, не связанное с вашим запросом, но вероятно нужное в будущем. Обращайтесь к полноценным материалам, книгам, статьям и т.д. У языков и библиотек есть спецификации, коммьюнити, how to и таким образом вы получаете самый надёжный способ развивать навыки программиста — просто читать документацию, а не искать чужие локальные решения и фрагменты кода. А вдруг ваше решение будет оптимальнее, быстрее и круче? 

    Доверяй, но проверяй


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

    Делайте бэкапы!


    Прекратите не делать бэкапы или держать их на тех же сторонних серверах, где хостится ваш проект. Думаете, смешной и напрасный совет? А вот более 700 участников чата в Телеграме, попавших в недавнюю неприятную ситуацию с остановкой одного известного дата-центра, так не думали — чего там только не было: от пет-проектов до крупных сайтов гос. органов и корпоративных баз 1С и биллинга. Значительная часть — без бэкапов или с бэкапами там же. Так что распределяйте риски и храните бэкап как минимум на основном хостинге, на каком-нибудь надёжном VDS и у себя на локальном сервере. В конечном итоге это выйдет гораздо дешевле. 

    Хватит проносить своё в ущерб проекту


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

    Не код, а комок нервов


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



    Keep it simple, stupid


    Не усложняйте код, решения и проекты. Не нужно городить сложную структуру и плодить сущности без особой значимости. Чем сложнее ваш код, тем больше вы становитесь его заложником — вам будет максимально сложно его поддерживать и развивать. Конечно, знаменитый принцип KISS («Keep it simple, stupid») подходит не всегда, но он создан не зря: простота и изящность кода — залог успешного его применения и переиспользования.



    Предохраняйтесь


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

    Не плюйте в колодец


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


    Так делать тоже не стоит. Но, как показывает опыт, не перестанем

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

    С любовью,
    команда RegionSoft Developer Studio

    В новом году мы продолжим работать для вас и развивать мощную десктопную CRM-систему RegionSoft CRM и простой и удобный хелпдеск и тикет-систему ZEDLine Support.
    RegionSoft Developer Studio
    CRM-система, программное обеспечение для бизнеса

    Комментарии 66

      +3
      и, как только найдёте что-то крутое и полезное, — смело тащите в проект!

      Спорное заявление. тащить в проект новые вещи нужно осознанно, а не когда нашел что-то крутое и полезное.
        0
        Об этом в статье тоже есть.
        +5
        Не используйте библиотеки и фреймворки, созданные сторонними разработчиками, не проверяя код и не адаптируя его под свои цели. У вас нет никаких оснований безоговорочно доверять этому автору кода, которого вы вообще не знаете.


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

        И не забудьте объяснить бизнесу куда вы потратили все время отведенное на работу над имплементацией новой фичи. Бездумное использование чужого кода это безусловно плохо, но нужно находить баланс. Вы слишком категоричны.
          0
          Слушайте, мы на Хабре :-) Если бы мы писали на пикабу или в журнал «Школьная разработка», мы бы жевали каждое слово и статья заняла бы 4 печатных листа. Наверное, хабровчане прекрасно понимают, что речь прежде всего о небольших частных разработках — на одном Хабре за год мы прочитали минимум пять статей от «создателей фреймворка». Категоричности в наших словах нет и не предполагалось — это отдельные советы для разработчиков, которые уже что-то понимают в деле :-)
            +12
            Наверное, хабровчане прекрасно понимают

            Что у библиотек и фреймворков, написанных сторонними разработчиками есть один фатальный недостаток…
          0
          не стоит бросать всё к чертям и переписывать на Dart, только потому что он показался вам интересным.

          Почему именно Dart привели как пример?
            +1
            Потому что это самый быстрорастущий язык 2019 года (на фоне дикой популярности Flutter). Довольно наглядный пример, против Дарта ничего не имеем :-)
              +2

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

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

            Лучше интуитивно-понятный интерфейс, чем самая классная документация и прочие мануалы.
              0
              Но это напрямую противоречит пункту :)

              Хватит проносить своё в ущерб проекту

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

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

                +4
                или уйти в новый стек (например, вы пишете высоко нагруженные системы на Java и внезапно решаете уйти в нейросети на Python). Причина простая: вам будет непросто. Во-первых, высока конкуренция со стороны специалистов, которые «сидят» на этом стеке с начала своей карьеры, во-вторых, вам придётся снова стать джуниором с низкой зарплатой


                Делал это уже 2 раза.
                Если у вас за плечами есть база — то в новый стек вы втыкаете куда как быстрее тех, что настоящие джуны.

                По моему наблюдению — 2-3 месяца и ты на своем прежнем уровне миддла или сеньора, что был у тебя в другом стеке.

                Ну, если ты на прежнем стеке балду не пинал, конечно.

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

                Грустно по деньгам это 1-2-3 месяца (в зависимости от поставленной цели). Да не такая уж это и проблема, если у вас есть опыт найма, то и за деньги разговаривать более-менее умеете.

                  +2
                  Мне 45 лет, последний раз стек менял лет 5 назад (с C++ на фронт-энд). Я бы, вероятно, на это не решился, если бы компания, в которой я работал, не начала новый проект и хотела обойтись без найма новых сотрудников. Так что мне повезло, готовы были терпеть отсутствие опыта.
                    0

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

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

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


                        Впрочем, свой стек тоже менять хочу.

                        • НЛО прилетело и опубликовало эту надпись здесь
                            0

                            На более академические вещи.


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


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

                            • НЛО прилетело и опубликовало эту надпись здесь
                                0

                                А это хороший вопрос.


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

                            +1
                            вебдев !== javascript. Там же и другие языки есть, где все стабильно.
                            Да и в C++ новые стандарты клепают.ся
                              0

                              Так новые стандарты JS/C++/TS/etc — не то же самое, что новый фреймворк/инструмент для сборки/етц.


                              Хотя, я слышал, в вебе вроде как всё остановилось на реакте из фреймворков-то.

                                0
                                !==

                                Нутк да, конечно…
                                  0
                                  Я на многих языках пишу, чаще всего такую конструкцию пишу на php. Вашего комментария (сарказма?) не понимаю. Можете объяснить?
                                    0
                                    Это оператор js. Прикольно было, не обижайтесь:)
                              0
                              А как относитесь к rust? там тоже все кипит и бурлит можно сказать.
                        +5
                        Но если вам больше 28-30, не стоит бросать всё ради того, чтобы войти в IT или уйти в новый стек (например, вы пишете высоко нагруженные системы на Java и внезапно решаете уйти в нейросети на Python). Причина простая: вам будет непросто.

                        Тоесть если ты пишешь высоконагруженные системы на Java, то ты не в IT?
                        Кому ты нужен в 35 без опыта? Сидеть дальше = похоронить возможность смены сферы деятельности. Жена и спиногрызы тоже врядли поддержут 40 летнего папку который в творческом кризисе и поиске своего пути.
                          0
                          «чтобы войти в IT или уйти в новый стек»
                          (нагруженные системы на Java)->(нейросети на Python) = «уйти в новый стек»
                            0

                            В 29 лет просто взял и сменил стек Qt/Qml на rust/blockchain. И заняло это немного времени, по сути пару месяцев, на сеньорный уровень вышел ну где-то через пару месяцев.
                            Но я любил интересоваться всякими новинками и имел базовое представление о computer science.
                            Развивайте гибкость ума и тогда этот совет не будет к вам относится.

                              +1

                              Мне интересно, или в странах бывшего СССР другое понятие вкладывается в seniority разработчиков, или "там" все "ленивые жопы", но пару месяцев до senior уровня — выглядит странно.

                                0

                                Потому что язык это лишь инструмент, а реально дело тащят общие hard skills в сочетании с адекватным уровнем soft skills.

                                  0
                                  Мне интересно, или в странах бывшего СССР другое понятие вкладывается в seniority разработчиков, или «там» все «ленивые жопы», но пару месяцев до senior уровня — выглядит странно.


                                  1) Дык не с нуля же. Сложно учатся парадигмы, принципы, концепции паттерны. А они от языка в язык повторяются. Сам язык учится не сложно. Другое дело, что новички в программировании во время изучения своего первого (возможно и второго тоже) языка изучение парадигм, принципов, паттернов, концепций не отличают от изучения собственно самого языка программирования.

                                  2) Сторого говоря, сеньорского уровня в языке программирования вообще не бывает. Сеньорский уровень — это архитектура приложений. Собственно, тем сеньор от миддла и отличается.
                              +3
                              Не гадьте своему работодателю. На сегодняшний день коммуникации достигли такого уровня, что, например, все HR-ы города заочно знакомы между собой и могут обменяться любой информацией в чатах и закрытых группах (как помочь трудоустроиться, так и написать «Василий Иванов, системный архитектор, перед уходом убил все учётные записи, затёр бэкапы и отключил сеть, восстановление заняло 3 суток. Не берите его на работу»). Таким образом, ваше поведение сыграет исключительно против вас — и иногда не поможет даже релокация в другой город или столицу. Даже если вы уходите с обидой, нет лучше мести, чем стать полезным и классным сотрудником конкурента :-) А главное, полностью безнаказанно.


                              А объединяться против работодателя, чтобы повысить свои трудовые условия — это гадить, например? Или требовать повышения оклада и отказ от переработок?
                              Просто интересуюсь, не подумайте.
                              Напоминаю, что «гадят» работотаделю не из вредности характера, а, зачастую, по объективным причинам, вроде эксплуатации. А увольнений или плохой репутации работники боятся всё меньше, и хорошо сие.
                              А что касается мести, то есть самый эффективный выход — перераспределить максимально большое количество благ от обидевшей компании в пользу обиженного работника. И лучше, если работника поддержит профсоюз.
                              С наступающим, не забывайте о своих правах, специалисты.
                                +8
                                А увольнений или плохой репутации работники боятся всё меньше


                                От хорошей репутации есть большая польза.

                                Меня и через 10 и через 15 лет находили те, с кем работал (телефон никогда не менял).
                                И через них, уже по рекомендации, я получал существенно более выгодные предложения, которые любому «по объявлению» не дадут. Причем без каких либо усилий с моей стороны в настоящем. Репутация из прошлого нагоняла и благодарила. Ибо — рекомендация это сила.
                                +1
                                В общем как всегда.Будьте хорошим мальчиком, будьте проактивны, и ни в коем случае не показывайте характер, а то большие дяди вас загонят в нищету. Кстати а такие закрытые чаты вообще законны?
                                  +3
                                  Будьте хорошим мальчиком, будьте проактивны, и ни в коем случае не показывайте характер, а то большие дяди вас загонят в нищету
                                  Ни в коем разе мы такое не писали! Характер показывать надо, его нужно использовать для достижения целей, но если ваш характер на 90% состоит из г***, лучше держать его при себе — зачем портить настроение коллегам только потому что вас всё бесит (ну бывают же такие, блин!).
                                  большие дяди вас загонят в нищету
                                  Адекватным большим дядям плевать на характер и хорошесть, главное — профессионализм и умение классно работать, а подход хороший руководитель найдёт к каждому.

                                  Вот вам анекдот про плохих мальчиков, их загоны и подход истиного лидера

                                  18+
                                  Вовочке сильно надоел урок русского языка.
                                  Он поднял руку и спросил:
                                  — Марья Ивановна, а ПОХ** пишется вместе или раздельно?
                                  За что его удалили из класса до конца учебного года. Чему он очень обрадовался.
                                  Но Мария Ивановна ушла в декрет, и язык начал вести старый, умудренный опытом
                                  Абрам Исаакович. Он позвонил родителям Вовочки и сказал, что тот опять может
                                  ходить на уроки.
                                  Вовочку это не устраивало, и на первом же занятии он спросил:
                                  — Абрам Исаакович, а ПОХ** пишется вместе или раздельно?
                                  — Это — когда как, — ответил старый учитель, — если, молодой человек, вы имеете
                                  в виду мое отношение к вашим закидонам — то вместе, а если глубину великой
                                  еврейской реки Иордан — то раздельно.
                                    0
                                    главное — профессионализм и умение классно работать,

                                    Давайте подходить инженерно к формулировкам?
                                    Какие критерии профессионализма и классной работы?
                                    Это красивые слова, такие как адекватность, хороший руководитель и тд. Но они слишком абстрактны. И в жизни принимают совершенно особые цвета =)
                                      +1
                                      Профессионализм:

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

                                      Классная работа:

                                      • в сроки
                                      • самостоятельно
                                      • качественно
                                      • с соблюдением необходимых норм (code style, протоколов лечения, норм, стандартов — смотря о ком мы говорим).

                                      Адекватный руководитель — руководитель, который:

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

                                      Да, особые цвета и оттенки есть, но в целом это интуитивно понятные качества. Вряд ли можно представить себе ГОСТ на хорошего руководителя. Для кого-то хороший руководитель — тот, которого нет на месте и который отпускает 30 и 31 декабря отдыхать ;-)
                                        –1
                                        Вот честно, сколько видел коллективов. Ни в одном не было соблюдения хотя бы 60% этих пунктов.
                                          0
                                          За свою карьеру видел много коллективов, и в результате понял простую вещь:
                                          Ты должен сделать добро из зла, потому что его больше не из чего сделать. (с, Пенн).
                                          Хотите работать в нормальном коллективе — сделайте его своими руками. Хотя инициатива в этом вопросе, безусловно, наказуема тем, что реализацию/реструктуризацию свалят на вас же, но и в зарплате это отразится (рано или чуть позже, но это скорее правило), да и вообще — это неоценимый социальный опыт. Люди, которые занимались этим в коллективе, на моей памяти почти всегда становились после руководителями проектов и далее. Не желаете?
                                          Конечно, страдать и жаловаться — более простой путь.
                                            0
                                            Знаете, я не жалуюсь. Мое отношение к подобным статьям, мне они не нравятся.
                                            Они, если просто сказать, имеют перекос не в сторону работника. Наверное они создают посыл будьте удобны нам, и ни на что не претендуйте. Сделайте больше, а мы (работодатель) посмотрим, и если нам понравиться, может быть поощрим, а если не понравиться " нуу мы же не просили".
                                            По поводу проактивности, у меня был такой опыт, даже несколько раз, в различных позициях. И я не могу назвать его положительным, я то выполнил цели, а вот оценены они не были. Собственно отсюда мое мнение, через призму моего опыта =)
                                              +1
                                              Если ваши успешные усилия по реструктуризации не оценены (не обязательно сразу), то у организации что-то не то в мотивационной модели.
                                              Вообще, приводя в порядок свой коллектив, вы должны «продать себя», свою новую ценность внутренним HR, руководители должны знать, что вы делаете, и увидеть ваши результаты. Это критически важно. На моей памяти проблем с этим не было. Просто вознаграждение бывало разное. Премия. Пакет корпоративной расширенной мед-страховки с кучей допуслуг на год (понравилось, кстати, очень). Перевод в более высокий грейд… да и вообще — с тобой начинают общаться по-другому уже.
                                              Если уж совсем никак не отмечают — печально.
                                              Ну в любом случае ваш опыт остался с вами, а организаций на рынке много.
                                          +2

                                          Осталось только это доказать новому работодателю.
                                          А доказательств не будет, ибо NDA и прочее.
                                          Вот тут выйдут наружу связи, рекомендации, знакомые, просто коллеги.
                                          И крутых ребят, внезапно, не берут никуда, т.к. спросили там-тут, а человек "чудак на букву М", хоть и пишет качественно и в срок, и на собеседовании хорош.
                                          Особенно такое актуально, когда рынок относительно небольшой и через 2-3 человека можно узнать.

                                    0
                                    Не изучайте новую технологию, чтобы сменить профессию или начать с нуля.

                                    Да ладно, работы на всех хватит, что Вам жалко, что ли?
                                      0
                                      Дочитайте до конца :-) К слову, человек, пишущий именно этот комментарий, начинал с нуля трижды (и это не предел) — и да, быть джуниором местами было неприятно.

                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        –1
                                        Почему 28-30 лет — это пару лет после учёбы? Кажется, только у врачей так может быть. Разработчики, сисадмины, менеджеры и т.д. работают с 21 года, а то и раньше. За 10 лет можно неплохо вырасти и прокачаться.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            0

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

                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                  0

                                                  И все вокруг топы, а кто не топ — ленивые неудачники?

                                            –1
                                            Не изучайте новую технологию, чтобы сменить профессию или начать с нуля. Наше время прекрасно тем, что можно обучаться, менять работу, в корне менять сферу — и так хоть до самой пенсии. Это классная, соблазнительная штука. Но если вам больше 28-30, не стоит бросать всё ради того, чтобы войти в IT или уйти в новый стек (например, вы пишете высоко нагруженные системы на Java и внезапно решаете уйти в нейросети на Python).


                                            Абсолютная фигня. Все течет, все изменяется, застагнировать на одном стеке — лучший способ перейти из сеньоров в джуны, когда не готов.
                                              –1
                                              Перечитайте посыл ещё раз: не НЕ делать, а если что-то хотите изучать и менять, делать в параллели, чтобы не потерять по времени и деньгам. Если у вас есть другой опыт — делитесь :-)
                                                0
                                                В 42 сменил направление (веб-разработка ушла на второй план, на первом оказалась обработка больших данных и машинное обучение) и заменил обычный стек для веб-разработки (и попутно страну) безо всяких понижений.

                                                Что значит «делать в параллели»? Я должен один и тот же проект реализовывать в рабочее время привычным для себя методом, а в свободное делать то же бесплатно? Вот уж где потеря времени и денег. Моего личного времени и денег, которое я затрачу на по сути бесплатный для нанимателя RnD. С точки зрения вас как работодателя, ваш пост мотивирует разработчика на выгодное для вас, но невыгодное для него поведение. Это называется «манипуляция».
                                              +2
                                              >Но пользователям почему-то не нравится находить баги на продакшене — никакой в них айтишной солидарности.
                                              Когда ПО стоит $1,5k+ на одно рабочее место — об айтишной солидарности как-то забываешь.
                                                0
                                                Так это и был сарказм. Не должно быть багов на проде ни в софте за $1,5k, ни за 100$.
                                                  –3

                                                  Кому не должно?

                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                  0
                                                  Так на руках, вот и не удобно. В остальных случаях волосы не могут причинить неудобства — не смогут встать дыбом, прижатые ;-) Не надо представлять лишнее, это просто юмор на картинке.
                                                  +1

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

                                                    +1

                                                    Ожидал другого списка о том что не стоит делать именно в 2020, а не в любом другом году.

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

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

                                                      ..., но вероятно нужное в будущем.

                                                      А вероятно и не нужные в 99% случаев детали. Я конечно не буду утверждать, что лучше, но я как раз от этого пункта периодически страдаю. Может быть правильнее решать задачи по мере их поступления, а не копаться «про запас»? Время — ценный и не возобновляемый ресурс.
                                                        +3
                                                        Кардинально сменил стек в 35 лет. Тяжело было только в самом начале. Сейчас безмерно счастлив и жалею только о том, что не сделал этого раньше.
                                                          0
                                                          Что на что?

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

                                                      Самое читаемое