Имя, фамилия, год рождения - если вы не Мохаммед Ахмет, то в 8-миллионной Швейцарии по этим трем критериям компьютер выдаст 2-3 строки. Как этот факт связан с тотальной государственной слежкой в РФ ?
«Никогда и ничего не просите! Никогда и ничего, и в особенности у тех, кто сильнее вас. Сами предложат и сами всё дадут!»
"Мастер и Маргарита" - лучшая в мировом искусстве реализация архетипа про искушение Дьяволом. Потому что в нём жертвой становятся не только персонажи, но и читатели. Кого ни спросишь - считают Воланда положительным героем)
В смысле, вы подумали, что я это только что решил? Но я с 2019 года работаю в иностранных компаниях с обязательным английским. А решил ещё в школе, которую я закончил, когда вы, скорее всего, ещё не родились)
Это была просто более вежливая версия высказывания типа "если ты не знаешь английский - ты не инженер, а в лучшем случае личинка инженера". Пришлось разжевать, увы, с пониманием намёков у людей обычно так же плохо, как со знанием языков.
Я для себя решил, что надо учить английский язык, потому что IT и software engineering развиваются в основном в англоязычном сегменте, и без возможности брать оттуда всё новое никакого профессионального роста не будет.
Вышедший в топ перевод статьи 2016 года, да ещё и с использованием термина "обратная разработка" вместо "реверс-инжиниринг", в полном соответствии с политикой и курсом партии "Единая Россия". Буду использовать как иллюстрацию деградации российского IT, спасибо.
Аналогия с вином плохая. Я даже не сомелье, просто любитель с большим стажем, но в игре "винная рулетка", когда надо угадать страну, сорт винограда, крепость и содержание сахара - показываю результаты статистически выше среднего. Вино Сицилии от Бордо отличить проще простого, на Сицилии вулканические почвы, а в Бордо - известняковые (на левом берегу, с правым сложнее, но там выращивают в основном мерло, которое любой человек с минимальным опытом определит с закрытыми глазами).
Я правильно понял, что нагрузка в главную mySQL базу была на чтение? Есть какая-то причина, почему у вас на ней не реализованы master-slaves репликация и чтение с реплик?
Вообще ООП возникло как средство упрощения разработки больших программных продуктов, в основном улучшения модульности. Если в условном C (чтобы было ближе к обсуждаемым временам) мне надо было писать #include somelib.h, а потом дёргать подключенные функции, передавая им на вход сконструированные разработчиком библиотеки типы, то в ООП вместо этого кастомные типы и функции для их обработки собраны в объекты. То, что объекты ООП сопоставимы с объектами реального мира - побочное явление, и нельзя сказать, что этого не было до ООП. Я могу декларировать тип struct duck { int age; bool gender}, и затем экспортировать из библиотеки функции void quack(d duck); void fly(d duck);
Проблема с таким подходом в том, что я показываю всему миру внутренности duck и, что ещё хуже, позволяю их модифицировать. Проблема тут не в дисциплине или осознанности разработчика, а в том, что у меня нет способа сказать пользователю своей библиотеки, что можно трогать, а что нельзя. Также я не мог сказать, какие функции библиотеки предназначены для внешнего использования, а какие нет (static появилось позже) Обернуть это всё в объект - способ сократить размер API, предоставляемого библиотекой, а значит упростить жизнь пользователя и разработку новых версий и миграцию на них - нужно поддерживать меньше совместимости.
Я бы насторожился, если ревью РЕЖЕ, чем три раза в год. Ревью нужно для получения подробной стратегической обратной связи, корректировки косяков, осознания своего положения на карте. Зачем мне в январе обратная связь по тому, что происходило в июне?
Я понимаю, что эта статья - чистый кликбейт, хотя и очень трудозатратный, но всё же добавлю важный комментарий:
Сравнение с другими операторами спутникового интернета.
В этой ключевой табличке нет одной важной строки: throttling. Даже на "безлимитном" тарифе HughesNet резко уменьшает полосу пропускания после того, как абонент потребит 15 гигабайт трафика. Может показаться, что это много, но "на самом деле нет". Я сейчас посмотрел статистику по адаптеру компа, с которого пишу этот комментарий - 37 гигабайт за 9 дней, 4 гигабайта в сутки. Я не смотрю киностриминги, YouTube открываю в среднем минут на 15-20 в день. Зато каждый день у меня есть Zoom-созвоны. "Безлимитного" спутникового интернета мне хватит на 4 дня работы, а дальше - привет. То есть традиционные спутниковые провайдеры для меня, если что, просто не подходят.
Спасибо за то, что подняли интересную тему! К моему удивлению, я не знал раньше про Джеффа Дина!
Хочу предложить своей взгляд на некоторые моменты из статьи:
Ему самому неприятно командовать коллегами
Руководить - не значит командовать. Есть ещё такое понятие как "лидерство", и в инженерных командах компетентным людям проще и правильнее именно быть лидером, вести команду за собой, показывать на своём примере, делиться своими знаниями и экспертизой. Люди, заинтересованные в профессиональном развитии, с удовольствием будут работать с таким человеком, и всем в этой схеме будет комфортно и продуктивно.
- избегать конфликтов
- говорить обтекаемо, чтобы никого не обидеть
Это необязательно должно быть так. Есть ситуации, где такие навыки нужны, но в целом люди нормально реагируют на критику, если она конструктивна, actionable (как это будет по-русски?) и подана в уважительной манере. Последнему несложно научиться; более того, по моему опыту самые сильные инженеры обычно общаются именно так, потому что им на самом деле не надо демонстрировать или защищать свой ранг в группе, все вокруг и так знают, что они компетентные и к их словам надо автоматически прислушиваться.
И наоборот: даже компетентный специалист, не умеющий нормально общаться с коллегами и подчинёнными, быстро растеряет уважение людей, а возможно и самих людей - сейчас не XX век, сменить работу или как минимум команду - не такая проблема.
игнорировать мнения и советы от некомпетентных коллег
И снова: уважительная манера коммуникации диктует нам не игнорировать коллег, а разъяснять им их неправоту, что, опять же, опытному инженеру не составит труда.
Я за свою трудовую биографию запромоутил в тимлидов нескольких очень толковых ребят. И каждый раз говорю им: руководство командой - это горизонтальное масштабирование тебя как инженера, чтобы достигнуть уровня производительности, недостижимой при вертикальном профессиональном росте. Конечно, становиться руководителем - это сильное изменение, но в этом нет ничего невозможного, если человек это интересно и есть желание развиваться в эту сторону.
Смотрите, в нормальном мире есть такой специальный человек, менеджер продукта, который 1) знает как надо 2) может записать это знание в виде спецификации 3) может найти общий язык с инженером, совместно с ним эту спецификацию привести к виду, пригодному к техническому воплощению.
Это задача менеджера продукта - влезть в шкуру пользователя и понять, какие у него потребности и пути их удовлетворения.
Имя, фамилия, год рождения - если вы не Мохаммед Ахмет, то в 8-миллионной Швейцарии по этим трем критериям компьютер выдаст 2-3 строки. Как этот факт связан с тотальной государственной слежкой в РФ ?
"Мастер и Маргарита" - лучшая в мировом искусстве реализация архетипа про искушение Дьяволом. Потому что в нём жертвой становятся не только персонажи, но и читатели. Кого ни спросишь - считают Воланда положительным героем)
Без пассивной агрессии, пожалуйста. Я это привёл не как отличие, а как приятную лично мне фичу. Перечисленными продуктами не пользовался.
Без пассивной агрессии, пожалуйста. Я это привёл не как отличие, а как приятную лично мне фичу. Перечисленными продуктами не пользовался.
В смысле, вы подумали, что я это только что решил? Но я с 2019 года работаю в иностранных компаниях с обязательным английским. А решил ещё в школе, которую я закончил, когда вы, скорее всего, ещё не родились)
Это была просто более вежливая версия высказывания типа "если ты не знаешь английский - ты не инженер, а в лучшем случае личинка инженера". Пришлось разжевать, увы, с пониманием намёков у людей обычно так же плохо, как со знанием языков.
Я для себя решил, что надо учить английский язык, потому что IT и software engineering развиваются в основном в англоязычном сегменте, и без возможности брать оттуда всё новое никакого профессионального роста не будет.
Чтобы консоль привести в чувство - надо набрать `chcp 65001`. У меня это первая пользовательская функция в User menu.
И ещё приятно, что по кнопке контекстного меню открывается контекстное меню.
Вышедший в топ перевод статьи 2016 года, да ещё и с использованием термина "обратная разработка" вместо "реверс-инжиниринг", в полном соответствии с политикой и курсом партии "Единая Россия". Буду использовать как иллюстрацию деградации российского IT, спасибо.
Аналогия с вином плохая. Я даже не сомелье, просто любитель с большим стажем, но в игре "винная рулетка", когда надо угадать страну, сорт винограда, крепость и содержание сахара - показываю результаты статистически выше среднего. Вино Сицилии от Бордо отличить проще простого, на Сицилии вулканические почвы, а в Бордо - известняковые (на левом берегу, с правым сложнее, но там выращивают в основном мерло, которое любой человек с минимальным опытом определит с закрытыми глазами).
Я правильно понял, что нагрузка в главную mySQL базу была на чтение? Есть какая-то причина, почему у вас на ней не реализованы master-slaves репликация и чтение с реплик?
И в самом деле, а что случилось?
Вообще ООП возникло как средство упрощения разработки больших программных продуктов, в основном улучшения модульности. Если в условном C (чтобы было ближе к обсуждаемым временам) мне надо было писать
#include somelib.h, а потом дёргать подключенные функции, передавая им на вход сконструированные разработчиком библиотеки типы, то в ООП вместо этого кастомные типы и функции для их обработки собраны в объекты. То, что объекты ООП сопоставимы с объектами реального мира - побочное явление, и нельзя сказать, что этого не было до ООП. Я могу декларировать типstruct duck { int age; bool gender}, и затем экспортировать из библиотеки функцииvoid quack(d duck); void fly(d duck);Проблема с таким подходом в том, что я показываю всему миру внутренности
duckи, что ещё хуже, позволяю их модифицировать. Проблема тут не в дисциплине или осознанности разработчика, а в том, что у меня нет способа сказать пользователю своей библиотеки, что можно трогать, а что нельзя. Также я не мог сказать, какие функции библиотеки предназначены для внешнего использования, а какие нет (staticпоявилось позже) Обернуть это всё в объект - способ сократить размер API, предоставляемого библиотекой, а значит упростить жизнь пользователя и разработку новых версий и миграцию на них - нужно поддерживать меньше совместимости.Я ж примерно написал: для получения обратной связи, для постановки целей развития, для трекинга прогресса, для корректировки косяков.
Я бы насторожился, если ревью РЕЖЕ, чем три раза в год. Ревью нужно для получения подробной стратегической обратной связи, корректировки косяков, осознания своего положения на карте. Зачем мне в январе обратная связь по тому, что происходило в июне?
Я понимаю, что эта статья - чистый кликбейт, хотя и очень трудозатратный, но всё же добавлю важный комментарий:
В этой ключевой табличке нет одной важной строки: throttling. Даже на "безлимитном" тарифе HughesNet резко уменьшает полосу пропускания после того, как абонент потребит 15 гигабайт трафика. Может показаться, что это много, но "на самом деле нет". Я сейчас посмотрел статистику по адаптеру компа, с которого пишу этот комментарий - 37 гигабайт за 9 дней, 4 гигабайта в сутки. Я не смотрю киностриминги, YouTube открываю в среднем минут на 15-20 в день. Зато каждый день у меня есть Zoom-созвоны. "Безлимитного" спутникового интернета мне хватит на 4 дня работы, а дальше - привет. То есть традиционные спутниковые провайдеры для меня, если что, просто не подходят.
Спасибо за то, что подняли интересную тему! К моему удивлению, я не знал раньше про Джеффа Дина!
Хочу предложить своей взгляд на некоторые моменты из статьи:
Руководить - не значит командовать. Есть ещё такое понятие как "лидерство", и в инженерных командах компетентным людям проще и правильнее именно быть лидером, вести команду за собой, показывать на своём примере, делиться своими знаниями и экспертизой. Люди, заинтересованные в профессиональном развитии, с удовольствием будут работать с таким человеком, и всем в этой схеме будет комфортно и продуктивно.
Это необязательно должно быть так. Есть ситуации, где такие навыки нужны, но в целом люди нормально реагируют на критику, если она конструктивна, actionable (как это будет по-русски?) и подана в уважительной манере. Последнему несложно научиться; более того, по моему опыту самые сильные инженеры обычно общаются именно так, потому что им на самом деле не надо демонстрировать или защищать свой ранг в группе, все вокруг и так знают, что они компетентные и к их словам надо автоматически прислушиваться.
И наоборот: даже компетентный специалист, не умеющий нормально общаться с коллегами и подчинёнными, быстро растеряет уважение людей, а возможно и самих людей - сейчас не XX век, сменить работу или как минимум команду - не такая проблема.
И снова: уважительная манера коммуникации диктует нам не игнорировать коллег, а разъяснять им их неправоту, что, опять же, опытному инженеру не составит труда.
Я за свою трудовую биографию запромоутил в тимлидов нескольких очень толковых ребят. И каждый раз говорю им: руководство командой - это горизонтальное масштабирование тебя как инженера, чтобы достигнуть уровня производительности, недостижимой при вертикальном профессиональном росте. Конечно, становиться руководителем - это сильное изменение, но в этом нет ничего невозможного, если человек это интересно и есть желание развиваться в эту сторону.
Прекрасно отзываюсь на "Викторыч, текилу будешь?"
Наверное всё же "готов провести собеседование", а не взять на работу.
Смотрите, в нормальном мире есть такой специальный человек, менеджер продукта, который 1) знает как надо 2) может записать это знание в виде спецификации 3) может найти общий язык с инженером, совместно с ним эту спецификацию привести к виду, пригодному к техническому воплощению.
Это задача менеджера продукта - влезть в шкуру пользователя и понять, какие у него потребности и пути их удовлетворения.