Тут некто GERGELY OROSZ написал 4 любопытных блогозаписи про эпоху низких банковских ставок в Зап. мире, особенно в США,
соотв. конец это эпохи и как это все отразилось на софте и индустрии. Часть тезисов у него в платном блоге, но и то
что есть очень и очень любопытно.
What is ZIRP? And why were there close to zero interest rates globally, for so long?
What post-ZIRP means for venture capital. When low-risk investments like government bonds deliver better returns, it’s harder for startups to raise money.
Publicly traded companies and Big Tech. Lower company valuations, pressure to become profitable – and Big Tech excelling.
Late-stage startups. Post-ZIRP, it’s much harder to raise new funding, fewer IPOs, and other exits. Few options except trying to achieve profitability – even if it means deep cuts.
Early-stage startups. Post-ZIRP, investors expect more at the seed stage, and raising a Series A became very challenging. A low burn rate is table stakes.
Bootstrapped companies. Bootstrapping is back in style in our higher interest-rate world – plus, lessons from bootstrapped companies founded by software engineers are timely.
Are startups really a “low-interest-rate phenomenon?” Some finance professionals claim startups depend on low interest rates. But this thesis can be defeated with data, offering hope for tech innovation in today’s high interest-rate environment.
Job market realities. It’s tougher than it’s been in a decade, with fewer jobs, and more qualified candidates. This is great if you’re hiring, but harder for applicants.
Getting a (new) job as a software engineer. What worked in an “employee’s market,” doesn’t function nearly as well. Suggestions on how to adapt to an employer’s market.
Compensation changes. It’s logical for compensation to stagnate, or go down. But things are a bit more nuanced, considering the trimodal nature of software engineering packages. It’s harder to move “up” a tier now.
Negotiating offers. The advice to negotiate hard doesn’t universally apply in today’s market. You should still negotiate, but tactfully.
У менеджеров совсем беда -- чуть ли не заставляют писать код или вообще стараются от них избавиться.
The trend of fewer engineering managers. Starting about a year ago, more companies have aimed to “flatten” tech organizations, and this means fewer middle managers and line managers.
How the engineering manager career path are changing. Managers take on more responsiblites, the job’s harder than before, and a tougher market for line manager EMs who don’t want to (or cannot) code.
The rise of the tech lead role. For years, line managers had good reasons to stay hands-off, but this is changing. The “player coach” role could well make a comeback, and tech leads could replace engineering manager roles in some companies. There are tradeoffs to this that organizations would have to manage, of course.
Improving job security, as an EM. Becoming more hands-on, strengthening your network and being aware on how tenure is becoming more relevant.
Opportunities these changes bring. ICs with manager experiences likely to be preferred for staff+ positions, the opportunity to build more cohesive teams and the pendulum eventually swinging back.
Ну и самое интересное, как все это повлияет на софт и практики, вплоть до архитектуры. Т.е. уход от микросерисов в пользу
монолитов, т.к. людей меньше, рост не такой быстрый, да и не факт, что стартап взлетит. Соотв. зачем все заранее усложнять.
Full-stack разработчики на вес золота. Более простые и прагматичные арх-ры. В общем, эпоха SkyDance'а.
Monoliths favored over microservices? Microservices are a great tool to prepare for hypergrowth in headcount. But do we even need them when growth is slow, or perhaps even negative?
Full-stack and cross-platform push. Engineering teams where with full-stack engineers, using cross-platform frameworks get the same stuff done with fewer people, with slightly less polish. That “less polish” is harder to notice: but the smaller team size means faster iteration and lower overall cost that are both harder to ignore.
Pragmatic, simpler architecture. During ZIRP, it made sense to solve problems the engineering team doesn’t yet have, but will have in 6-12 months. With ZIRP behind us, this could be a more wasteful approach. Why not solve architecture issues when teams feel the pain of the current architecture slowing things down too much?
More responsibilities “shift left.” Developers end up taking on more responsibilities on DevOps, security, infra and platforms. All this comes with better tools to be able to manage all this – and, at larger companies, centralized security and platform teams supporting engineers.
Buy vs build vs use open source. Building non-core tools in-house will make much less sense, when looking at the numbers – especially if Section 174 tax changes stay in place. A more common question will be to buy from a vendor, or operate an open source solution instead?
Commercial backing for the most popular open source projects. The open source field will almost certainly shift: community funded open source projects could see fewer companies contributing, while some of the widely used – and well-supported – open source projects will likely see licenses become more restrictive.
Other industry observations. Less focus whether engineers enjoy working on a project; serving sales teams becomes more important; less tech debt and more business priorities focus, amongst others.
Пару цитат оттуда:
“We still have around ~2,000 services to take care of, even though we now have less than 2/3rds of the engineers we had in 2021, when we built all of these! We recently told leadership: “We don’t have enough people to even operate these services: we need to hire more.” The response has been: “Sort it. Maybe use AI?”
“I believe ZIRP led to a lot of overcomplicated tech architectures; byzantine microservice architectures and multiple databases, where a simple monolith with PostgreSQL as a database would have been enough. It inevitably led to unsustainable headcount in engineering departments as well. I expect this excess to reduce by a lot.“
“I see a change in developers around me, who’ve started to talk a lot more about pragmatic and efficient architectures, and a lot less about ‘best’ tools for the job.”
Architecting to solve a current pain point could become more common. During times of fast growth, it makes a ton of sense to design systems for future expected loads, even if they fail to materialize.
Кодом людям нужно помогать!
Re: Влияние эпохи 0% ставок(ZIRP) на софт и индустрию ИТ в ц
С этой фигней можно было просто пилить проект в кредит годами без реальных клиентов, а потом продать его крупной конторе. Позволялораздувать стоимость акций и выплачивать большие бонусы помимо зп . Ни первое ни второе в России не распространено, так что русских это вообще не коснется в мире подсократится количество стартапов без внятной финансовой модели (жалко) и количество вакансий где можно получить по мильону баксов в акциях, остальное мало поменяется (во время пандемии мой знакомый обычный программист американский получил оффер от stripe на 4 млн долларов в акциях помимо зп)
Здравствуйте, __kot2, Вы писали:
__>(во время пандемии мой знакомый обычный программист американский получил оффер от stripe на 4 млн долларов в акциях помимо зп)
Значит не такой уж и обычный. Его еще не сократили?
Кодом людям нужно помогать!
Re: Влияние эпохи 0% ставок(ZIRP) на софт и индустрию ИТ в целом.
On May 15, 2024, 8:47 PM, Sharov <79401@users.rsdn.org> wrote:
В целом все логично. И что касается первых трех частей плюс-минус верно. У меня замечание к четвертой части — относительно его прогноза модели будущего. Надо понимать мотив автора, побудивший его к написанию этого чтива. Это может быть графоманство или это может быть связано с его недавнему переходу к консультации компаний с реинженирингом процессов. Какая бы ни была его конечная цель — по всей видимости его прогноз базируется на его старом опыте и прошлом кризисе. На мой скромный взгляд, это не так работает, вот тезисно его утверждения и мои замечания по каждому пункту:
Monoliths favored over microservices? Microservices are a great tool to prepare for hypergrowth in headcount. But do we even need them when growth is slow, or perhaps even negative?
Возврат к монолитам исключен. Монолит действительно ведет к меньшей стоимости, но на ранней стадии. На практике это приведет к еще большему удорожанию на пустом месте (переписывать тонны кода потребует огромных бюджетов и времени). Я думаю будет по другому, микросервисы теперь все больше будут поддерживать функцию горизонтального масштабирования. Таким образом, сервисный каскад будет удешевляться за счет масштабирования сервисных узлов (на слабом дешевом железе), а не превращения их в монолиты. Более предпочтительно здесь переход на условно бесплатные варианты, но об этом ниже.
Full-stack and cross-platform push. Engineering teams where with full-stack engineers, using cross-platform frameworks get the same stuff done with fewer people, with slightly less polish. That «less polish» is harder to notice: but the smaller team size means faster iteration and lower overall cost that are both harder to ignore.
На мой взгляд здесь есть заблуждение у автора. Это не ведет к «кросс-платформенности» это ведет к уходу от платформы А к платформе Б. Всего лишь. Зачем поддерживать платформу А, если цена поддержки ее (на ней) превысит все адекватные рамки? Ну кто будет сидет на кросплатформенной «сфере» или «корбе» (извините, вырвалось). Итого, мой прогноз в этой части — вообще не будет изменений, таким образом — «игры будут делаться под Windows», бэки как и делались (на той же технологии что и раньше).
Pragmatic, simpler architecture. During ZIRP, it made sense to solve problems the engineering team doesn’t yet have, but will have in 6–12 months. With ZIRP behind us, this could be a more wasteful approach. Why not solve architecture issues when teams feel the pain of the current architecture slowing things down too much?
Здесь пропущу, ибо не совсем понял что он имел ввиду. Видимо, у автора был опыт с какой-то локальной болью о которой известно только автору.
More responsibilities «shift left.» Developers end up taking on more responsibilities on DevOps, security, infra and platforms. All this comes with better tools to be able to manage all this – and, at larger companies, centralized security and platform teams supporting engineers.
Выглядит логично, что автор предполагает уменьшение стоимости за счет укрупнения ролей, на практике же, увы, этого никогда не происходит — мешает этому уменьшение качества продуктовых поставок и соблюдение Vier-Augen-Prinzip. То есть уменьшив расходную часть на укрупнении ролей, вопреки благим намерениям автора увеличиваются издержки при поставках и в соблюдении регуляторных правил. Об этом ниже.
Buy vs build vs use open source. Building non-core tools in-house will make much less sense, when looking at the numbers – especially if Section 174 tax changes stay in place. A more common question will be to buy from a vendor, or operate an open source solution instead?
Речь идет об этом: «До вступления в силу TCJA предприятия вычитали общую сумму расходов на НИОКР как расход в налогооблагаемом году. Начиная с 2022 года, все затраты на НИОКР теперь должны амортизироваться в течение пяти лет для компаний из США и 15 лет для компаний из других стран». Эта история релевантна только для стартапов из США. PS. Видимо налоговиков США задолбали суммы «расходняка» на «инновации»
Commercial backing for the most popular open source projects. The open source field will almost certainly shift: community funded open source projects could see fewer companies contributing, while some of the widely used – and well-supported – open source projects will likely see licenses become more restrictive.
С этим утверждением в целом согласен — уже сейчас это происходит. Единственное, что будет еще «отскок». Потому что в какой-то момент отрицательный эффект перевести положительный эффект от этого.
Other industry observations. Less focus whether engineers enjoy working on a project; serving sales teams becomes more important; less tech debt and more business priorities focus, amongst others.
Тут он снова, видимо, вспоминает кризисные ситуации прошлых лет — ну да, возможно, так и будет. Но это будет географически локально, не факт что это могут быть только проблемы рынка условной Калифорнии, а допустим на всоточном побережье этого не будет.
⸻ ❧ “Courage is like a muscle. We strengthen it by use.” — Ruth Gordo
Re: Влияние эпохи 0% ставок(ZIRP) на софт и индустрию ИТ в целом.
S>Ну и самое интересное, как все это повлияет на софт и практики, вплоть до архитектуры. Т.е. уход от микросерисов в пользу S>монолитов, т.к. людей меньше, рост не такой быстрый, да и не факт, что стартап взлетит. Соотв. зачем все заранее усложнять. S>Full-stack разработчики на вес золота. Более простые и прагматичные арх-ры. В общем, эпоха SkyDance'а.
Оно так всегда было, простые и прагматичные архитектуры всегда выигрывали.
Другое дело что в эпоху бесплатных денег "макароны" могли выжить за счет этого самого безудержного роста поголовья программистов.
А виток спирали от микросервисов к монолиту идет уже некоторое время, в первую очередь с концепцией "monorepo/megarepo".
Re[3]: Влияние эпохи 0% ставок(ZIRP) на софт и индустрию ИТ в ц
Здравствуйте, Sharov, Вы писали: __>>(во время пандемии мой знакомый обычный программист американский получил оффер от stripe на 4 млн долларов в акциях помимо зп)
S>Значит не такой уж и обычный. Его еще не сократили?
Давно про него ничего не слышал. Я с ним работал и общался несколько лет, есть много общих знакомых — чисто как программист он такой крепкий середнячок с карьерными удачами и неудачами. Вот да, таким давали такие офферы
Re[4]: Влияние эпохи 0% ставок(ZIRP) на софт и индустрию ИТ в ц
S>“We still have around ~2,000 services to take care of, even though we now have less than 2/3rds of the engineers we had in 2021, when we built all of these! We recently told leadership: “We don’t have enough people to even operate these services: we need to hire more.” The response has been: “Sort it. Maybe use AI?”
Как же меня задолбали эти качели. Микросервисы- все как бараны побежали "переписывать на микросервисы", когда я спрашивал "а на #уа?" мне говорили "молчи ты ничего непонимаешь". Теперь людей в 3-4 раза меньше — те же люди говорят "это было ошибкой вводить микросервисы. Мы будем пилить и добавлять фичи в монолит, но оставим микросервисы,". Теперь все как бараны побежали в AI, но с стороны юзеров, вообще не понимают, что это auto-encoder- т.е. средство для компактного представления информации и поиска по нему, типа такой индекс. Да блин, "оно само" пишет код, ага- оно ищет по базе знаний, собранной из написанного кожаными мешками кода. Если кожаные мешки перестанут писать код сами- то и база данных застынет в нынешнем состоянии.
Re[2]: Влияние эпохи 0% ставок(ZIRP) на софт и индустрию ИТ в целом.
Здравствуйте, Артём, Вы писали:
Аё>Как же меня задолбали эти качели. Микросервисы- все как бараны побежали "переписывать на микросервисы", когда я спрашивал "а на #уа?" мне говорили "молчи ты ничего непонимаешь". Теперь людей в 3-4 раза меньше — те же люди говорят "это было ошибкой вводить микросервисы. Мы будем пилить и добавлять фичи в монолит, но оставим микросервисы,". Теперь все как бараны побежали в AI, но с стороны юзеров, вообще не понимают, что это auto-encoder- т.е. средство для компактного представления информации и поиска по нему, типа такой индекс. Да блин, "оно само" пишет код, ага- оно ищет по базе знаний, собранной из написанного кожаными мешками кода. Если кожаные мешки перестанут писать код сами- то и база данных застынет в нынешнем состоянии.
Преимущества микросервисного подхода — в основном организационные.
Когда 10 человек сервис пишет и функционала немного — делай что хочешь.
А когда от 100 — типичная ситуация что мы не можем зарелизится 2 месяца (при обычной каденции в 'два раза в неделю') потому что то одно сломается, то другое.
Приходится вводить код фризы, стабилизировать сервис, с большими рисками это выкатывать, потом откатывать потому что резиз что-то поломал, и тд.
А потом через месяц все заново повторяется.
С микросервисами каждая команда может независимо от других релизить свои фичи.
Re[3]: Влияние эпохи 0% ставок(ZIRP) на софт и индустрию ИТ в целом.
Здравствуйте, umnik, Вы писали:
U>А когда от 100 — типичная ситуация что мы не можем зарелизится 2 месяца (при обычной каденции в 'два раза в неделю') потому что то одно сломается, то другое.
Давно изобрели gitflow и стабилизационную модель разработки, когда готова фича едет в интеграционную ветку, там сливается с другими фичами, тестируется, допиливается и едет на прод. Остальные разработчики при этом вполне могут работать на интеграцией фич уже в новый релиз. В случае фатальных проблем откатывается релиз целиком. Но если в проекте нормально организованно тестирование, фатальных проблем почти никогда не бывает.
U>С микросервисами каждая команда может независимо от других релизить свои фичи.
Как правило, фичи приносят ценность не сами по себе, а в интеграции с другими фичами. Т.е. в любом случае приходится ждать пока смежники допилят свою часть, а потом интегрироваться с ними. И точно также с откатами, мало откатить проблемный сервис, нужно еще откатить все сервисы, которые от него зависят. Причем получившаяся в результате отката конфигурация должна быть работоспособна, т.е. именно эта конфигурация должна быть протестирована.
Re[2]: Влияние эпохи 0% ставок(ZIRP) на софт и индустрию ИТ в целом.
Здравствуйте, SkyDance, Вы писали:
SD>А виток спирали от микросервисов к монолиту идет уже некоторое время, в первую очередь с концепцией "monorepo/megarepo".
А где это заметно? Яндекс и Микрософт вроде всегда предпочитали mega-megarepo.
Re[2]: Влияние эпохи 0% ставок(ZIRP) на софт и индустрию ИТ в целом.
Здравствуйте, Артём, Вы писали:
Аё>Как же меня задолбали эти качели. Микросервисы- все как бараны побежали "переписывать на микросервисы", когда я спрашивал "а на #уа?" мне говорили "молчи ты ничего непонимаешь".
Это, скорее всего, проблема менеджмента и руководства, которые всегда верят в сказки, что просто применив что-то можно увеличить продуктивность в N раз, и продавливают внедрение.
А так, да, микросервисы это просто архитектурный инструмент, который, в общем-то, был всегда.
в мире подсократится количество стартапов без внятной финансовой модели (жалко) и количество вакансий где можно получить по мильону баксов в акциях, остальное мало поменяется (во время пандемии мой знакомый обычный программист американский получил оффер от stripe на 4 млн долларов в акциях помимо зп)
