Мне понравилась мысль в статье: это повысить Федю. Неохотно так звучит ещё: не ну давайте его на конференции отправим, давайте его займем менторством, ну можно из тестировщиков в аналитики. А автор не думал, что Феде лучше его место занять?
Не дефиктивного. А менеджеров по русской модели управления: уровниловка и круговая порука. Централизация власти (в своем лице) и прераспределение ресурсов (бесконечная ротация). Иначе если не делать это то в душе русской такая пустота будет, что разрушит на своем пути всякое устройство (процессы поломает, ага). Никакой конкуренции, пусть перформер сходит борщь поварит
Вы написали что не просто хуизху надо знать, вы еще наисали что надо думать об их развитии, а если все это объединить, то мы получаем мотивацию. Надо знать мотивацию каждого и использовать ее для развития бизнеса, а не людей. Развитие людей это инструмент не только их роста, но и выгарания, и тут как бы автор его навязывает, ага, не удивлен что 40% уволилось.
У меня одного ощущение что в статье какая-то невнятная проблема решается путем составления направленного графа следсвенно-причинных пунктов и вершин разрешений, который сходится к стоку: "Погасить перформера"?
Автор, а вы проверяли свой граф на цикличность? Кажется вы упомянули, что стать незаменимым управленцем "мы теперь знаем к чему ведет". Но почему то у меня ощущение того, что Вы занимались микроменеджментом и не только в каком то частном случае, но ей богу ворошить так команду и Федю это надо прям усидчивость и терпение иметь.
Первое правило решения проблем: а есть ли проблема? Тоже самое первое правило гласит, а в чем же проблема? Точно в Феде? А точно в команде? 60 багов то не из-за Феди как оказалось, а не из-за того что ошибки не искали по ходу решения, то есть в процессах.
Ну предположим, что автор не все проблемы опубликовал, и проблемы очень много и они действительно в Феде и в команде, тогда второе правило гласит: а давайте соберем всех лиц, кто причастен к этой проблеме и спросим как решить эту проблему у них, определим ответственного, сроки и критерий приемки результата. Было? Я вижу из статьи, что вместо этого, могучий управленец начал назначать ответсвенных, ротировать всю команду (перформатировать ответственность) и бедного Федю ставить под увольнение.
Единственная здравая мысль в статье, это повысить Федю, причем так неохотно написано: не ну давайте его на конференции отправим, на обучения, давайте его займем менторством, ну можно аналитиком. А автор не думал что Феде лучше его место занять?
фейсайди, пушнотификации, фоновые вычисления, кеширование состояния приложения это неполный список фич нашего ПВЗ и даже свистелка есть, в общем не так легко затащить через Web. А так согласен, для приложения аля стартап бери и пиши на чем хочешь
Проблема xib и storyboard еще в том что 1. системе их надо парсить, держать в памяти - время и ресурсы 2. связь с кодом (вызов событий или переходов на экраны) не гарантирует отсутствия эксепшенов и ошибок, чето переименовали - перестало просто работать, отсутствуют проверки на этапе компиляции короче
Теорию могут заучить почти все. Применять эту теорию на практике могут немногие.
а как вы это делаете? Я не совсем понял. Вот есть вроде намек на "дополнительные вопросы", но вы сказали что они задаются "если ответ не нравится", значит у вас какие то ожидания от кандидата есть, технические, что если например вы ждете от кандидата, что он вам расскажет про барьеры в очередях, а он знает лучшее решение в организации цепочек запросов в сеть с помощью Promise? Вроде дичь, вот уже Combine есть, но в конкретной задаче Combine хуже справится, и как оценить тогда такой ответ?
Еще есть кейс, что после одного из ваши собесов сольют в сеть "правильные ответы" и будут появляться кандидаты, которым не нужно вообще задавать вопросов, потому что они чешут от зубка, как опытные синьеры. Как с этим боритесь?
Вы очень крутую вещь подсказали в статье: "иногда я меняю условия" вот это реально помогает определить софты, а вот про отсев нежелательных личностей, можете пояснить? Как он происходит? Как вы определяете не подходящего для вашей команды человека?
Спасибо большое за дополнение. Но получается, что #Preview теперь уже точно не компилируется? Потому что до SDK iOS 17 все попадало в билд и уже вычищалось во время архивации, соответственно нам пришлось обрамлять своими макросами такие превью, так как их компиляция могла задействовать моки, которые складываются в некомпилируемые пакеты и соответственно на CI возникала ошибка компиляции, теперь этого можно избежать с помощью такого макроса?
Мне статья помогла понять, как кастомизировать данные для переходов на экраны. Спасибо. Так же я сделал форк, чтобы продемонстрировать передачу параметров на экраны (это важный момент) и кроме того добавил диплинки, потому как использовать координатор имеет смысл именно совместно с диплинками, ссылка ниже на форк https://github.com/sofbix/NaviTest
Вы правы, так спасти жизни можно, фича действительно моргинальная, не сколь своим явлением, сколь реализацией. Если залезть под капот SDK Localise, то там обнаруживается Swizzling, работа с Notification Center, обязывание разработчиков обновлять текстовые сообщения в специальном методе. Хочется такой SDK не использовать.
Руковожу в общей сложности с 2013, когда твой отдел достигает 25 людей, то ваще не до признания, и честно говоря, не помню чтобы возникало желание засветиться еще до внедрения, после внедрения и получения профита было дело, хочется делиться своими наработками, скоро про это напишу, кстати. Если бы следующее предложение прочитали после первого, то получили внятный ответ о моем участии в выборе стеков, так то надо мной руководитель тоже есть.
Все впорядке, дружище. Мы выпустили нативку в сентябре, рейтинг приложения с тех пор вырос, пользователи стали более довольны, акции растут. Правильный выбор сделали, главное что результат есть
Вы видимо не часто пишите движки рендеринга на эпловские продукты, раз не видите проблем в рендеринге для такой компании как Google. Может тогда Google в легкую напишет альтернативу iOS? И Apple с этим ничего не будет делать?
Зачем увеличивать штат еще больше у нас полно нативщиков так то, зачем вкладывать в технологии, которые не привели команду к успеху?, чтобы что? Я просто не понимаю, вам нравится Дарт и вы хотите чтоб Озон тоже на Дарте писал? Ну да, у нас зрелая компания которая мониторит рынок, смотрит скорость разработки продукта и знает во что вкладывать, а во что нет. Наш выбор вам кажется необоснованным, наверное у вас другая компания аля стартапа (я писал об этом), полно разработчиков Flutter, которые лезут в форточку готовы получать меньше нативщиков и задачи не требуют написания кучи плагинов и потом их еще поддерживать, нативный мир то тоже не стоит на месте
В SwiftUI встречается множество косяков, но в целом он намного приятнее для разработки и ревью кода, есть даже подозрение что верстка начиная на нем с iOS 14 меньше ресурсов тратит, чем AutoLayout и соответственно меньше тормозов. Когда вы выбираете что то отличное от MVC то на UIKit это выглядит костыльно, а здесь полная свобода и Combine помогает вам с реактивщиной даже. Если вам хочется крутых кастомизаций, то помогают backports, но чем дальше вы от iOS 13, тем их меньше будет.
Спасибо за ссылка, интересно всегда мнение со стороны узнать.
Распространение языков очень интересное, если смотреть ту же статистику сравнения Dart и Kotlin по странам, то создается впечатление что у KMM и Flutter не только разные цели но и разный контингент.
Мне понравилась мысль в статье: это повысить Федю. Неохотно так звучит ещё: не ну давайте его на конференции отправим, давайте его займем менторством, ну можно из тестировщиков в аналитики. А автор не думал, что Феде лучше его место занять?
Не дефиктивного. А менеджеров по русской модели управления: уровниловка и круговая порука. Централизация власти (в своем лице) и прераспределение ресурсов (бесконечная ротация). Иначе если не делать это то в душе русской такая пустота будет, что разрушит на своем пути всякое устройство (процессы поломает, ага). Никакой конкуренции, пусть перформер сходит борщь поварит
Вот Вы ясно видите какую проблему решали? Расскажите, я из статьи не понял.
Вы написали что не просто хуизху надо знать, вы еще наисали что надо думать об их развитии, а если все это объединить, то мы получаем мотивацию. Надо знать мотивацию каждого и использовать ее для развития бизнеса, а не людей. Развитие людей это инструмент не только их роста, но и выгарания, и тут как бы автор его навязывает, ага, не удивлен что 40% уволилось.
У меня одного ощущение что в статье какая-то невнятная проблема решается путем составления направленного графа следсвенно-причинных пунктов и вершин разрешений, который сходится к стоку: "Погасить перформера"?
Автор, а вы проверяли свой граф на цикличность? Кажется вы упомянули, что стать незаменимым управленцем "мы теперь знаем к чему ведет". Но почему то у меня ощущение того, что Вы занимались микроменеджментом и не только в каком то частном случае, но ей богу ворошить так команду и Федю это надо прям усидчивость и терпение иметь.
Первое правило решения проблем: а есть ли проблема? Тоже самое первое правило гласит, а в чем же проблема? Точно в Феде? А точно в команде? 60 багов то не из-за Феди как оказалось, а не из-за того что ошибки не искали по ходу решения, то есть в процессах.
Ну предположим, что автор не все проблемы опубликовал, и проблемы очень много и они действительно в Феде и в команде, тогда второе правило гласит: а давайте соберем всех лиц, кто причастен к этой проблеме и спросим как решить эту проблему у них, определим ответственного, сроки и критерий приемки результата. Было? Я вижу из статьи, что вместо этого, могучий управленец начал назначать ответсвенных, ротировать всю команду (перформатировать ответственность) и бедного Федю ставить под увольнение.
Единственная здравая мысль в статье, это повысить Федю, причем так неохотно написано: не ну давайте его на конференции отправим, на обучения, давайте его займем менторством, ну можно аналитиком. А автор не думал что Феде лучше его место занять?
Федя и сам бы рад уже уволится, но кто то же должен всю работу делать
Вы его уволили?
фейсайди, пушнотификации, фоновые вычисления, кеширование состояния приложения это неполный список фич нашего ПВЗ и даже свистелка есть, в общем не так легко затащить через Web. А так согласен, для приложения аля стартап бери и пиши на чем хочешь
Проблема xib и storyboard еще в том что
1. системе их надо парсить, держать в памяти - время и ресурсы
2. связь с кодом (вызов событий или переходов на экраны) не гарантирует отсутствия эксепшенов и ошибок, чето переименовали - перестало просто работать, отсутствуют проверки на этапе компиляции короче
Теорию могут заучить почти все. Применять эту теорию на практике могут немногие.а как вы это делаете? Я не совсем понял.
Вот есть вроде намек на "дополнительные вопросы", но вы сказали что они задаются "если ответ не нравится", значит у вас какие то ожидания от кандидата есть, технические, что если например вы ждете от кандидата, что он вам расскажет про барьеры в очередях, а он знает лучшее решение в организации цепочек запросов в сеть с помощью Promise? Вроде дичь, вот уже Combine есть, но в конкретной задаче Combine хуже справится, и как оценить тогда такой ответ?
Еще есть кейс, что после одного из ваши собесов сольют в сеть "правильные ответы" и будут появляться кандидаты, которым не нужно вообще задавать вопросов, потому что они чешут от зубка, как опытные синьеры. Как с этим боритесь?
Вы очень крутую вещь подсказали в статье: "иногда я меняю условия" вот это реально помогает определить софты, а вот про отсев нежелательных личностей, можете пояснить? Как он происходит? Как вы определяете не подходящего для вашей команды человека?
Спасибо большое за дополнение. Но получается, что
#Previewтеперь уже точно не компилируется? Потому что до SDK iOS 17 все попадало в билд и уже вычищалось во время архивации, соответственно нам пришлось обрамлять своими макросами такие превью, так как их компиляция могла задействовать моки, которые складываются в некомпилируемые пакеты и соответственно на CI возникала ошибка компиляции, теперь этого можно избежать с помощью такого макроса?Мне статья помогла понять, как кастомизировать данные для переходов на экраны. Спасибо.
Так же я сделал форк, чтобы продемонстрировать передачу параметров на экраны (это важный момент) и кроме того добавил диплинки, потому как использовать координатор имеет смысл именно совместно с диплинками, ссылка ниже на форк
https://github.com/sofbix/NaviTest
Вы правы, так спасти жизни можно, фича действительно моргинальная, не сколь своим явлением, сколь реализацией. Если залезть под капот SDK Localise, то там обнаруживается Swizzling, работа с Notification Center, обязывание разработчиков обновлять текстовые сообщения в специальном методе. Хочется такой SDK не использовать.
Руковожу в общей сложности с 2013, когда твой отдел достигает 25 людей, то ваще не до признания, и честно говоря, не помню чтобы возникало желание засветиться еще до внедрения, после внедрения и получения профита было дело, хочется делиться своими наработками, скоро про это напишу, кстати. Если бы следующее предложение прочитали после первого, то получили внятный ответ о моем участии в выборе стеков, так то надо мной руководитель тоже есть.
Все впорядке, дружище. Мы выпустили нативку в сентябре, рейтинг приложения с тех пор вырос, пользователи стали более довольны, акции растут. Правильный выбор сделали, главное что результат есть
Вы видимо не часто пишите движки рендеринга на эпловские продукты, раз не видите проблем в рендеринге для такой компании как Google. Может тогда Google в легкую напишет альтернативу iOS? И Apple с этим ничего не будет делать?
Зачем увеличивать штат еще больше у нас полно нативщиков так то, зачем вкладывать в технологии, которые не привели команду к успеху?, чтобы что? Я просто не понимаю, вам нравится Дарт и вы хотите чтоб Озон тоже на Дарте писал? Ну да, у нас зрелая компания которая мониторит рынок, смотрит скорость разработки продукта и знает во что вкладывать, а во что нет. Наш выбор вам кажется необоснованным, наверное у вас другая компания аля стартапа (я писал об этом), полно разработчиков Flutter, которые лезут в форточку готовы получать меньше нативщиков и задачи не требуют написания кучи плагинов и потом их еще поддерживать, нативный мир то тоже не стоит на месте
В SwiftUI встречается множество косяков, но в целом он намного приятнее для разработки и ревью кода, есть даже подозрение что верстка начиная на нем с iOS 14 меньше ресурсов тратит, чем AutoLayout и соответственно меньше тормозов. Когда вы выбираете что то отличное от MVC то на UIKit это выглядит костыльно, а здесь полная свобода и Combine помогает вам с реактивщиной даже. Если вам хочется крутых кастомизаций, то помогают backports, но чем дальше вы от iOS 13, тем их меньше будет.
Спасибо за ссылка, интересно всегда мнение со стороны узнать.
Распространение языков очень интересное, если смотреть ту же статистику сравнения Dart и Kotlin по странам, то создается впечатление что у KMM и Flutter не только разные цели но и разный контингент.
Согласен, надо исправиться. Я прокоментирую, когда Update накачу.