[rs23296008n1]

Usually poorly performant code needs optimisation through a change of approach or mindset. It is the way we are thinking about the problem that is lowering performance. Not necessarily the hardware itself.

I've seen locking brought forward as a critical limit. Long discussions about new hardware and adding nodes and all sorts of expenditure required. We need a larger kubernetes. More GPUs!

I've also been in the situation where we switched to a plain redis queue (LPOP, RPUSH) scheme and gotten 10x the improvement just by lowering message overhead. A lot of the very complex solutions require so much processing power overhead simply because they involve wading through gigabytes. Better alternative solutions involve less gigabytes. Same hardware, different mindset. Not even talking about assembly language or other forms of optimisation being required. Just different philosophy and different methodology.

Perhaps we need programmers with the mental flexibility to run experiments and be open to alternatives. (Spoiler: we've already got plenty of these people.)

[pdimitar]

We have a good number of them indeed but nobody wants to pay them to fix most of the IT area. Ironic, right.

[rs23296008n1]

Or we can't get them past the HR hiring policies that eliminate all candidates. Been through that myself. I even got multiple tech leads to sit the testing and watched them fail. They were already on the team yet would not be able to get on the team. Absurd but true.

Contracting is such a strange world. I've drifted so far into it I've lost the ability to see how salary based people even get work. All I can do is keep the door open for as many people as possible. Sometimes I need to actually assert the door into existence. This was something I didn't know was possible until recently.

[pdimitar]

Can you tell me more? Sounds quite humorous. And quite usual...