You chose to invest in the downward career slope. That’s why your opinion has changed. If you continued to resist it you wouldn’t be looking to remove yourself from the auditing/coding position.
I'm not sure that's much of an achievement, to be honest. If you tried it and it turned out to be not useful for you, fine, I'm on your side. But refusing to try for the sake of it seems backwards. I mean, then why use CI, version control and those fancy IDEs anyway? Notepad is a perfectly cromulent text editor (and what is code, if not text, anyway?) and my local build.bat and deploy.bat do their job nicely and quickly.
> - Redistribution of wealth
We can talk about excessively wealthy individuals all day, but I'm pretty sure that most knowledge workers are not going to be on the receiving side of wealth redistribution. This is even more likely to be true for the programmers affected by these tech layoffs.
This is really just a cheap rhetorical trick. Linux [0] can run just as much software, if you include VMs, but you can't legally virtualize MacOS, therefore buying a Mac is the only way to legally run their software, in addition to everything else. Now, you are technically correct, but the casual interpretation of
> Eh, macOS is still the UNIX with the most commercial software available.
isn't really that you can simply run everything unavailable on MacOS in a VM (or several layers of VMs). It's the same as arguing that Powerpoint is all you ever need, as it is Turing complete.
[0] And so can Windows, if you run said VMs in a Linux VM.
Dead Comment
It might, but in this case it is preceded by "This is why", which makes the sentence as a whole simply wrong.
This is quite dependent on the games you play. Modern games are becoming larger, which makes the project overall more serious and makes it harder to hide easter eggs. That being said, Indie games with small teams still contain a lot of fun and even AAAs can still contain some goodies.
I don't think this applies in most situations. If you have been part of the original core team and are rewriting the app in the same way, this might be true - basically a lost code situation, like the author was in.
However, if you are doing so because you lack understanding of the original code or you are switching the stack, you will inevitably find new obstacles and repeat mistakes that were fixed in the original prototype. Also, in a real world situation, you probably also have to handle fun things like data import/migration, upgrading production instances and serving customers (and possibly fixing bugs) while having your rewrite as a side project. I'm not saying that a rewrite is never the answer, but the authors situation was pretty unique.
Plus, we're most likely talking about Gigabit networking here, so unless your workload consists of very parallel random access, this is going to be the limiting factor anyway.