Yea, in the company I work in (entire country it seems tbh) - it's exceedingly rare for contributers to get a raise over a certain point. If I want to increase my income I kinda have to go into management.

I'm sure there are outliers, but this seems to be the norm.

How long would you say it takes to feel the effects after switching? I did this a couple of years ago and as far as I remember the only real effect was my energy levels were more stable.

I gave it maybe 2-3 months and decided it's not worth it.

Tempted to give it another shot!

I think some of the positive effects are very quick (better sleep) whereas others take longer to materialise. My wife commented after maybe 2-3 years that I had become much more organised. I think that happened because I came off caffeine and then adapted over time to having a different brain chemistry, so I learned techniques to organise myself that I wouldn't have stuck to had I carried on consuming caffeine.

Was in a company that didn't promote engineers (never saw this happen), only hired managers externally. Resulted in a management layer clueless about the work and product.

Good management is rare.

Good management is rare partly because nobody wants to take risks and hire inexperienced management.

This leads to a reluctance to promote people without previous experience into management roles. This in turn leads to a shortage of experienced managers.

Good management is rare because it's the wrong people doing it. The bigger problem is that we're all always told that we need "professional" management, implicitly people who's been to "management" schools, this dissuades promoting from within (that honestly can be equally disastrous).

The upside of people from within is that they know what the bottom line comes from, there's been some highlighting of the effects in terms of the founder-mode discussions.

https://paulgraham.com/foundermode.html

> In other words, if you want 10% of your savings to be in X, and they do a dividend, then you have to take the cash and buy shares of X.

Wouldn't the inverse of this be true in buybacks though? If it's economically equivalent then buyback should increase the price and similarly increase the proportion of X in your portfolio - which would force you to rebalance (might have tax implications).

Generally agree with the main point.

Another fun one is when sales has already sold the thing to the customer without there being a product to sell. At that point it stops being about trust it's just "get it out there".

I hate this, but seems to be fairly normal practice.

I'm reminded of an effect called Gell-Mann Amnesia.

When reading news stories on topics you know well, you notice inaccuracies or poor reporting - but then immediately forget that lesson when reading the next article on a topic you are not familiar with.

It's very similar to what happens with AI.

I absolutely love programming. I enjoy creating software, trying out new languages and systems, creating games during my free time.

And I also might "vibe code" when I need to add another endpoint on a deadline to earn a living. To be fair - I review and test the code so not sure it's really vibe coding.

For me it's not that binary.

In a fresh project that is well documented and set up it might work better. Many issues that Agents have in my work is that the endpoints are not always documented correctly.

Real example that happened to me, Agent forgets to rename an expected parameter in API spec for service 1. Now when working on service 2, there is no other way of finding this mistake for the Agent than to give it access to service 1. And now you are back to "... effect of context size on agent performance ...". For context, we might have ~100 services.

One could argue these issues reduce over time as instruction files are updated etc but that also assumes the models follow instructions and don't hallucinate.

That being said, I do use Agents quite successfully now - but I have to guide them a bit more than some care to admit.

> In a fresh project that is well documented and set up it might work better.

I guess this may be dependent on domain, language, codebase, or soke combination of the 3. The biggest issues I've had with agents is when they go down the wrong path and it snowballs from there. Suddenly they are loading more context unrelated to the tasks and getting more confused. Documenting interfaces doesn't help if the source is available to the agent.

My agentic sweet spot is human-designed interfaces. Agents cannot mess up code they don't have access to, e.g. by inadvertently changing the interface contract and the implementation.

> Agent forgets to rename an expected parameter in API spec for service 1

Document and test your interfaces/logic boundaries! I have witnessed this break many times with human teams with field renames, change in optionality, undocumented field dependencies, etc, there are challenging trade-offs with API versioning. Agents can't fix process issues.

And there are different contexts.

In reality there are tons of tasks at work that are boring and time constrained. There are days I don't enjoy it, and days I do. It's not binary - I still love programming by hand but at times I let Agents work whilst reviewing the results.