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

  1. Не читай документацию. Она только путает и отвлекает от настоящей работы — гугли ответы на форумах и копируй чужие решения с StackOverflow или GPT.

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

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

  4. Специально переусложняй реализацию. Чем запутаннее твое решение, тем более высоко смогут оценить тебя коллеги. Ведь это покажет, что ты можешь реализовать “сложные” решения.

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

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

  7. Не используй системы контроля версий. Зачем усложнять себе жизнь Git? Просто сохраняй файлы с названиями project_final_v6_final2 (FINAL).zip. Просто потом их в чат можно скинуть автору задачи, он там сам разберется уже. Зато ничего лишнего не будет в архиве.

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

  9. Забудь про резервное копирование. Бэкапы — удел тех, кто не уверен в том что делает. Но ты то совершенно точно все делаешь правильно.

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

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

  12. Тратить время на свое обучение больше не нужно. Ты ведь уже итак специалист: закончил курсы, посмотрел пару уроков на YouTube, почитал несколько статей — достаточно. Все остальное просто на практике доберешь. Лучше всего все изучать сразу на практике без нудной теории. Вот когда коснется чего то, тогда и изучишь.

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

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

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

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

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

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

Спасибо за внимание. Надеюсь мне удалось немного поднять вам настроение. Если хотите - можете заглянуть ко мне в тележку https://t.me/devopsbrain.

UPD: всем спасибо за комментарии - с вашего позволения лучшими советами буду дополнять этот пост. Итак, что еще:

  • Никогда не просите повышение, сами все дадут и предложат

Комментарии (11)


  1. dyadyaSerezha
    21.01.2025 03:57

    Это все советы второго уровня, в вот главные вредные:

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


    1. Habr_Somebody
      21.01.2025 03:57

      Эти советы не только для IT, они верны вообще для всех


  1. boopiz
    21.01.2025 03:57

    открыл документацию, а там написано: "хер знает, как оно тут работает, но иногда, закон Ома перестаёт действовать". попросил помощи у коллег, один полез в gpt который открыл страницу в стэковерфло, старшие коллеги поплевались и пошли на sql.ru, а самые продвинутые на govnokod.ru. хотел сделать задачу баш скриптом в 3 строки, но все стали смеяться и заявили, что обязательно нужно использовать самый распоследний модный фреймворк, являющийся 13 надстройкой над интерпретатором. открыл код и увидев переменные x, xx, _x2, xXx, xyz, index, ix, idx в одном if условии рука сама потянулась писать xxxx..
    протестировал функционал автотестами, но пользователь запустил приложение в текстовом браузере.
    сделал коммт в ветку и запушил, но после наката пришлось на проде патчить руками потому что легла база и откат невозможен, так как поменялась схема, а бэкапы лежали рядом. и тд и тп


    1. Billander
      21.01.2025 03:57

      Это знак! Пора написать собственную реализацию на 50 фреймворках с балдежными переменными)


  1. gun_dose
    21.01.2025 03:57

    Пароли храни в текстовом файле

    В идеале пароли хранить надо в документации, потому что там их точно никто не найдёт


    1. cupraer
      21.01.2025 03:57

      Я в README.md храню, в секции «Пароли», сразу после «Мои банковские счета с CVS».


    1. itcaat Автор
      21.01.2025 03:57

      О даа, а еще лучше прям в гите


  1. kuzzmenka
    21.01.2025 03:57

    Вредные советы командам разработки и их хозяевам

    • Набирайте 15 джунов вместо трёх мидлов или одного сеньора. Помните как в басне у Толстого? Много веточек, связанных вместе не сломаются. Фреймворк на фреймворке из фреймворков джун джуна джуном погоняет, ноукод зерокод гомнокод только в путь, и все у вас будет отлично, производительность приложения на на уровне.

    • Вы видели, новые флагманы от Самсунг на 512 гб? Ну так и ничего, что ваше приложение на две кнопки и 30 строчек кода будет весить 450 мб. Ну да, оно с тем же функционалом 10 лет назад весило 15 мб, но мы же должны быть в тренде. Говорят, владельцев андроидов с 32 гб памяти сбрасывают со скалы.

    • Закон Мура помните? Его нужно срочно нивелировать вашим приложением!

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

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

    • Перед приёмом на работу обязательно дайте тестовое задание. Идеальный кандидат должен иметь в в памяти всё, что можно нагуглить за секунду. Если не помнит, пусть проваливает и продолжает индексировать пока не будет знать все.

    • Офис - это очень важно. Офис - это команда и сплочённость. Обязательно все должны быть в офисе. К одному времени. А за опоздания лучше штрафовать.

    • Пока не обеспечите совместимость сайта с internet explorer 6, домой никого не отпускать.


  1. FroseMan
    21.01.2025 03:57

    Никогда не просите повышение, сами все дадут и предложат


    1. itcaat Автор
      21.01.2025 03:57

      В точку!


  1. Dendilz
    21.01.2025 03:57

    Всегда используй git push --force, так гораздо быстрее и удобнее