Бесконечность. Т.к. как комменты на хабре не почитаешь, всех только размер ЗП интересует. А значит, не имеет значения, что они там поняли, пока им платят. А ещё у хорошего начальника они так и не поймут, что молотки, см "Люди которые играют в игры".
Вот это и есть культура. Я вот наоборот не хочу только задачи в код превращать. Я хочу знать, что и зачем я делаю, влиять на принятие решений. Соответственно беру на себя ответственность за результат. Получается, что есть компании в которых я не смогу работать физически.
Я бы культуру компанию определил как "у нас так принято". У всех, почему-то, принято по разному.
Так это и есть корпоративная культура: делать как принято в компании. Где-то поощряются переработки, где-то запрещаются. Где-то программист не видит заказчика, а где-то общение с заказчиком - это его обязанность. Где-то "мы все здесь ради денег", а где-то "мы семья, деньги не важное" и т.д. Из всех этих выборов и складывается корпоративная культура в моём представлении.
И вот человек делает не то, что надо, потому что не хочет. Он хочет код пилить, а не аналитикой заниматься.
прибыли можно извлечь больше, если не загонять насмерть.
Как же я этому рад!
Из инструмента нельзя извлечь прибыль, а из человека можно.
А можно развернуть мысль? С одной стороны я понимаю, что человек обладает самодвижением в отличии от инструмента, с другой стороны есть куча линейных должностей, которые стремятся стать функцией и мало чем отличаются от инструмента. Например, кассир - касса самообслуживания или вендинговый автомат, бариста - кофе-автомат, таксист - автопилот, оператор поддержки - книга со криптами.
мастерски расставить на места так, чтобы они вносили максимальный вклад в общее дело
Да ладно? С точки зрения бизнеса ещё какой инструмент. Только не такой простой как молоток.
Аналогия такая: инженеры используют инструменты, чтобы достичь цели, руководители используются людей, чтобы достичь цели. В такой аналогии, для них люди - это инструмент.
Талантливый специалист - понятие растяжимое, каждый вложит что-то своё, хорошее.
Мой пример как сотрудник не вписался в корпоративную культуру. Пришёл программист, сказал, я не хочу вникать в бизнес заказчика, я хочу делать таски. Код он писал быстро и круто, но не то. Типа, пока вы там бла-бла-бла я уже всё сделаю. Сделал, не то, переделал. Несколько раз прошёл по такому сценарии и, в итоге, сам ушёл.
По идее, идеальный "жиродробитель", легко найдёт себе хорошее место, но конкретно в эту компанию не вписался.
Прям сюжет фильма Подземелья и драконы: Честь среди воров. Там бард, с одной стороны вообще не тащит битвы, с другой стороны собрал пати, проработал мотивацию каждого и , в итоге. победил злобное зло.
Приложения, построенные на основе микросервисов, должны быть максимально независимыми и согласованными" - это фактически означает, что вы не должны через rpc клиент дергать какой-то микросервис
Не убедил. Не понимаю как одно из другого вытекает.
Я делал модульные монолиты, но выносить общение между модулями через внешние интеграции (http, очереди) казалось оверкилом. Кроме инфраструктурных сложностей мы ещё получаем все проблемы Eventual consistency. А в чём профит - непонятно.
Теперь вижу, в каких случаях такой подход может пригодиться.
Самое главное за проектом Common следить и всё будет хорошо.
Если это не рантайм исключение (не описывать же в каждом методе, что он может аут оф мемори кинуть), то описывать обязательно. Проблема в том, что этот подход (проверяемые исключения) все ненавидят.
Ну тут даже момента с недорого не будет ):
Чёт вы в цикл впали
А какая альтернатива?
Плохо чтоле? Хорошо!
Пусть продолжают
Бесконечность. Т.к. как комменты на хабре не почитаешь, всех только размер ЗП интересует. А значит, не имеет значения, что они там поняли, пока им платят. А ещё у хорошего начальника они так и не поймут, что молотки, см "Люди которые играют в игры".
Вот это и есть культура. Я вот наоборот не хочу только задачи в код превращать. Я хочу знать, что и зачем я делаю, влиять на принятие решений. Соответственно беру на себя ответственность за результат. Получается, что есть компании в которых я не смогу работать физически.
Я бы культуру компанию определил как "у нас так принято". У всех, почему-то, принято по разному.
Может не оказывать. Вообще это доведение до абсурда.
Вот скажите, вы меняли место работы? Все места работы были одинаковые или чем-то отличались друг от друга? Как можно было описать это отличие?
Так это и есть корпоративная культура: делать как принято в компании.
Где-то поощряются переработки, где-то запрещаются. Где-то программист не видит заказчика, а где-то общение с заказчиком - это его обязанность. Где-то "мы все здесь ради денег", а где-то "мы семья, деньги не важное" и т.д. Из всех этих выборов и складывается корпоративная культура в моём представлении.
И вот человек делает не то, что надо, потому что не хочет. Он хочет код пилить, а не аналитикой заниматься.
Как же я этому рад!
А можно развернуть мысль? С одной стороны я понимаю, что человек обладает самодвижением в отличии от инструмента, с другой стороны есть куча линейных должностей, которые стремятся стать функцией и мало чем отличаются от инструмента. Например, кассир - касса самообслуживания или вендинговый автомат, бариста - кофе-автомат, таксист - автопилот, оператор поддержки - книга со криптами.
Программист, а к чему вопрос?
Для меня это звучит так: люди - сложный инструмент.
Да ладно? С точки зрения бизнеса ещё какой инструмент. Только не такой простой как молоток.
Аналогия такая: инженеры используют инструменты, чтобы достичь цели, руководители используются людей, чтобы достичь цели. В такой аналогии, для них люди - это инструмент.
Талантливый специалист - понятие растяжимое, каждый вложит что-то своё, хорошее.
Мой пример как сотрудник не вписался в корпоративную культуру. Пришёл программист, сказал, я не хочу вникать в бизнес заказчика, я хочу делать таски. Код он писал быстро и круто, но не то. Типа, пока вы там бла-бла-бла я уже всё сделаю. Сделал, не то, переделал. Несколько раз прошёл по такому сценарии и, в итоге, сам ушёл.
По идее, идеальный "жиродробитель", легко найдёт себе хорошее место, но конкретно в эту компанию не вписался.
Прям сюжет фильма Подземелья и драконы: Честь среди воров. Там бард, с одной стороны вообще не тащит битвы, с другой стороны собрал пати, проработал мотивацию каждого и , в итоге. победил злобное зло.
Крутые спецы могут работать с тем что есть, с самым дерьмовым инструментом, даже из плохого оборудования выжимают максимум, но почему-то не хотят.
Не убедил. Не понимаю как одно из другого вытекает.
А ещё композиция апи не микросервисный паттерн https://microservices.io/patterns/data/api-composition.html
Нормальная статья, подход понятен.
Я делал модульные монолиты, но выносить общение между модулями через внешние интеграции (http, очереди) казалось оверкилом. Кроме инфраструктурных сложностей мы ещё получаем все проблемы Eventual consistency. А в чём профит - непонятно.
Теперь вижу, в каких случаях такой подход может пригодиться.
Самое главное за проектом Common следить и всё будет хорошо.
Копипаст!
Если это не рантайм исключение (не описывать же в каждом методе, что он может аут оф мемори кинуть), то описывать обязательно.
Проблема в том, что этот подход (проверяемые исключения) все ненавидят.
Вы хоть вычитывайте перевод