У меня в нескольких командах (FAANG, Лондон/США) есть два чатика - один собственно рабочий, <teamname-eng>, второй - болталка, <teamname-chatty>. Те, кто хотят - читают оба, другие могут замьютить второй (или читать от случая к случаю).
У меня был довольно длительный период, когда я активно экспериментировал с разными роутерами, прошивками, самопальными сборками на базе Mini-PC - но в итоге в новом доме я поставил роутер Unifi USG 4 (как жаль что нет новой версии!) - в него втыкаются два независимых WAN провода, и три точка доступа UniFi - прекрасное покрытие по всему дому, и работает как часы. Честно говоря, в какой-то момент я понял, что трачу слишком много времени на это, а нужно решение, которое просто работает, 24x7.
Unifi не лишен своих недостатков, но его легко развертывать, управлять, обновлять и т.п. - к тому же все это делается через очень простой графический интерфейс (в отличии от).
Ну я говорю скорее об engineering manager - проджект менеджмент это все-таки немного другое с моей точки зрения. Но при этом все эти дисциплины, безусловно, пересекаются и в разных компаниях акценты расставляются по-разному.
Многое из написаного здесь специфично именно для заказной разработки. Если не трогать аспект people management (а это совершенно отдельная тема), а сосредоточиться на продуктовой разработке, то я бы добавил следующее:
Неуменее или нежелание думать о том, что нужно пользователю. "Это проблема продакт менеджера" - поверьте, это точно путь в никуда. На старших уровнях engineering management становится слабо отличим от product management - что естественно, потому что на самых верхних уровнях (executive management) эта разница зачастую исчезает вообще.
Стремление делать фичи, а не решать проблемы. Этот пункт тесно связан с предыдущим. Зачастую я вижу, как начинающие менеджеры пытаются питчить "фичи", не очень понимая, какую пользовательскую проблему они решают. Я помню фразу Генри Форда про более быстрых лошадей, но даже в создании автомобиля был четкий акцент на решение проблемы пользователей - пусть даже они не могут ее правильно сформулировать.
Желание получить полную, стопроцентную ясность "а что же мы все таки делаем?" до того, как написана первая строчка кода. Вот поверьте, так просто не бывает. 100% ясность может быть только если мы пытаемся скопировать фияу конкурента - и значит, мы уже опоздали на рынок. Умение жить в климате постоянной неясности, нечетких требований - и умение их постепенно прояснять - это критический скилл для senior management. На верхних уровнях менеджмента проблемы зачастую формулируются как "у нас что-то все плохо, а надо чтобы было все хорошо" - и это, к сожалению, не преувеличение.
На самом деле о менеджменте написано много, очень много книг. Своим менеджерам, как начинающим, так и опытным, я часто рекомендую книгу The Manager's Path - там есть ответы на многие вопросы. В то же время, я активно советую им изучать аспекты смежных профессий - например, если ваша работа завязана на активное взаимодействие с пользователем, изучение таких дисциплин как User Experience, UX Research и просто product management становится очень важным.
Когда-нибудь я соберусь с мыслями и напишу длиннопост на эту тему, но если интересно - готов пообщаться и поотвечать на вопросы.
Sony отличные уши, я недавно проагрейдился с XM3 на XM5 - особой разницы нету, но multi-point bluetooth мне сильно по нраву (т.е. подключены одновременно к телефону и компьютеру, и музыку можно играть и с того, и с другого). В самолете они просто шикарны - за 10 часов я их снимаю может быть пару раз.
Для звонков использую Jabra Evolve 75 - их крутая фишка это шумоподавляющий микрофон; работаю из одной комнаты с женой и это реально спасает.
На своем опыте напишу - к моменту, когда я пошел в 10 класс, по-моему, абсолютно всем было понятно, что я буду программистом. Ну, я имею в виду, всем кроме меня.
Я хотел быть журналистом. И даже что-то куда-то писал и меня даже где-то публиковали (аж раза два). А потом я хотел работать в финансах. А потом я еще хотел ...
Короче я очень благодарен своим родителям за то, что они - вероятно, зная или хотя бы подозревая какой будет финальный результат - терпели мои заскоки и давали мне определиться самостоятельно. Теперь, уже сам будучи отцом, я понимаю что скорее всего они меня мягко ориентировали именно на мою текущую карьеру (хотя когда спрашивал -надцать лет спустя, уходили в глухую несознанку) -- но при этом поддерживали любые мои начинания. Дай мне Б-г терпения так же помочь моим детям.
Во-первых, если вы работаете в большой компании которая поощряет internal mobility, можно менять команду а не компанию. А во-вторых, когда я смотрю на людей в более сеньорных позициях, как правило (хотя и не всегда) они подолгу работают в одной компании, нарабатывая политический капитал, изучая как работает компания, индустрию и т.п. Это не значит, что они не меняют позиции - меняют, но намного реже (по моим прикидкам медианное время работы в компании как минимум 5-6 лет, и нередко 10+).
Но это относится именно к позициям уровня senior manager в FAANG и эквивалентным им (L7+).
Хочу сказать пару слов про первую книгу. Я нашел ее буквально случайно, когда я первый раз стал менеджером. С тех пор я рекомендую эту книгу всем своим подчиненным - будь они менеджеры менеджеров, линейные менеджеры, тимлиды или просто инженеры которые думают о переходе на лидерские позиции.
Почему мне так нравится эта книга? По ряду причин.
Она написана очень простым и понятным, no-bullshit языком, инженером для инженеров. Многие книги по бизнесу и лидерству (особенно американских авторов) грешат тем, что первые три главы тебе рассказывают о том, как этот подход изменил жизнь многих известных людей, потом еще две о том, как автор пришел к этому подходу, и только в конце, кратенько - в чем, собственно, подход заключается.
Ее можно читать в любом порядке, в том числе - как справочник. Может показаться, что если ты TL, то глава The Big Leagues тебе пока не нужна - но это не так. Чтение поможет понять, как мыслят люди в таких позициях, что для них важно и как выстраивать разговор и аргументацию с ними.
В том числе, если ты менеджер менеджеров, читая главу про TL-ов, можно лучше понять как растить людей, как давать им stretch goals (задачи по силам, но на пределе, которые стимулируют развитие)
В книге довольно много конкретных примеров и рекомендаций, в стиле "попробуй так, а не получится, попробуй еще вот так".
Наконец, эта книга описывает не сферический менеджмент в вакууме, а менеджмент именно инженерных команд - в этом (как, пожалуй, и везде) очень много специфики, и ее нельзя не учитывать.
Короче, это отличная книга и я настоятельно рекомендую ее всем, кому интересно лидерство именно в технической сфере.
Это делается при помощи two stage build, примерно вот так:
# Stage 1: building the binary
FROM tetafro/golang-gcc:latest
RUN mkdir /app
# Installing all dependencies that are required for build
RUN apk add sqlite gawk bash wget curl
# Copying _everything_ to the image
ADD . /app
WORKDIR /app
# Building binaries
RUN go build -o downloader cmd/downloader/main.go
RUN go build -o flibustier_server -tags fts5 flibuserver/server/*.go
# Stage 2: creating the actual production image
FROM alpine:latest # note that using tiny basic alpine image
RUN mkdir /app
ADD download_launcher.sh
# Installing only dependencies needed at runtime
RUN apk add sqlite gawk bash curl
WORKDIR /app
# Copying binaries _from the first image_
COPY --from=0 /app/downloader /app/downloader
COPY --from=0 /app/flibustier_server /app/flibustier_server
EXPOSE 9000
# Entry point
CMD /app/downloader_launcher.sh ; /app/flibustier_server --flibusta_db=/app/flibusta.db --port=90009000
Я задавал похожий вопрос товарищам из фейсбука когда они мне расказывали про HipHop, и задам его еще раз — кроме исторических причин (куча кода на PHP), есть ли преимущества перед реализацией продукта сразу на типизированном языке, с JIT или компиляцией в машинный код?
Аргументом, разумеется, является то, что "а вы знаете сколько у нас строк на PHP?!?". На мой взгляд, аргумент это довольно слабый: в конце концов, никто не мешает разбивать код на микросервисы, связанные RPC, и переписывать их по отдельности, начиная с самых критичных по производительсности (вариант: с самым загнившим кодом). В конце концов, те части, которые действительно проще написать на PHP, можно на нем и оставить — выполняя все performance-critical задачи в native code.
В реальности все не так однозначно, и довольно тяжело мерить все команды и всех сотрудников по одной мерке. По опыту моей команды, после 6 месяцев дома, большинство достигли уровня продуктивности как в офисе или выше, но даже в этом случае остается немало ситуаций про которые сами сотрудники говорят что «было бы классно собраться в одной комнате и обсудить ». Несмотря на то, что лично мне очень комфортно работать из дома, я осознаю, что не у всех есть таки условия, и «фишки» офиса имеют разную ценность для разных людей (например, если ты живешь во flat share (типичная ситуация в больших городах), и «твое» пространство ограничевается твоей спальней, работать из дома, мягко говоря, некомфортно). Кроме того, не надо забывать про тех, кому требуется специальное оборудование, которое часто используется несколькими инженерами по очереди.
Я поддерживаю идею гибридной работы, и готов экспериментировать, пытаясь найти оптимальный баланс (и моя команда скорее согласна с таким подходом).
Если ты хочешь назвать что-то говном, то называй это говном, а не фекалиями. Если кто-то написал херовый код, то так ему и скажи: «Ты написал херовый код».
Когда я первый раз стал менеджером менеджеров, мой начальник сказал мне одну умную вещь: "Когда ты находишься в позиции власти (authority), все что ты говоришь даже шепотом, [для твоих сотрудников] будет звучать как из мегафона, поэтому думай трижды что и как ты говоришь"
Если я увижу херовый код, я попробую выяснить почему человек написал его именно так, и может быть дам рекомендации как его улучшить. Услышать что ты пишешь херовый код от начальника твоего начальника это довольно жестко.
Это верно. Исследованиями подтвержден тот факт, что в целом для человека благосостояние в абсолютном масштабе имеет меньшее значение нежели в относительном (грубо говоря, если все живут плохо и бедно, для ощущения благосостояния достаточно жить лишь чуть менее плохо и бедно).
Это тоже верно. Но представьте себе ситуацию. Вот есть у нас гипотетический разработчик, зарабатывающий ну скажем $100K в год, за вычетом налогов ну условно $75K, то есть $6250 в месяц Если им поднимум зарплату на 10%, что немало, он будет зарабатывать на $625 в месяц больше — что в целом уже не очень ощутимо, потому что им и до этого хватало. Ну сможет купить машину подороже, но и текущая машина вполне себе пристойная. В магазин будут ходить все тот же, потому что он рядом а более крутой, дорогой — дальше. Дети будут ходить в ту же школу потому что все вроде бы нормально.
Ситуация меняется радикально, если им на что-то не хватает — например, хочет человек купить дом, и понимают что ипотеку ну не тянут они сейчас. Здесь эти деньги сыграют — но если и дом уже есть, и платежи вменяемые, удельная ценность этих несчастных шестисот баксов сильно падает.
Я не говорю о том, что не надо платить больше — надо. Но в какой-то момент чисто деньги как мотивационный инструмент начинают давать сбои.
Во-первых, давайте сразу примем как факт: разные люди требуют разного подхода к мотивации, и это функция времени/ситуации. Для кого-то это действительно деньги — по крайней мере, до какого-то уровня. По достижению определенного дохода +$nK ничего не меняет в глобальной картине мира человека, потому что ему хватало раньше, и хватает теперь. На первую позицию выходят более высокоуровневые факторы (например, интерес задачи, признание и т.п.). Классическая пирамида Маслоу, несмотря на всю критику, продолжает оставаться удовлетворительной апроксимацией. Так что можно сказать что мотивация деньгами краткосрочна, но все зависит от человека, ситуации в которой он находится, и что он ставит на первое место в этот момент времени.
У меня в нескольких командах (FAANG, Лондон/США) есть два чатика - один собственно рабочий, <teamname-eng>, второй - болталка, <teamname-chatty>. Те, кто хотят - читают оба, другие могут замьютить второй (или читать от случая к случаю).
Спасибо за статью! Понятно о сложных вещах - это верный путь.
Причем уже какое-то время - https://www.bnymellon.com/us/en/insights/all-insights/artificial-intelligence-sweeps-hedge-funds.html
Сейчас вообще повсеместно, и те хедж-фонды которые не используют AI рискуют оказаться без маржи. Однако одним только AI обойтись не получается, поэтому это скорее помощник чем главный decision maker: https://www.livemint.com/opinion/columns/ai-in-finance-hype-or-opportunity-jpmorgan-s-ai-bot-generates-trade-signals-but-can-it-beat-the-market-11683655569834.html
У меня был довольно длительный период, когда я активно экспериментировал с разными роутерами, прошивками, самопальными сборками на базе Mini-PC - но в итоге в новом доме я поставил роутер Unifi USG 4 (как жаль что нет новой версии!) - в него втыкаются два независимых WAN провода, и три точка доступа UniFi - прекрасное покрытие по всему дому, и работает как часы. Честно говоря, в какой-то момент я понял, что трачу слишком много времени на это, а нужно решение, которое просто работает, 24x7.
Unifi не лишен своих недостатков, но его легко развертывать, управлять, обновлять и т.п. - к тому же все это делается через очень простой графический интерфейс (в отличии от).
Ну я говорю скорее об engineering manager - проджект менеджмент это все-таки немного другое с моей точки зрения. Но при этом все эти дисциплины, безусловно, пересекаются и в разных компаниях акценты расставляются по-разному.
Многое из написаного здесь специфично именно для заказной разработки. Если не трогать аспект people management (а это совершенно отдельная тема), а сосредоточиться на продуктовой разработке, то я бы добавил следующее:
Неуменее или нежелание думать о том, что нужно пользователю. "Это проблема продакт менеджера" - поверьте, это точно путь в никуда. На старших уровнях engineering management становится слабо отличим от product management - что естественно, потому что на самых верхних уровнях (executive management) эта разница зачастую исчезает вообще.
Стремление делать фичи, а не решать проблемы. Этот пункт тесно связан с предыдущим. Зачастую я вижу, как начинающие менеджеры пытаются питчить "фичи", не очень понимая, какую пользовательскую проблему они решают. Я помню фразу Генри Форда про более быстрых лошадей, но даже в создании автомобиля был четкий акцент на решение проблемы пользователей - пусть даже они не могут ее правильно сформулировать.
Желание получить полную, стопроцентную ясность "а что же мы все таки делаем?" до того, как написана первая строчка кода. Вот поверьте, так просто не бывает. 100% ясность может быть только если мы пытаемся скопировать фияу конкурента - и значит, мы уже опоздали на рынок. Умение жить в климате постоянной неясности, нечетких требований - и умение их постепенно прояснять - это критический скилл для senior management. На верхних уровнях менеджмента проблемы зачастую формулируются как "у нас что-то все плохо, а надо чтобы было все хорошо" - и это, к сожалению, не преувеличение.
На самом деле о менеджменте написано много, очень много книг. Своим менеджерам, как начинающим, так и опытным, я часто рекомендую книгу The Manager's Path - там есть ответы на многие вопросы. В то же время, я активно советую им изучать аспекты смежных профессий - например, если ваша работа завязана на активное взаимодействие с пользователем, изучение таких дисциплин как User Experience, UX Research и просто product management становится очень важным.
Когда-нибудь я соберусь с мыслями и напишу длиннопост на эту тему, но если интересно - готов пообщаться и поотвечать на вопросы.
Sony отличные уши, я недавно проагрейдился с XM3 на XM5 - особой разницы нету, но multi-point bluetooth мне сильно по нраву (т.е. подключены одновременно к телефону и компьютеру, и музыку можно играть и с того, и с другого). В самолете они просто шикарны - за 10 часов я их снимаю может быть пару раз.
Для звонков использую Jabra Evolve 75 - их крутая фишка это шумоподавляющий микрофон; работаю из одной комнаты с женой и это реально спасает.
На своем опыте напишу - к моменту, когда я пошел в 10 класс, по-моему, абсолютно всем было понятно, что я буду программистом. Ну, я имею в виду, всем кроме меня.
Я хотел быть журналистом. И даже что-то куда-то писал и меня даже где-то публиковали (аж раза два). А потом я хотел работать в финансах. А потом я еще хотел ...
Короче я очень благодарен своим родителям за то, что они - вероятно, зная или хотя бы подозревая какой будет финальный результат - терпели мои заскоки и давали мне определиться самостоятельно. Теперь, уже сам будучи отцом, я понимаю что скорее всего они меня мягко ориентировали именно на мою текущую карьеру (хотя когда спрашивал -надцать лет спустя, уходили в глухую несознанку) -- но при этом поддерживали любые мои начинания. Дай мне Б-г терпения так же помочь моим детям.
В 3.15.0 снова завезли optional fields, стало как в proto2
Это не всегда так.
Во-первых, если вы работаете в большой компании которая поощряет internal mobility, можно менять команду а не компанию. А во-вторых, когда я смотрю на людей в более сеньорных позициях, как правило (хотя и не всегда) они подолгу работают в одной компании, нарабатывая политический капитал, изучая как работает компания, индустрию и т.п. Это не значит, что они не меняют позиции - меняют, но намного реже (по моим прикидкам медианное время работы в компании как минимум 5-6 лет, и нередко 10+).
Но это относится именно к позициям уровня senior manager в FAANG и эквивалентным им (L7+).
Хочу сказать пару слов про первую книгу. Я нашел ее буквально случайно, когда я первый раз стал менеджером. С тех пор я рекомендую эту книгу всем своим подчиненным - будь они менеджеры менеджеров, линейные менеджеры, тимлиды или просто инженеры которые думают о переходе на лидерские позиции.
Почему мне так нравится эта книга? По ряду причин.
Она написана очень простым и понятным, no-bullshit языком, инженером для инженеров. Многие книги по бизнесу и лидерству (особенно американских авторов) грешат тем, что первые три главы тебе рассказывают о том, как этот подход изменил жизнь многих известных людей, потом еще две о том, как автор пришел к этому подходу, и только в конце, кратенько - в чем, собственно, подход заключается.
Ее можно читать в любом порядке, в том числе - как справочник. Может показаться, что если ты TL, то глава The Big Leagues тебе пока не нужна - но это не так. Чтение поможет понять, как мыслят люди в таких позициях, что для них важно и как выстраивать разговор и аргументацию с ними.
В том числе, если ты менеджер менеджеров, читая главу про TL-ов, можно лучше понять как растить людей, как давать им stretch goals (задачи по силам, но на пределе, которые стимулируют развитие)
В книге довольно много конкретных примеров и рекомендаций, в стиле "попробуй так, а не получится, попробуй еще вот так".
Наконец, эта книга описывает не сферический менеджмент в вакууме, а менеджмент именно инженерных команд - в этом (как, пожалуй, и везде) очень много специфики, и ее нельзя не учитывать.
Короче, это отличная книга и я настоятельно рекомендую ее всем, кому интересно лидерство именно в технической сфере.
Это делается при помощи two stage build, примерно вот так:
Ну как вариант перевести все на PHP 8 — опять же, используя микросервисную архитектуру чтобы не релизить весь миллион строк кода за один раз.
Кстати про то что PHP 8 типизированый и JIT не знал — очень давно не писал на PHP, уже не в курсе что происходит в этом мире :)
Я задавал похожий вопрос товарищам из фейсбука когда они мне расказывали про HipHop, и задам его еще раз — кроме исторических причин (куча кода на PHP), есть ли преимущества перед реализацией продукта сразу на типизированном языке, с JIT или компиляцией в машинный код?
Аргументом, разумеется, является то, что "а вы знаете сколько у нас строк на PHP?!?". На мой взгляд, аргумент это довольно слабый: в конце концов, никто не мешает разбивать код на микросервисы, связанные RPC, и переписывать их по отдельности, начиная с самых критичных по производительсности (вариант: с самым загнившим кодом). В конце концов, те части, которые действительно проще написать на PHP, можно на нем и оставить — выполняя все performance-critical задачи в native code.
В реальности все не так однозначно, и довольно тяжело мерить все команды и всех сотрудников по одной мерке. По опыту моей команды, после 6 месяцев дома, большинство достигли уровня продуктивности как в офисе или выше, но даже в этом случае остается немало ситуаций про которые сами сотрудники говорят что «было бы классно собраться в одной комнате и обсудить ». Несмотря на то, что лично мне очень комфортно работать из дома, я осознаю, что не у всех есть таки условия, и «фишки» офиса имеют разную ценность для разных людей (например, если ты живешь во flat share (типичная ситуация в больших городах), и «твое» пространство ограничевается твоей спальней, работать из дома, мягко говоря, некомфортно). Кроме того, не надо забывать про тех, кому требуется специальное оборудование, которое часто используется несколькими инженерами по очереди.
Я поддерживаю идею гибридной работы, и готов экспериментировать, пытаясь найти оптимальный баланс (и моя команда скорее согласна с таким подходом).
Когда я первый раз стал менеджером менеджеров, мой начальник сказал мне одну умную вещь: "Когда ты находишься в позиции власти (authority), все что ты говоришь даже шепотом, [для твоих сотрудников] будет звучать как из мегафона, поэтому думай трижды что и как ты говоришь"
Если я увижу херовый код, я попробую выяснить почему человек написал его именно так, и может быть дам рекомендации как его улучшить. Услышать что ты пишешь херовый код от начальника твоего начальника это довольно жестко.
Это верно. Исследованиями подтвержден тот факт, что в целом для человека благосостояние в абсолютном масштабе имеет меньшее значение нежели в относительном (грубо говоря, если все живут плохо и бедно, для ощущения благосостояния достаточно жить лишь чуть менее плохо и бедно).
Это тоже верно. Но представьте себе ситуацию. Вот есть у нас гипотетический разработчик, зарабатывающий ну скажем $100K в год, за вычетом налогов ну условно $75K, то есть $6250 в месяц Если им поднимум зарплату на 10%, что немало, он будет зарабатывать на $625 в месяц больше — что в целом уже не очень ощутимо, потому что им и до этого хватало. Ну сможет купить машину подороже, но и текущая машина вполне себе пристойная. В магазин будут ходить все тот же, потому что он рядом а более крутой, дорогой — дальше. Дети будут ходить в ту же школу потому что все вроде бы нормально.
Ситуация меняется радикально, если им на что-то не хватает — например, хочет человек купить дом, и понимают что ипотеку ну не тянут они сейчас. Здесь эти деньги сыграют — но если и дом уже есть, и платежи вменяемые, удельная ценность этих несчастных шестисот баксов сильно падает.
Я не говорю о том, что не надо платить больше — надо. Но в какой-то момент чисто деньги как мотивационный инструмент начинают давать сбои.
Интересен источник — с удовольствием бы прочитал!
ммм… все не так просто и однозначно.
Во-первых, давайте сразу примем как факт: разные люди требуют разного подхода к мотивации, и это функция времени/ситуации. Для кого-то это действительно деньги — по крайней мере, до какого-то уровня. По достижению определенного дохода +$nK ничего не меняет в глобальной картине мира человека, потому что ему хватало раньше, и хватает теперь. На первую позицию выходят более высокоуровневые факторы (например, интерес задачи, признание и т.п.). Классическая пирамида Маслоу, несмотря на всю критику, продолжает оставаться удовлетворительной апроксимацией. Так что можно сказать что мотивация деньгами краткосрочна, но все зависит от человека, ситуации в которой он находится, и что он ставит на первое место в этот момент времени.