Полностью понимаю автора с его болью в изменениях. Имел такой опыт работы в компании, где с тебя требуют изменений, но извини людей нет иди мотивируй текущих на дополнительную работу после основной работы. Сам обозначь цель, замотивируй и принеси результат ты же должен работать на результат. В тоге после долгих попыток выбить бюджет, обозначить что руководство должно обозначать цели - я не выдержал и ушёл)) Как сейчас вижу не зря это сделал т.к. прошлая компания всё ещё в поисках волшебства!
всё очень просто. Проще построить пирамиду, чтобы за тебя школьники которые себя считаю хацкерами делали всё эту работу а ты собирал только логи и продавал их. Старая схема сбора персональных данных
Очень знакома и близка "Причина 2: разочарование в работе" историей Дениса. Работал архитектором в компании с численностью от 250 ИТ специалистов. Да, долго через муки и страдания понял что ценности расходятся и как я хотел ИТ компанию тут не построить а готовы только делать сервисный центр для агрохолдинговой компании. Какие либо встречи как автор советует "обсудить ситуацию с руководителем", не помогали т.к. мой руководитель был директор компании и он только подбадривал т.к. его основная цель была удержать любыми правдами и не правдами. Что в итоге делало выгорание только хуже. Совет всем кто подозревает что его работа "не делает мир лучше" и есть симптомы выгорания начать с общих встреч: Начните с обычной ретроспективы, выделите проблемы с командой и сотрудниками с которыми работаете и намети шаги. Если вы увидите что команда в упор не видят проблемы которые видите вы, то попробуйте их раскрыть. Цель понять что корабль в котором вы плывёт по тому-же адресу, который вам нужен. Так вы сразу поймёте стоит ли менять компанию т.к. плыть в корабле не потому адресу только нагоняет депрессию.
В итоге я для себя принял решение сменить работу и полностью этому рад. Да, это было сложно во всех обстоятельствах и были сомнения. Но и тог я рад
Дополню исходя из опыта. В репозитории хорошо иметь не только README.md а ещё и License, Authors и важно Changelog. Все коммиты должны быть связанны с Changelog историей разработки поэтому каждый коммит должен начинатся с {code-task-tracker} а если мы делаем не монолит а микросервисы то мы должны иметь общий индекс системы чтобы понимать ещё и связи {index} и того чтобы понять что это лучше взять в квадратные скобках т.к. вот так git commit -m "[SHOP-ISSUE-994] feat: добавлен вывод строки" # index = shop, code-task-tracker = issue 994 т.к. так трекер не всегда может быть частью git. И нам остаётся только в Changelog указать что мы закрыли issue 994 для shop)))) и естественно описав что изменили.
История коммитов это очень хорошо. Главное не забывать что есть ещё теги, история изменений и правила ветвления. Всё в мести при правильном использования как раз и даёт полноту картины и удобства использования.
Отличные новости, ждём пакет с адаптацией CycleORM под Yii3! т.к. нам в Yii2 не хватает полноценной ORM, которая реализована по модели DataMapper. Так-же кому интересно про ЭФКО можно подробней ознакомиться на Хабр.Карьера https://career.habr.com/companies/efko
да, когда у нас только 3х разделения:
младший — студенты без знаний
программист — те что могут сами уже работать
и сразу ведущий программист — то что описано в статье.
выше это уже начальник отдела, направления и т.д.
Заметил такую же ситуацию практически во всех российский компаниях.
Бизнесу нужны DevOps, а то наберут этих админов и программистов, а они в ответ это не моя задача не в моей ответственности. (сарказм)
Я вот работаю веб-программистов(на каком говне только не пишу), но также администрирую веб-сервера и реализую полную CI интеграцию для проектов. Что я теперь DevOps? Нет я так не считаю, считаю, что я просто могу провести веб проект от начала до конца.
Доля правды в этом есть. Встречал у нас на работе специалиста который всю жизнь писал на беке и тут решил на js написать часть со словами, а там всё просто. Так для того чтобы сделать «динамическую форму» он отправлял на сервере в сесии всю таблицу всё делал на сервере и на клиенте назад принимал сессию (не json). Кто угадает что он делал на клиенте, правильно ajax на jquery. А что он делал на сервере, правильно сортировку и математические вычисления. Странно почему код тормозил.
Я работаю в компании где на каждое действия есть свой регламент. Есть регламенты даже на общение сотрудников внутри офиса и походов в туалет за несоблюдение которые начисляются штрафы. Конечно компания берёт в себя все новые веяния корпоративы, вывозки на природу, но реализует их в соответствие со своими правилами т.е. компания организует, а за корпоротив платишь ты, сходил не по регламенту с тебя штраф, а если не сходил, то пишешь объяснительную. Очередной раз читаю таю статью думаешь, как же у нас переделают под себя.
Может и удобно погрузится а экосистему одного продукта. Но для меня это не плюс мне интересно и нужно чтобы продукт был интегрирован со сторонним софтом и железом. Как выше я писал пока не не вижу чтобы продукты Яндекса вообще как-то работали со сторонним софтом (Их вообще нет в play market с поддержкой больших экранов :-) и управление клавиатурой или пультом вообще лучше молчать :-) )
Ради будильника покупать))) Я про то что интеграция со сторонним софтом страдает. У того же гугл ассистента больше поддержек ПО (но там и так очевидно). А на androidTV так они вообще не могут уже больше 2х лет что-то сделать (считают от отправленных писем в поддержку)
Про Байкал последнее что слышал habr.com/ru/post/451898 а именно про основателя компании “Т-платформы”. Про Эльбрус сорян новость не актуально — последнее что я слышал, видел ОС как бы была открыта но получить её нельзя было. Вроде ситуация изменилась habr.com/ru/news/t/446584
Из наблюдений аналогичных проектов, сложится судьба как у поисковика Спутник, Российский процессор Baikal, ОС Эльбрус. Если бы этим занималась организация которая до этого развивалась в этом направление, то было бы чуть больше доверия.
Полностью понимаю автора с его болью в изменениях. Имел такой опыт работы в компании, где с тебя требуют изменений, но извини людей нет иди мотивируй текущих на дополнительную работу после основной работы. Сам обозначь цель, замотивируй и принеси результат ты же должен работать на результат. В тоге после долгих попыток выбить бюджет, обозначить что руководство должно обозначать цели - я не выдержал и ушёл)) Как сейчас вижу не зря это сделал т.к. прошлая компания всё ещё в поисках волшебства!
всё очень просто. Проще построить пирамиду, чтобы за тебя школьники которые себя считаю хацкерами делали всё эту работу а ты собирал только логи и продавал их. Старая схема сбора персональных данных
Очень знакома и близка "Причина 2: разочарование в работе" историей Дениса. Работал архитектором в компании с численностью от 250 ИТ специалистов. Да, долго через муки и страдания понял что ценности расходятся и как я хотел ИТ компанию тут не построить а готовы только делать сервисный центр для агрохолдинговой компании. Какие либо встречи как автор советует "обсудить ситуацию с руководителем", не помогали т.к. мой руководитель был директор компании и он только подбадривал т.к. его основная цель была удержать любыми правдами и не правдами. Что в итоге делало выгорание только хуже. Совет всем кто подозревает что его работа "не делает мир лучше" и есть симптомы выгорания начать с общих встреч: Начните с обычной ретроспективы, выделите проблемы с командой и сотрудниками с которыми работаете и намети шаги. Если вы увидите что команда в упор не видят проблемы которые видите вы, то попробуйте их раскрыть. Цель понять что корабль в котором вы плывёт по тому-же адресу, который вам нужен. Так вы сразу поймёте стоит ли менять компанию т.к. плыть в корабле не потому адресу только нагоняет депрессию.
В итоге я для себя принял решение сменить работу и полностью этому рад. Да, это было сложно во всех обстоятельствах и были сомнения. Но и тог я рад
Дополню исходя из опыта. В репозитории хорошо иметь не только README.md а ещё и License, Authors и важно Changelog. Все коммиты должны быть связанны с Changelog историей разработки поэтому каждый коммит должен начинатся с {code-task-tracker} а если мы делаем не монолит а микросервисы то мы должны иметь общий индекс системы чтобы понимать ещё и связи {index} и того чтобы понять что это лучше взять в квадратные скобках т.к. вот так git commit -m "[SHOP-ISSUE-994] feat: добавлен вывод строки" # index = shop, code-task-tracker = issue 994 т.к. так трекер не всегда может быть частью git. И нам остаётся только в Changelog указать что мы закрыли issue 994 для shop)))) и естественно описав что изменили.
История коммитов это очень хорошо. Главное не забывать что есть ещё теги, история изменений и правила ветвления. Всё в мести при правильном использования как раз и даёт полноту картины и удобства использования.
Отличные новости, ждём пакет с адаптацией CycleORM под Yii3! т.к. нам в Yii2 не хватает полноценной ORM, которая реализована по модели DataMapper. Так-же кому интересно про ЭФКО можно подробней ознакомиться на Хабр.Карьера https://career.habr.com/companies/efko
младший — студенты без знаний
программист — те что могут сами уже работать
и сразу ведущий программист — то что описано в статье.
выше это уже начальник отдела, направления и т.д.
Заметил такую же ситуацию практически во всех российский компаниях.
Я вот работаю веб-программистов(на каком говне только не пишу), но также администрирую веб-сервера и реализую полную CI интеграцию для проектов. Что я теперь DevOps? Нет я так не считаю, считаю, что я просто могу провести веб проект от начала до конца.