да тут наверно вы правы - крутясь внутри финтеха в одних и тех же задачах много лет возникает иллюзия что выгоднее разработчику иметь бизнес навыки на высоком уровне. тем более что заказчик этжом ниже и если коммуникация налажена то все прекрасно. а если заказчик в другом городе или доступен только по конференциям - ну автор про это наверно и не знает. короче специфика
основаная тема материала - все делают все. если ты будешь общаться с бизнесом, то ты уже не будешь разрабатывать - будешь все болшье и больше тратить время на совещания и меньше на разработку. то есть из разработчика превратишься в менеджера - легко деквалифицироватся.
и тем не менее как правильно сказать невозможно - неясно что такое правильно. анекдот "быстро качественно и дешево" это не анекдот. у автора есть пример быстро и качественно? правда в чем качество ( критерий) и быстрота - это какой срок? что дочно можно сказать - бизнес задача реализована или нет. как реализована - оценить можно
кто может позволить себе прототипирование с учетом требований для инвалидов? какой их процент? приложение для заказа еды - ориентировано на массовость - иначе прибыли не будет. кто будет адаптацию под инвалидов
в примере со списком надо было переставить sublist(0,1) на sublist(0,3) - как я понял списко меняли в одном месте. если была бы ситуация, когда у вас были два списка с длиной один и три, то тут надо поставить заметку "если будет еще такой список то тут уже пора делать параметризованный список". читат я где то то ли методика то ли подход - на такие вещи реагируем только по третьему преценденту
так код фронтед должен быть минифицирован. иначе свою зарплату сотрудники получают зря
да тут наверно вы правы - крутясь внутри финтеха в одних и тех же задачах много лет возникает иллюзия что выгоднее разработчику иметь бизнес навыки на высоком уровне.
тем более что заказчик этжом ниже и если коммуникация налажена то все прекрасно.
а если заказчик в другом городе или доступен только по конференциям - ну автор про это наверно и не знает.
короче специфика
основаная тема материала - все делают все.
если ты будешь общаться с бизнесом, то ты уже не будешь разрабатывать - будешь все болшье и больше тратить время на совещания и меньше на разработку.
то есть из разработчика превратишься в менеджера - легко деквалифицироватся.
и тем не менее как правильно сказать невозможно - неясно что такое правильно.
анекдот "быстро качественно и дешево" это не анекдот. у автора есть пример быстро и качественно?
правда в чем качество ( критерий) и быстрота - это какой срок?
что дочно можно сказать - бизнес задача реализована или нет. как реализована - оценить можно
ну ну - то то американцев все на улицу выставлять принялись
кто может позволить себе прототипирование с учетом требований для инвалидов?
какой их процент?
приложение для заказа еды - ориентировано на массовость - иначе прибыли не будет. кто будет адаптацию под инвалидов
я тут мощно задумался - полиморфизм и наследование - в чем разница друг от друга ?
в примере со списком надо было переставить sublist(0,1) на sublist(0,3) - как я понял списко меняли в одном месте. если была бы ситуация, когда у вас были два списка с длиной один и три, то тут надо поставить заметку "если будет еще такой список то тут уже пора делать параметризованный список".
читат я где то то ли методика то ли подход - на такие вещи реагируем только по третьему преценденту