Ответы пользователя по тегу Организация работы
  • Информация для мозга во время перерывов между программированием в течение рабочего дня?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Серфи не разные сайты, а один конкретный.
    Я вот нашел для себя тостер. Иногда вопросы на тостере заставляют сбегать на википедию или SO.
    Иногда, когда хочу напрячься, хожу на SO, но там вопросы посложнее, поэтому на тостере я больше отдыхаю.

    По новостям вообще не бегаю, это плохой вариант для отдыха.

    Ну и еще юмор, но немного. Конкретные пару исполнителей найди и все.

    А так - самодисциплина. Час поработал, 5-10 минут отдохнул.
    Ответ написан
  • Как правильно вести разработку на Django и TeleBot?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    git-flow?
    Ответ написан
  • Почему в компаниях сидят на linux и нельзя на windows?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Зачастую в качестве рабочей машины может быть любая ОС, но веб сервера в основном крутятся под линукс.
    А также контейнеры крутятся под линукс.
    под MS IIS сервер в основном могут крутиться внутренние ентерпрайз решения, редко публичные порталы.

    Поэтому да, Линукс - это то, где скорее всего будет запускаться ваше приложение, и опыт работы с Линукс нужен чтобы ты мог зайти на сервер, посмотреть логи, отладить.
    Если нет автоматического ci/cd, то выложить приложение, поправить конфиги, запустить руками.

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

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Вообще не важно сколько стоит компьютер на рынке.
    Если он куплен в организацию, у него есть его стоимость на балансе у организации, в зависимости от того, как он приобретался (например с лицензионной ОС и другим софтом, который за ним может числиться как 1 комплект), и у бухгалтерии не факт что есть возможность этот комплект разделить.
    Там же может проводиться или не проводиться амортизация.
    Поэтому компьютер оценивать может только бухгалтер, который списывает его с баланса организации.
    Вы сперва уточните готовы ли они вообще на такую операцию, а потом уже "оценивайте".
    Ответ написан
  • Почему я не могу кодить временами?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Экстасенсов не существует. Диагнозов понаставляют...
    Или подобрать нюни или к врачу.
    Ответ написан
  • Страх, что программист отберет сайт?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    1. Если у вас постоянно текучка программистов, следует переосмыслить ваше отношение к тому, как вы их нанимаете и что от них требуете. Работайте с одним программистом или одной командой.

    2. Сделайте два сайта - один для разработки, другой боевой. И научитесь переносить с сайта для разработки на боевой изменения. Программистам давайте доступ к сайту для разработки

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

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    А в вашей команде есть тестировщики?
    А в вашей команде code review есть?

    Баги - это нормальная ситуация, и их надо просто исправлять а не бояться выявить.
    Ответ написан
  • Сеньоры и лиды - это всегда обуза и зло, а работают джуниоры и миддлы? Или только у нас в компании?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Я джуниор. Мне приходилось работать в команде (одной и той же) над разными проектами. Один из проектов обнищал, не смог больше кормить команду. И там теперь всего один разработчик. Всего один разработчик в проекте с непростой архитектурой, с C++, JavaScript, Node.js и Lua. И он джуниор. И он - я.

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

    Все проекты, с которыми мы работали, это форки, или мы вообще подрядчики. То есть код не наш. Соответственно главная (по мне) проблема это изучить код. И от сеньора и лида здесь пользы не бывает. Потому что отвечают они на твои вопросы по коду не быстро, не всегда, и вообще не обязаны отвечать.
    А изучать код сам я вполне могу и без сеньора и лида.

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

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

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

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

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

    Без сеньора и лида я рискую сорвать лишь более-менее глобальный дедлайн. И тогда меня пошлет заказчик и придется умолять заказчика вернуться. Всего 1 раз! А сеньор и лид за это время раз 5 успели бы меня отругать.

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

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

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

    Без сеньора и лида я так же делаю упор на сдачу в срок и на безбажность. На качество иногда подзабиваю. Зато всегда спокоен и уверен, что если что-то сдаю, то это навсегда. И соответствующим образом проверяю код на баги. Делаю саморевью, а от него куда больше пользы, чем от ревью сеньора и лида, которое ищет где поэстетствовать, а не где баг. Число багов после ухода команды резко упало.

    Если навсегда, то почему в принципе вы еще пишете код? Разве он не должен был быть уже давным давно написан навсегда?
    Баги могут быть технические и логические. Если вы хорошо знаете бизнес заказчика - это одно.
    Число багов после ухода команды может упасть потому что разработка упала. Гораздо меньше багов, если никто ничего не пишет, это же Л - Логика.

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

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

    Сорри за много букв и у меня вопрос, это везде так или от сеньора и лида бывает и польза?

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

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Для начала с терминологией.
    Overtime - это работа на работе во внеурочное время, СОГЛАСОВАННОЕ и одобренное с заказчиком. Обычно оно оплачивается или компенсируется.
    А то, что вы просто задерживаетесь на работе по личным причинам - это просто ваше личное желание.
    Если у вас какая-то проблема, никто не мешает пойти домой, сесть за комп, и разобраться с технологией, проблемой.

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

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

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

    Собственно основная проблема увлечения чем-либо одним заключается в том, что чем дальше - тем сложнее самостоятельно выйти из западни. Поэтому самый простой совет - не углубляться слишком далеко.
    Ответ написан
  • Что делать с джуниор программистом, который самоучка и не с этой планеты?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Если человек не понимает, что деньги платят не за сделанную задачу, а за сделанную задачу в срок - то штрафовать его за каждый раз, когда он проваливает дедлайн. У него резко понизится мотивация делать какие-то костыли и повысится мотивация успевать в дедлайны.

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

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

    Это ОЧЕНЬ СТРАННО, когда дедлайны целого проекта зависят от ДЖУНА. Что-то в вашем проекте вы недоговариваете.
    Ответ написан
  • Что подразумевает полный рабочий день?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Что подразумевает полный рабочий день (на удаленке)?


    Обычно это подразумевает 40 часов в неделю.

    ВСЕ остальные нюансы - примеры перечислены ниже, зависят от конкретного работодателя:
    * когда начинать и когда заканчивать, может зависеть от часового пояса клиента или команды
    * нужно ли постоянно быть на связи, зависит от проекта и обязанностей.
    * активно работать - зависит от обязанностей. Например дежурный админ должен все время следить за уведомлениями мониторинга, а пойти на 2 часа обедать
    * Отчитываться о реально потраченном времени может быть обязательно или не очень, или только по бумажке.
    * Нужно ли ставить софт, который будет следить за вашей активностью или не нужно

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

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Есть определенные требования к альфа, бета и полному релизу.
    Если требования к альфа выполнены, и альфа запланировано, то ее нужно выводить.

    А потом, наверно, надо будет выпустить еще одну версию, устранив и перекроив часть проблем. А потом еще. Какой-то подход "лишь бы не сидеть сложа руки".


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

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

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

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

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Мой главный герой - фронтенд-разработчик, а компания, в которой он работает (крупная и ведущая в стране) - занимается аутсорсингом и консалтингом в сфере IT.


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


    Крупная компания - это 1000 человек минимум. А лучше 3-5к людей.
    Проект, в котором всего 2-3 разработчика это просто ни о чем. В аутсорсинге такие мелкие проекты - это нонсенс, нет смысла искать заказчика и заключать с ним договор, выделяя всего 3-5 человек. Разве что это мелкие под-проекты внутри одного большого заказчика.
    И если герой - единственный главный разработчик то он и будет тимлид, потому что тимлид - ведущий разработчик, иногда совмещающий системного архитектора.

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

    Либо сделать ГГ тимлидом, либо добавить еще человек 10-15 минимум в проект.

    2. Какого рода проекты обычно поручают команде? Сайты, ПО, приложения? Поскольку главный герой - фронтенд, и сама команда талантами не блистает, нужно что-то не слишком обременительное.

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

    3. Роль руководителя (тимлида). Как он обьясняет своей команде то, что хочет заказчик? Как часто он появляется в офисе и контролирует ли процесс работы? Как общается с подчиненными - в роли злого начальника или на равных?

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

    4. Дедлайны разных проектов (например, сколько по времени делается один сайт и во сколько этапов?)

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

    5. Может ли заказчик советовать вносить правки, если его не устраивает результат? Перед работой вообще заключаются какие-то договора и кто за это ответственен?

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

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

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

    7. Сисадмин. Он в одном офисе со всеми работает или в другом месте где-то? Как выглядит его рабочее место? Нужен ещё процесс его работы. Если можно, опишите простыми словами.

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

    8. Тестировщики. Они, вроде, тестируют почти в самом конце, когда все готово. Но, наверное, и в начале проекта они что-то делают?

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

    9. Разработчики для ios и android. Если требуется сделать мобильное приложение, то как эти разработчики взаимодействуют с остальными членами команды?

    Также как и все.

    10. Аналитик. Он точно нужен, или его роль может играть и тимлид?

    Чтобы написать сайтик - не нужен. Чтобы написать бизнес-приложение нужен.

    11. Состав команды, в целом, может меняться, в зависимости от проекта? Куда в таком случае отправляют «ненужных» работников? В другую команду?


    12. Миттапы, совещания, летучки. Как часто проходят, кто участвует и что там обсуждают?

    Зависит от того, какой agile настроен. Вдобавок они могут быть между конкретными командами или даже между конкретными людьми.

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

    У них есть какие-то особые темы для обсуждений или они могут как и обычные люди

    они могут как и обычные люди

    Нет, мы Марсиане.

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

    Могут быть специальные служебные помещения. Например туалет, кухня, ресепшн. Может быть и серверная.

    15. Есть какие-то особо важные нюансы, которые непременно стоит ещё упомянуть при описании работы?

    Да. Не пишите книгу про ИТ, если не работали в ИТ сами. Либо найдите знакомого айтишника, который работает, и напишите книгу про его работу.

    Простите, но ваши вопросы вызывают такой диссонанс, что это капец.
    Ответ написан
  • Как вы боретесь с выгоранием?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Найдите себе хобби, на которое хочется тратить время. И работайте по 8 часов, остальное - на себя.
    А вообще - это не выгорание. Это банально "сила воли"
    Ответ написан
  • Правильно ли начинать с простых задач?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Встречается место в котором вы заходите в тупик

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

    В остальном, сложность задач просто занимает определенное количество времени+бюрократия.
    Ответ написан
  • Как эффективно познакомить новичка с проектом?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Человек или понимает или нет.

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

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

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    : «Buddy, у тебя нет тех. бэка, поэтому дай другому челу руль и он тебя приведёт к успеху». Стоит ли рассказывать, что это, мягко говоря, «очень плохой ответ».


    Смотрите, "Евгений".
    Для стартапа у вас должен быть бизнес-план. А именно - кому продавать продукт, кто его уже готов купить и за какие деньги. А у вас на повестке дня просто "как написать продукт".

    Стартап это вообще не про то, что вы тут написали. Для стартапа именно вы должны быть главным техническим специалистом, а не просто спонсором с непродуманной идеей. То есть самая суть вопроса - "стартап" вы пропускаете.

    Вы придумали концепт продукта. У вас уже есть примерное ТЗ. То есть задача осталась простая - просто написать продукт.

    Если вы не разбираетесь в людях и не можете нанять даже технического архитектора, которому готовы доверитсья, что он уложится в указанный бюджет и напишет продукт по ТЗ - ну идете в контору, заключаете договор, они вам пишут
    Если ТЗ нет, то перед выделением 50.000 нанимаете консультанта, который помогает вам написать ТЗ и оценить (можно сразу в контору, которая еще и возьмется потом это писать).
    Но будет ли этот проект приносить прибыль? Сможете ли вы его продать - вот в чем главный вопрос. Потому как хороших программистов, которые могут довольно быстро накопить 50к - много, а стартапов подобного плана - мало. Именно потому что кому оно нужно - это вопрос из области продаж и знания рынка.
    Ответ написан
  • Как работать командой над большим проектом?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    1. Договор - полюбому. Чтобы можно было прижучить.
    В нормальных команиях также секьюрити проводят регулярные таунхолы, особенно для новичков, где рассказывают о безопасности. И приводят пару примеров, как кто-то расшарил кусочек кода, как его засудили на много денег и добавили в черные списки всех компаний.
    Это для тех, кто по глупости может.

    2. Делите исходники на части. Автоматизируйте деплой так, чтобы разработчик это руками не делал и никуда не лазил - сделал коммит - CI сервер автоматом закачал все нужное из разных репозиториев и задеплоил. Надо нескольким разработчикам - сделайте несколько тестовых окружений, чтобы разработчик мог зайти в Jenkins или Teamcity, нажал одну кнопку и выбрал куда ему деплоить. Но своих логинов парлей у него не было.

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

    И это все равно не гарантия. Смиритесь =)
    Ответ написан
  • Какие DevOps практики(инструменты) используете для разворачивания инфраструктуры?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Пример: у меня есть плейбук ansible который разворачивает гитрепозитарий на групе серверов, но я примерно понимаю, что скорее всего, у "больших дядек" это делается не через плейбук, а через jenkins + docker + webhook, но на практике взглянуть на такое я не могу :)


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

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

    Старайтесь не оптимизировать что-либо, а решать конкретные проблемы, типа "вот тут я трачу еженедельно xx часов на рутину. Имеет ли смысл потратить неделю на оптимизацию и сэкономить потом на этом, или рутина связана с процессами, неподдающимися автоматизации (например из-за бюрократии).
    Ответ написан