Спасибо за точку зрения! Да, такое бывает и в таких местах тоже приходилось работать. Текущее место работы я и выбрал по причине того, что тут во главе угла здравый смысл.
> закрываются проекты из-за перерасхода бюджета на прирания на совещания
Компания продолжает рост даже в текущих непростых условиях на рынке РФ, можно ли сделать вывод, что перерасхода не случается и открытый подход работает?
Отдельно скажу, что получаю мега-кайф от общего канала с архитекторами всех команд, где можно жестко зарубиться за какую-нибудь серьезную продуктовую фичу и в итоге получить не только новый ценный опыт, но лучшее, выверенное решение. Первый раз такое встретил именно в майндбоксе.
Тривиальные и очевидные задачи проезжают без каких-либо вопросов. Да, бывают ситуации, когда сеньор без знаний домена предлагает не самые лучшие решения и ему об этом открыто говорят более осведомленные в проблематике ребята, которые не обязательно должны быть равного или выше грейда. И все обсуждается на здравом смысле, так как у всех одна цель: сделать крутой продукт, а не вставить друг другу палки в колёса.
> Эксперт потому и эксперт, что не должен доказывать каждый раз кому попало, что он не верблюд.
Это может быть в другом месте джуны это "кто попало", а у нас они уважаемые и компетентные люди, с которыми очень приятно работать. И если эксперт не может (или не хочет, козыряя грейдом) объяснить свою точку зрения, то вопросы будут скорее к эксперту, чем задающему вопрос.
> оптимального решения, основанного на опыте
Опыт - вещь субъективная. Открытые дискуссии не только помогают собрать коллективный опыт всех заинтересованных, но и шарят этот самый опыт между людьми, что не менее ценно.
Лично мне в удовольствие объяснить человеку свою точку зрения, когда я принимаю какое-либо решение, в выигрыше все. И я могу получить обратную связь и что-то улучшить, и собеседник ценное для себя усвоит.
> сектантство
Хохотнул, была у меня похожая мысль во время трудоустройства :D
Никто и не требует ходить с обходным листом по джунам и запрашивать их одобрения. Культура даёт возможность каждому сотруднику высказаться, но вовсе не обязывает этого делать. И да, если кто-то выразит сомнение в твоём решении, то тебе придется обосновывать его и доказывать свою экспертизу, не важно джун это сделал или архитектор. Из этого и рождаются лучшие решения, принятые совместно.
Работаю в майндбоксе почти два года, никаких игр престолов не заметил. Всё максимально комфортно и с уважением к людям. Карточки на ЗП очень эффективный способ роста, где ты можешь получить полезную обратную связь в моменте. Работать от целей считаю полезнее, чем просто делать задачки из беклога. Ставишь себе продуктовые цели, которые приносят компании деньги и достигаешь их. В итоге, все в плюсе: компания зарабатывает на новой фиче, ты повышаешь себе зарплату до нужного уровня.
А больше всего мне нравится открытость: я могу пойти к любому человеку (хоть к джуну из соседней команды, хоть к CTO), чтобы обсудить решение какой-то проблемы, если считаю, что он в контексте и может помочь. Или вовсе написать в публичный канал с архитекторами и найти оптимальное решение среди многих.
Мне кажется, не хватает данных по компаниям и по количеству вакансий. Вероятно, Go-разработчики получают больше потому что самих вакансий меньше и они находятся в наиболее прибыльных компаниях РФ. В отличие от того же 1С, где и малый, и средний бизнес вполне себе привлекает разработчиков на поддержку своих конфигураций.
Иными словами, пытаться ответить самому себе на вопрос "Куда мне идти работать" на основании только графиков зарплат я бы не стал.
А какой профит добавлять required в DTO? И почему не пользоваться record-типами? Сущности EF - это, по сути, те же DTO, как бы создатели фреймворка ни пытались подогнать их под богатую модель, какой профит там в required, мне тоже не понятно.
Для DTO я бы предложил все-таки использовать прекрасные record. Мб я не вижу, конечно, какой-то кейс, который закрывается этим нововведением, тогда я был бы рад увидеть пример
required спорное нововведение, имхо. Имеет смысл заменять им простые конструкторы с большим количеством параметров для того, чтобы повысить читаемость, ок. Но как только появится необходимость добавлять некоторую бизнес-логику при инициализации объекта, придется потом обратно возвращаться к конструктору и орудовать уже в нём. Так что полноценной замены конструктора тут нет, значительно
Для коллекции ссылочных типов перегон IEnumerable через ToList() означает копирование ссылок из итератора в лист, вряд ли вы в реальном проекте заметите какие-то существенные изменения в использовании памяти, другое дело — типы значимые. Но это предположение никак не отменяет факт, что перечисления нужно использовать правильно :)
Спасибо за точку зрения! Да, такое бывает и в таких местах тоже приходилось работать. Текущее место работы я и выбрал по причине того, что тут во главе угла здравый смысл.
> закрываются проекты из-за перерасхода бюджета на прирания на совещания
Компания продолжает рост даже в текущих непростых условиях на рынке РФ, можно ли сделать вывод, что перерасхода не случается и открытый подход работает?
Отдельно скажу, что получаю мега-кайф от общего канала с архитекторами всех команд, где можно жестко зарубиться за какую-нибудь серьезную продуктовую фичу и в итоге получить не только новый ценный опыт, но лучшее, выверенное решение. Первый раз такое встретил именно в майндбоксе.
Я не понимаю, где вы читаете "каждый раз"?
Тривиальные и очевидные задачи проезжают без каких-либо вопросов. Да, бывают ситуации, когда сеньор без знаний домена предлагает не самые лучшие решения и ему об этом открыто говорят более осведомленные в проблематике ребята, которые не обязательно должны быть равного или выше грейда. И все обсуждается на здравом смысле, так как у всех одна цель: сделать крутой продукт, а не вставить друг другу палки в колёса.
> Эксперт потому и эксперт, что не должен доказывать каждый раз кому попало, что он не верблюд.
Это может быть в другом месте джуны это "кто попало", а у нас они уважаемые и компетентные люди, с которыми очень приятно работать. И если эксперт не может (или не хочет, козыряя грейдом) объяснить свою точку зрения, то вопросы будут скорее к эксперту, чем задающему вопрос.
> оптимального решения, основанного на опыте
Опыт - вещь субъективная. Открытые дискуссии не только помогают собрать коллективный опыт всех заинтересованных, но и шарят этот самый опыт между людьми, что не менее ценно.
Лично мне в удовольствие объяснить человеку свою точку зрения, когда я принимаю какое-либо решение, в выигрыше все. И я могу получить обратную связь и что-то улучшить, и собеседник ценное для себя усвоит.
> сектантство
Хохотнул, была у меня похожая мысль во время трудоустройства :D
Но потом втянулся (промыли мозги)
Никто и не требует ходить с обходным листом по джунам и запрашивать их одобрения. Культура даёт возможность каждому сотруднику высказаться, но вовсе не обязывает этого делать. И да, если кто-то выразит сомнение в твоём решении, то тебе придется обосновывать его и доказывать свою экспертизу, не важно джун это сделал или архитектор. Из этого и рождаются лучшие решения, принятые совместно.
Работаю в майндбоксе почти два года, никаких игр престолов не заметил. Всё максимально комфортно и с уважением к людям. Карточки на ЗП очень эффективный способ роста, где ты можешь получить полезную обратную связь в моменте. Работать от целей считаю полезнее, чем просто делать задачки из беклога. Ставишь себе продуктовые цели, которые приносят компании деньги и достигаешь их. В итоге, все в плюсе: компания зарабатывает на новой фиче, ты повышаешь себе зарплату до нужного уровня.
А больше всего мне нравится открытость: я могу пойти к любому человеку (хоть к джуну из соседней команды, хоть к CTO), чтобы обсудить решение какой-то проблемы, если считаю, что он в контексте и может помочь. Или вовсе написать в публичный канал с архитекторами и найти оптимальное решение среди многих.
Мне кажется, не хватает данных по компаниям и по количеству вакансий. Вероятно, Go-разработчики получают больше потому что самих вакансий меньше и они находятся в наиболее прибыльных компаниях РФ. В отличие от того же 1С, где и малый, и средний бизнес вполне себе привлекает разработчиков на поддержку своих конфигураций.
Иными словами, пытаться ответить самому себе на вопрос "Куда мне идти работать" на основании только графиков зарплат я бы не стал.
А какой профит добавлять required в DTO? И почему не пользоваться record-типами?
Сущности EF - это, по сути, те же DTO, как бы создатели фреймворка ни пытались подогнать их под богатую модель, какой профит там в required, мне тоже не понятно.
Для DTO я бы предложил все-таки использовать прекрасные record. Мб я не вижу, конечно, какой-то кейс, который закрывается этим нововведением, тогда я был бы рад увидеть пример
required спорное нововведение, имхо. Имеет смысл заменять им простые конструкторы с большим количеством параметров для того, чтобы повысить читаемость, ок. Но как только появится необходимость добавлять некоторую бизнес-логику при инициализации объекта, придется потом обратно возвращаться к конструктору и орудовать уже в нём. Так что полноценной замены конструктора тут нет, значительно