Можно немного конкретики? Где именно разница между запятой и cross join? Я не смог найти.
Про групповые и итерационные - пример был бы супер, так не оч понятно. Ну т.е я согласен, что бнздумно ничего делать нельзя, но если есть какой то кейс, который прям точно может всплыть, то хотелось бы увидеть
Не, ну многие уже 100% кода пишут агентом. И программирование ускорилось раза в 2..Но при этом приходится тщательно проверять высеры агентов, иначе глючки, оверинжениринг и недопонятые задачи нарастают как снежный ком.
Я согласен. Если кто-то напишет микросервис на языке BrainFuck, то потом будет тяжело. Но это крайний случай. Я говорю про другое, когда пытаются делать из людей дешевые винтики, или просто у директораа есть какой-то бзик. Типа, пишем только на такой-то версии, используем только библиотеки из списка и т.д. И тогда мы Васю за один день заменим на Петю из соседнего отдела. Но у этого подхода есть психологическая цена.
Например, я слышал, что в Skyeng всё писали на php, потому что так решил их тех дир. При этом писали статьи, как они ловко выкручиваются и наворачивают на пхп сложные системы, чтобы выжить. Вместо того, чтобы добавить немного Go в многопоточных местах. Я точно не знаю, но предполагаю, что команда с этого знатно выгорала.
Я сталкивался с подобными ситуациями, когда навязывался фреймворк или, наоборот, писать вообще без фреймворка. Хотя вся команда не понимала, почему, и погдорала с этого.
Я пришел к выводу, что надо давать максимум свободы, если нет прям явных противопоказаний. Понятно, что зависит от конкретной ситуации
насчет спринтов и демо. Моя команда больше половины времени занималась поддержкой уже созданных микросервисов. Никому наше демо было не нужно (заказчики изменений были в курсе всего или вообще даже тестировали их вместе с нами), да и показать это на демо было не просто. Типа добавили в апи какую-то очередную хрень, а в кафку плюём другую очередную хрень.
Спринты были не нужны, потому что иногда задачи по размеру не подходили: например, одна важная задача влезает, а две - уже нет. И стоял выбор: либо вместо второй важной набить спринт какой-то хренью или же оформить перенос недоделанной задачи между спринтами или делать искусственное разделение задачи. Зачем этот гемор?
Всё это ради совершенно искусственно высосанной из пальца концепции скрама. Не нужны нам были ни роли , ни ритуалы, у нас и без скрама всё было норм, клянусь. Я был тимлидом маленькой сработанной команды, всё происходящее видел и контролировал, команда работала хорошо. ПРосто сверху назначили скрам. Стало чуть хуже.
На ритуалы эти ваши уходил целый день суммарно. Это просто бред. планирование+ демо+ретро+груминг
У Скрама одна большая проблема - это слишком жесткий фреймворк. Т.е. чтобы это называлось скрамом, нужно чтобы было планирование на спринт, демо, ретро и т.д. Даже если команде нахер всё это не нужно, если задачи проще разбить по-другому (а не по спринтам), а демо показывать никому не нужно, всё равно, блин, найдется начальник который всех будет нагибать и требовать, чтобы было именно с разбивкой по спринтам, к концу спринта всех подгонять палкой, потом устроит никому не нужное демо, а на ретро тоже обычно цирк еще тот.
Особенно, конечно, смешны сторипоинты. Это какая-то эфемерная величина, которую никто толком не понимает. Это не время, но при этом сторипоинты надо упаковать в две недели. Я уж молчу о том, что сроки обычно предсказываются от балды, потому что никому они не известны никогда. А потом еще кто-то особо умный построит график сторипоинтов и будет сравнивать эффективность команд на основании этой абсолютно высосанной из пальца метрики.
Я считаю, что Скрам не нужен вообще. Лучше просто перестраивать процессы под свои нужды, используя разные инструменты, исходя из реальности и потребностей. Канбан в этом смысле намного лучше - это просто набор инструментов, он ничего не навязывает.
Ну так да, от уровня зависит. Программист может повлиять на один уровень выше, но всё равно не будет делать полную проработку бизнес требований и согласований. А уж если речь про два уровня выше - там совсем труба
В небольших стартапах а ля 2 pizza team да, все влияют на всё, я согласен. Это нормально и хорошо
Я в целом согласен с посылом, что для многих задач хватает мидл знаний.
Но вот с эти не оч согласен: "любой проходимец может легко влететь в айтишку, остаться в ней и успешно перформит"
Я знаю многих людей, адекватных и работящих, которые не осилили войти в айти, еще на этапе обучения. Не потому что тупые, а просто "это не моё". Нужен определенный склад ума, чтобы сидеть весь день за компом и решать шарады, пусть даже и не супер сложные.
Слышал, как какой-то чел взялся бесплатно учить народ программированию. Из 30 чел доучилось только 4, остальные сбежали.
а, понял, спасибо!
Я бы вообще не стал смешивать синтаксис с запятой и JOIN в одном запросе, это превращает код в ребус
Можно немного конкретики? Где именно разница между запятой и cross join? Я не смог найти.
Про групповые и итерационные - пример был бы супер, так не оч понятно. Ну т.е я согласен, что бнздумно ничего делать нельзя, но если есть какой то кейс, который прям точно может всплыть, то хотелось бы увидеть
О, борцун за систему с нулевого аккаунта
Я бы с "макс" на одном поле ср.. не стал
Не, ну многие уже 100% кода пишут агентом. И программирование ускорилось раза в 2..Но при этом приходится тщательно проверять высеры агентов, иначе глючки, оверинжениринг и недопонятые задачи нарастают как снежный ком.
Я согласен. Если кто-то напишет микросервис на языке BrainFuck, то потом будет тяжело. Но это крайний случай. Я говорю про другое, когда пытаются делать из людей дешевые винтики, или просто у директораа есть какой-то бзик. Типа, пишем только на такой-то версии, используем только библиотеки из списка и т.д. И тогда мы Васю за один день заменим на Петю из соседнего отдела. Но у этого подхода есть психологическая цена.
Например, я слышал, что в Skyeng всё писали на php, потому что так решил их тех дир. При этом писали статьи, как они ловко выкручиваются и наворачивают на пхп сложные системы, чтобы выжить. Вместо того, чтобы добавить немного Go в многопоточных местах. Я точно не знаю, но предполагаю, что команда с этого знатно выгорала.
Я сталкивался с подобными ситуациями, когда навязывался фреймворк или, наоборот, писать вообще без фреймворка. Хотя вся команда не понимала, почему, и погдорала с этого.
Я пришел к выводу, что надо давать максимум свободы, если нет прям явных противопоказаний. Понятно, что зависит от конкретной ситуации
насчет спринтов и демо. Моя команда больше половины времени занималась поддержкой уже созданных микросервисов. Никому наше демо было не нужно (заказчики изменений были в курсе всего или вообще даже тестировали их вместе с нами), да и показать это на демо было не просто. Типа добавили в апи какую-то очередную хрень, а в кафку плюём другую очередную хрень.
Спринты были не нужны, потому что иногда задачи по размеру не подходили: например, одна важная задача влезает, а две - уже нет. И стоял выбор: либо вместо второй важной набить спринт какой-то хренью или же оформить перенос недоделанной задачи между спринтами или делать искусственное разделение задачи. Зачем этот гемор?
Всё это ради совершенно искусственно высосанной из пальца концепции скрама. Не нужны нам были ни роли , ни ритуалы, у нас и без скрама всё было норм, клянусь. Я был тимлидом маленькой сработанной команды, всё происходящее видел и контролировал, команда работала хорошо. ПРосто сверху назначили скрам. Стало чуть хуже.
На ритуалы эти ваши уходил целый день суммарно. Это просто бред. планирование+ демо+ретро+груминг
Возможно, стоит поговорить с людьми, что именно они считают несправедливым. Сложно сказать издалека
У Скрама одна большая проблема - это слишком жесткий фреймворк. Т.е. чтобы это называлось скрамом, нужно чтобы было планирование на спринт, демо, ретро и т.д. Даже если команде нахер всё это не нужно, если задачи проще разбить по-другому (а не по спринтам), а демо показывать никому не нужно, всё равно, блин, найдется начальник который всех будет нагибать и требовать, чтобы было именно с разбивкой по спринтам, к концу спринта всех подгонять палкой, потом устроит никому не нужное демо, а на ретро тоже обычно цирк еще тот.
Особенно, конечно, смешны сторипоинты. Это какая-то эфемерная величина, которую никто толком не понимает. Это не время, но при этом сторипоинты надо упаковать в две недели. Я уж молчу о том, что сроки обычно предсказываются от балды, потому что никому они не известны никогда. А потом еще кто-то особо умный построит график сторипоинтов и будет сравнивать эффективность команд на основании этой абсолютно высосанной из пальца метрики.
Я считаю, что Скрам не нужен вообще. Лучше просто перестраивать процессы под свои нужды, используя разные инструменты, исходя из реальности и потребностей. Канбан в этом смысле намного лучше - это просто набор инструментов, он ничего не навязывает.
всё верно, но 1С в 2001 году был вовсю
Ну так да, от уровня зависит. Программист может повлиять на один уровень выше, но всё равно не будет делать полную проработку бизнес требований и согласований. А уж если речь про два уровня выше - там совсем труба
В небольших стартапах а ля 2 pizza team да, все влияют на всё, я согласен. Это нормально и хорошо
Т.е. по вашему, цель и решения, приводящие к цели, - это одно и то же? Я не понял суть вашего наезда
Просто надо проверять результат на каждом этапе и просить подправить.
а что с ней не так? )
рейтинг TIOBE - это бред собачий. Кто еще на него ориентируется?
поправлю про drop expression
тоже удивился. Ведь по выраженияем в pg можно индексы делать, почему по выражениям, описанным в колонке нельзя. Видимо просто не допилили пока что.
я не знаю, возможно некоторые вычисления могут зависеть от каких-то факторов (локаль, например), и данные разъедутся. Х.з, инфы пока что очень мало
Это на какую позицию?
Я в целом согласен с посылом, что для многих задач хватает мидл знаний.
Но вот с эти не оч согласен: "любой проходимец может легко влететь в айтишку, остаться в ней и успешно перформит"
Я знаю многих людей, адекватных и работящих, которые не осилили войти в айти, еще на этапе обучения. Не потому что тупые, а просто "это не моё". Нужен определенный склад ума, чтобы сидеть весь день за компом и решать шарады, пусть даже и не супер сложные.
Слышал, как какой-то чел взялся бесплатно учить народ программированию. Из 30 чел доучилось только 4, остальные сбежали.