Здравствуйте.

Тут некто GERGELY OROSZ написал 4 любопытных блогозаписи про эпоху низких банковских ставок в Зап. мире, особенно в США,
соотв. конец это эпохи и как это все отразилось на софте и индустрии. Часть тезисов у него в платном блоге, но и то
что есть очень и очень любопытно.

Он разбил все на 4 части:

1)The end of 0% interest rates: what it means for tech startups and the industry
В этой записи в основном общий обзор для компаний и стартапов

	часть 1
	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.

2)The end of 0% interest rates: what the new normal means for software engineers
Тут уже как это коснется разработчиков, уже касается -- сокращения и проч.
Краткие тезисы -- пахать придется больше, сложнее стало войти в ИТ, конкуренция выросла, сложнее двигаться
по карьерной лестнице.

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.

3)The end of 0% interest rates: what the new normal means for engineering managers and tech leads

У менеджеров совсем беда -- чуть ли не заставляют писать код или вообще стараются от них избавиться.

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.

4)https://newsletter.pragmaticengineer.com/p/zirp-engineering-practices

Ну и самое интересное, как все это повлияет на софт и практики, вплоть до архитектуры. Т.е. уход от микросерисов в пользу
монолитов, т.к. людей меньше, рост не такой быстрый, да и не факт, что стартап взлетит. Соотв. зачем все заранее усложнять.
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.