dkrikun

so true, made my day

winlister for me. It is like process explorer for windows. When you develop something window related and you have no idea where is a window -- winlister can tell you whether it is hidden, or maybe have left-top out of the monitor

try reflex arena

Question: how relevant is this with the serverless? Don't cloud providers provide also these kind of tools?

This is a good advice, but I feel to add a few points of mine:

1. the author says "premature optmization", and it has the right context, however I prefer to use "premature abstraction" or even "speculative generalization".

2. YAGNI and DRY can be counter-principles because at times "you aint gonna need that level of abstraction/genericity".

3. Inadequately abstract and generic code hurts simplicity and readability.

I did and I know the author says "actually it is a terrible advise" but he also continues to soften his statement

Could not disagree more. The author most probably freed the company from its dysfunctional stagnation due to some political issue. It is thanks to his ignorance that he resolved an issue, something that had to be done.

In general, staying out of other people code is a bad idea. It promotes lack of transparency and agenda proliferation. This is because the owners of the code start being a "monopoly", can work less hard, provide exaggerated estimates etc. When people know that others can read there code, maybe hack on it, make something faster or simpler -- well they work harder and tend to be more transparent.

"Great advice if you want a miserable 40 year career as a team player in mind numbing corporate work prevention departments"

This

It is mainly a matter of decision making. In my case, no refactoring was ever sanctioned by itself. Devs were having been allowed to refactor anything on a small scale and always backed up by a feature request. So when the desire to somehow "heal" the codebase is met, it is usually because it is already too "dead" to work with in the first place.

Yes most of these things are terrible

Yeah, I just tried to be on the more "permissive" side of things. Though per-library errno is being used (zeromq, libuv).

It is unpopular opinion, but not all code can be cost-effectively validated by unittests at all. I have been maintaining codebases where the customer would come and change his requirements on a weekly basis. While I could set up unittests to validate the code that implemented these requirements, doing so would demand significantly more effort than the code itself. I'm talking about some 3d graphics, game logic code. Instead setting up a simple ui (with imgui) to play with the state of the game scene provided much more confidence per man hour.