-
Сообщений
6 899 -
Зарегистрирован
-
Посещение
-
Время онлайн
120д 7ч 30м 10с
Все публикации пользователя Drakonian
-
куколдизм + омежность просто приведет к тому что такие случаи будут учащатся с обеих сторон, напряжение между людьми будет усиливываться, итог понятен просто куколдизм ================= По факту лучшим решением будет спокойный открытый разговор с просьбой чтобы такие ситуации не возникали в будущем. Потом два ответления возможны: а) ситуации продолжают возникать, значит с этой дамой вам не по пути б) ситуации перестали возникать, значит не все так плохо ================= в контексте конкретного случая дримухи не релевентано, так как это просто была девушка на 1 ночь, там пох в принципе
-
я про то и думаю. я просто не понял какая у тебя частота. одно дело "1 раз на час в начале созвониться" на таску недельную и другое на месячную - частота в 4 раза отличается. ты сколько имел ввиду? Хорошо, давай подробнее на примерах Вот есть у меня таска на неделю, обычно она не така уж и сложная раз там работы на неделю. Таск расписан что и как, домен мне знакомый. Сколько нужно митингов? От 0 до 2. Бывает что по таску все понятно, всю работу сделал и запушил в репозиторий с авто тестами и иногда с документацией, CICD запушил на тестовый сервак, кто-то допольнительно протестировал. Если все ок, то релиз на прод опять же обычно без моего участия. Реже нужно 2 митинга, в начале чтобы уточнить все непонятные моменты и в конце чтобы демо сделать к примеру. (больше в ОЧЕНЬ редких случаях) По сути это количество можно для любого размера задачи экстраполировать, в среднем так и получается 0-2 митинга в неделю. Просто в случае задач на 1-2-3-6 месяцев обычно митинги могут возникать чаще в начале задачи и в её конце (совместное тестирование, обсуждение, демо, етц). Итого у меня в неделю 0-3 митинга в среднем за неделю, обычно третий допольнительный может быть просто сапортом кому-то или в случае большей задачи на начале-конце её. И для меня это количество приемлимо. Я готов уделить где-то 1-2 часа в неделю на встречи (с учетом малого количества встреч!!!) =============== Я работал в компании где были дейлики в 9 утра почти каждый день, плюс доп. митинги по ходу дня. Сначала кажется ну что тут такого, но я настолько заебался за год что решил что больше никогда на такую хуйню не подпишусь. Причем часто проблема даже не в продолжительности митингов, а в их количестве. Это выбивает из колеи.
-
а как бы не сильно растет частота митингов от времени создания фичи, митинги во времени размазываются в любом случае хоть 1 недельная, хоть 6 месячная послушаю о проблеме, а потом просто код почитаю, сделаю дамп БД в тест sandbox, продебажу очень редко когда появляется необходимость созваниватся или поднимать документацию прям детальную из-за таких проблем но если митинг и нужен то как бы таких ситуаций не так много )
-
а как работать? ну типа там настолько отсутствует неопределенность что прокто кодируешь хуйню по тз как ебаный робот? или как?? у меня следующие рассуждения если ты не джун/мидл и делаешь что-то более менее сложное - нужен контекст по продукту, нужно принятие решений в условиях неопределенности и недостатка информации. такое в одного не делается. в целом даже выбрать чисто техническое решение (кафку хуяфку, апи вс очередь, либу, паттерн и тп) лучше посоветоваться с другими опытными товарищами (только если у вас не все супер зарегулировано и таких вопросов не стоит). тоесть коммуникация нужна в любом случае. можно делать очень многое асинхронно. но какие-то вещи проще обсудить в диалоге тк нужен короткий цикл обратной связи (когда у тебя много вопросов и нужно быстро вась-вась выйти на общее понимание). а какие-то чтобы асинхронно обсуждать нужно предварительно быть очень быть на одной волне с другими людьми, что в свою очередь обычно достигается тоже в основном в диалоге (митинге). плюс всякие 1-1, демо, ретро. если делаются со смыслом а не тупой калькой из книги по скраму, то это тоже супер профитные активности, которые необходимы для высокопроизводительных команд которые делают что-то интересное/полезное как без митингов можно? ну смотри Норм ТЗ действительно уменьшает количество необходимым комуникаций, но конечно же полностью не избавляет от них Кроме того размер компании прямо влияет на количество митингов, чем больше компания, тем больше бюрократии, тем больше людей, что в свою очередь сильно увеличивает количество необходимым комуникаций Моя стратегия была соответственно этим рассуждением, МАЛЕНЬКАЯ компания с норм ЗП, чем меньше тем лучше, синьйорный уровень работников (нету джунов-мидлов). Вуаля, митингов почти не будет. У меня нет дейликов, нет еженедельных митингов, у меня есть только митинг когда что-то нужно уточнить (редко), часто это митингы на 15 минут где-то раз в неделю или что такого Показать больше проблема в том, что я и есть тот чел, который пишет тз потом ну кто-то же должен ))
-
Все так, код на тестовом сервере и код на проде это совсем разные субстанции Качественный рост разработчика сильно связан с тем чтобы код попадал на прод и разраб мог в этом сам убедится и прохавать все проблемы реального прода здесь есть ошибка условия заказчик не может диктовать из-за отсутствия технического понимания проблемы, все что заказчик диктует это сроки и бюджет, а ты уже от этого отталкиваешься заказчиком обычно выступает другая ИТ компания, у которой есть свои тех.спецы - которые выставляют сроки. это если мы говорим про большие компании, то возможно у меня например заказчик это непосредственно бизнес, поэтому такой проблемы нет
-
здесь есть ошибка условия заказчик не может диктовать из-за отсутствия технического понимания проблемы, все что заказчик диктует это сроки и бюджет, а ты уже от этого отталкиваешься
-
совсем не так, маленькая компания синьйорного лвла это значит что будут и тесты и документация в стартапе возможно, не работал в них если компания не большая то такие проекты обычно не супер огромные кроме того из-за уровня команды у тебя есть намного больше свободы в решениях относительно дизайна и архитектуры, ты сам решаешь как это сделать и тебе доверяют А мне не нужно каждую микро деталь расписывать, нужно просто немного разбираться в бизнес процессах (на опыте), ты зачастую сам решаешь как лучше это реализовать, все что мне нужно знать это какую проблему бизнеса мы пытаемся решить и о чем бизнес. Это буквально час разговора в начале проекта и ИНОГДА редкие синк апы с бизнесом или консультантами внутренними ну вот, даже с огромной командой может быть минимум митингов но я бы и час в день не хотел бы))
-
ну я еще не тренированный и не сениор тяжело а ну тогда не ссы, прорвешься, нужно время просто и старания
-
сколько у тебя парт-тайм проектов кроме фулл тайма? если меньше 3 то все ок
-
а как работать? ну типа там настолько отсутствует неопределенность что прокто кодируешь хуйню по тз как ебаный робот? или как?? у меня следующие рассуждения если ты не джун/мидл и делаешь что-то более менее сложное - нужен контекст по продукту, нужно принятие решений в условиях неопределенности и недостатка информации. такое в одного не делается. в целом даже выбрать чисто техническое решение (кафку хуяфку, апи вс очередь, либу, паттерн и тп) лучше посоветоваться с другими опытными товарищами (только если у вас не все супер зарегулировано и таких вопросов не стоит). тоесть коммуникация нужна в любом случае. можно делать очень многое асинхронно. но какие-то вещи проще обсудить в диалоге тк нужен короткий цикл обратной связи (когда у тебя много вопросов и нужно быстро вась-вась выйти на общее понимание). а какие-то чтобы асинхронно обсуждать нужно предварительно быть очень быть на одной волне с другими людьми, что в свою очередь обычно достигается тоже в основном в диалоге (митинге). плюс всякие 1-1, демо, ретро. если делаются со смыслом а не тупой калькой из книги по скраму, то это тоже супер профитные активности, которые необходимы для высокопроизводительных команд которые делают что-то интересное/полезное как без митингов можно? ну смотри Норм ТЗ действительно уменьшает количество необходимым комуникаций, но конечно же полностью не избавляет от них Кроме того размер компании прямо влияет на количество митингов, чем больше компания, тем больше бюрократии, тем больше людей, что в свою очередь сильно увеличивает количество необходимым комуникаций Моя стратегия была соответственно этим рассуждением, МАЛЕНЬКАЯ компания с норм ЗП, чем меньше тем лучше, синьйорный уровень работников (нету джунов-мидлов). Вуаля, митингов почти не будет. У меня нет дейликов, нет еженедельных митингов, у меня есть только митинг когда что-то нужно уточнить (редко), часто это митингы на 15 минут где-то раз в неделю или что такого
-
можно найти компанию без митингов я по крайней мере нашел в итоге А когда работал в конторе Нидерландской то ахуел из-за количества митингов и утренних стендапов, сука в 9 утра стенд-ап это пиздец был я там год продержался
-
сегодня клауд не закрыл вместо меня тикет потому что я весь день нихуя не делал так я тоже нихуя не делал )
-
сегодня claude закрыл вместо меня тикет
-
прогонял прогоняю и буду прогонять
-
пусть сначала поймают
-
я на питоне пишу, бро да кто этот ваш грок такой? в смысле, а как же Java?
-
могу залить тонны говна на прод без ллм ллм не нужон так быстро фуру говна которая комплится и даже на первый взгляд работает ты не сделаешь
-
пиздец вы деды LLM уже генерит тоны говнокода который можно на изи сквозь ревью в прод залить если захотеть а у вас ниче он не делает))
-
нихуя инсайды мойка чистая хотя бы?
-
Ну, синтаксис же знать надо. А там понятно, что дальше библиотеки связывать. Да не, я бы тоже офк за жпт сел в первую очередь. Но тут 2 момента: совет дается динозавру; речь о какой-то мелкой либе с ебанатским названием, из-за чего могут быть галюны Вот как-то так. Понятно что я задал ебанатский промт, но тем не менее. Показать больше o3 вот что первым шагом размышлений выдал А дипсик чо расскажет? отсосет, он ущербный
-
чатгпт все сделает за тебя this
-
Не хочу. Ладно, завтра ищешь в интернете книжку Dive into python. Пофиг если ничего не поймешь. Затем идешь на python.org и изучаешь стандартную библиотеку от корки до корки. Потом зубришь, именно, сука, вызубриваешь конвенцию по написанию питоньего кода - PEP8, чтобы от зубов отскакивало. Когда напишешь свою первую имиджборду, по пути изучив верстку на html+css, скачиваешь и изучаешь любой питоний асинхронный вебсервер, рекомендую Tornado или Gevent. Как переделаешь имиджборду, чтобы выдавала по крайней мере 5 тысяч запросов в секунду, можешь идти дальше - тебя ждет увлекательный мир хайлоада. Apache Hadoop, сверхбыстрые асинхронные key-value хранилища, MapReduce. Отсос хиккующих выблѣдков / просто неудачников типа рейфага или сисярп/джава-удососов, которые сосут уд по жизни не заставит себя ждать и уже через пол года ты будешь получать такие суммы, что любая баба будет течь при одном упоминании твоей зарплаты.
-
где же еще бабки просить как не на ПД звучит логично
-
в этой сети баб не будет