Pull to refresh
10
0
Muhamad Zununov@VanquisherWinbringer

CIO

Send message
Sub but true. Сваливать надо пока нас программистов похожая на это фигня не заденет.
Карго культ в всей красоте. Соблюдают сам ритуал забывая зачем он вообще нужен и почему он так делается.
Митапы разговорные с нативами бесплатными на meetup.com друг в Мск в Парке Горького ходил. Вроде он говорил что норм.
У меня знакомая платила чуваку который живет в Штатах за то что он с ней просто разговаривал по скайпу на английском. Забыл как эта услуга называется. Она мне даже контакты фирмы давала которая эту услугу предоставляет. К сожалению я по рассеяности и контакты фирмы и контакты самой тети растерял. Погугли, в общем есть такая хрень что с тобой просто чувак который там живет и не знает русского будет по часу в день на какую-то тему расспрашивать и слушать.
Хех, особенно доставляет как вспомню плачи ребят из России, Новосибирска (там на минуточку девушек от возрастом 18 до 30 лет процентов на 12 больше чем парней того же возраста чисто статистически) о том что девушки совсем нос воротят, их вообще свободных нет (на самом деле да, у многих мужчин жена и любовница имеется) и все такое. Да как бе любому думающему человек и так очевидно что Омежки по всей планете девушкам одинаково не нужны и их одинаково не любят. Странно вообще в этом плане выделят калифорнию. Даже в в том же Новосибирске из-за того что девушек много просто у нормальных парней их несколько. Жена и любовница. Просто несколько любовниц и все.
Хм, мне был NY после Мск по интересней в плане переезда как такой же мегаполис только вот таких вот хороших статей про NY маловатенько.
Это одна из главных проблем со скрамом и ошибок управленцев — думать что скрам даст предсказуемость сроков. Он даете скорость обратной связи. Тобишь скрам не про «Мы сделаем это за 2 недели и точно сделаем». Начнем с того что в принцыпе в любой методологии неправильные сроки это обычное дело. Скрам про то что вместо «Мы думали что сделаем за год а сделали за 4» — «Мы думали что сделаем за 1 неделю а сделали за 4 недели»
Фильм «Цельнометалическая Оболочка» смотрели? Суть как там. За все всегда всю команду наказывают. Не успели что-то сделать. Всей команде срезали премию. На проде что-то легло. Всей команде выговор. Ну и увольнять всю команду разом. Внутри команда сама разберется кто есть кто. Понятно дело что если вся команда проголосовала что кого-то хочет исключит из своих рядом то его надо для начала перевести в другую команда и если он и там уже не приживется то в целом отпускать на свободу.
Если коллектив токсичен, уровень менеджмента примерно соответствует «я начальник — ты дурак, делай как сказали», исполнители читают требования после того, как закрывают задачи, никто не умеет собирать и описывать эти самые требования, то смысла от этой сложной системы никакого. Проще и быстрее работать так, как коллектив работал до этого.

Можно было вместо такого длинного текста сказать кратко — Скрам предназначен для организации работы самомотивированой команды. Где-то смотрел статистику что в принцые самомотивированных и саморганизованных людей процентов 15 от всех программистов а команд где из 5 программистов 5 самомотивированные еще меньше. Для всех остальных есть схема ТимЛид и его подчиненные. Тимлид принимает все решения и поэтому за все несет ответственность. Назначает задачи своим подчиненным и принимает от них результат выполнения. Все.
Тут вспомнил картинку из постера к сериалу «Давай еще, Тед» где они всей командой одновременно жмут красную кнопку.
Да вы прикольный. Со временем рейтинг повысится. Не переживайте. :)
Вы не поняли о чем спор вообще. Расширяемый код не самоценность, где-то расширяемость нужна, где-то вредна.

Да и к тому же расширяемый код сложнее и его дольше писать.
Например можно сделать метод User Get(int id) и если понадобиться получать несколько пользователей то придется писать новый метод или в цикле вызывать этот а можно сделать List Get(List ids) который будет работать и с 1 айди и когда кому-то надо будет получить коллекцию не надо будет писать новый код. Метод универсален. Ток написать его будет чуть сложнее. Можно сделать просто int Add(int a, int b) а можно сделать T Add(T a, T b) второй вариант будет более универсальным и расширяемым ток будет сложнее и его дольше делать. Можно сделать просто JsonSerialazer.Serialize(User) а можно ISerializer.Serialize(User) второй вариант будет универсальнее. Его проще расширить но дольше писать и код там будет сложнее. В общем расширяемость это всегда повышение сложности кода и времени его разработки. Иногда проще и выгодней сделать код быстро переписываемым чем расширяемым.

А думать правилами — вообще плохой тон. Правила скорее для людей у которых еще нет опыта

Ага, правила дорожного движения соблюдают только не опытные водители. Вы странный.
Вас в детстве часто головой вниз роняли или просто часто били по голове?
Это у вас будет потому что судя по вашему комментарию вы не умеете работать с коллекциями как с потоками данных. Я умею поэтому у меня не будет.
Ну посмотрим что будет осенью.
Забыл про генерики. Хотя про генерики и так всем очевидно что код на них расширяемый по дефолту.
Дорогой брат, а откуда ты вообще в курсе моих финансовых возможностей? Не помню, чтобы я в открытом доступе их выкладывал.

Ты в телеге говорил.
Я тебе ссылки скинул где посмотреть в долларах в США. В Европе Швейцария разве что. Да и вообще, ты в хочешь встречать пенсию в России? Чем раньше уедешь тем лучше потом будет у тебя пенсия там.
БТВ, с опытом сформировал 2 правила расширяемого кода
1) Используй Интерфейсы вместо реальных объектов везде где это в принципе возможно
2) Используй Коллекции вместо единичного объекта везде где это возможно
Вооще сатат по ЗП за 2019 год в среднем по США вот www.levels.fyi/2019
Судя по ней разраб Нью-Йорке получает в среднем $190к в год грязными (Основная + акции + премии)

Information

Rating
Does not participate
Location
Россия
Registered
Activity

Specialization

Технический директор, Директор по информационным технологиям
C#
Разработка программного обеспечения
Управление проектами
Управление продуктами
Управление разработкой
Agile
Scrum
Kanban
Разработка ТЗ
Scala