Even worse is when they don't wrap the original exception in the new exception, but throw away any knowledge of the error.

Neither Windows nor Linux do well when putting too many files in a single folder. I've tried it with a million files, it is very painful. Some operations, like simply listing the directory, or even trying to delete the files take absurdly long. It seems to be doing some operations that are simply not designed for large numbers of files. Like said, around 10,000 files in a folder is a reasonable max. I simply make it 1,000. So for a million files, spread them across 1,000 folders. There is a nice symmetry here, and it works like a charm.

Ah, the joys of treating estimates as deadlines. My advice, don't ever succumb to the management pressure of decreasing your estimates to fit their schedule. Never, ever works. Second, since everything takes longer than you guess, practice inflating your estimates until they actually seem to predict the time it takes. You can actually get good at this with practice. Good management greatly prefer accurate estimates than low-ball estimates that never make schedule. Third, don't accept any tasks/work that anyone, even the janitor, has said out loud, "that's easy". If you get it done on time, no credit because it was easy. If you are late, you must be a bad developer because you couldn't deliver something easy on time. Fourth, if you are ever in a meeting and asked for an estimate, but another manager/developer gives a lower estimate, make them do the work! No matter how much they claim they are too busy to do it. Lowest estimate wins the work. Trust me on this one. Cheers

I love interfaces, but the problem isn't interfaces, it's that any good thing can be use wrongly/badly/ugily ;) So just because it can be done badly, doesn't mean it's bad. I've had colleagues that would never write a class in c# without a corresponding interface, most of which were never actually used for any proper purpose. That's just extra maintenance with zero benefit. And one often sees wrong things put in interfaces, e.g. implementation specific info which makes no sense for other implementations of the interface. And often interfaces contain too many things that should be separated out into multiple interfaces. This I find cool, that I can implement multiple interfaces in a single class.

You would have found that pretty quickly with JetBrains, e.g.

This question has received lots of humorous responses, now for a slightly more serious one ;) Yes, we used to use gotos a lot in the old days (and I'm actually old enough to say that :)). But my feeling now is that any language where I ever feel the need to use a goto is a flawed language. But seriously, the original "Go To Considered Harmful" [https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf\] was a brilliant step in providing discipline to coding to narrow the gap between algorithm design and implementation. A main idea being that gotos break the provability of correctness. Anybody can tell you that extensive use of gotos was involved in large numbers of defects (thus quite costly). One other point I'd like to make is that gotos can interfere with optimizers.

The reason for the results are pretty obvious, when a new instance is created in "CreateNewContext", the parameter "context" is still referring to the original context, not the new one ==> false; When the main program does the compare afterwards, the comparison is done to the static that holds the new context ==> true. Fixing this is not obvious because you didn't specify what the correct behavior should be. Do you wish it to be "True" always, or "False" always :) Simply update the context parameter in the method to get True always, but I would personally recommend to re-write this whole thing, it is full of code smells. Perhaps some practice in TDD would also be helpful. Cheers, Anthony

I was saying that you can use an empty collection with foreach, which will basically do nothing. You shouldn't need anything there.

In your example:

list.WhenNotEmpty()?.ForEach(s => s.Prepare(out var r)?.Manipulate(r));

The WhenNotEmpty()?. isn't really needed, is it?

That is a valid perspective, and further one could say that junior developers need opportunities to learn and not have their hand held too much; and there must be an expectation that developers meet minimum requirements of understanding many aspects of software development. Code reviews are an effective way to share knowledge and help develop junior devs. So, for balance, let's look at the other side. Companies invest in and employ devs to develop software assets. These assets are important to the companies value/revenue/future etc. So naturally, maintainability is a hugely important attribute of company assets. And there are many aspects to maintainability of course. I would say that if someone is asking you to "dumb down" code for easier maintenance, perhaps that is just a diplomatic way of saying that your code is not readable/maintainable. There is an old school rule that when writing code, it should be readable by other people, including yourself at some time in the future. Since I am no expert in LINQ, for example, I will often write code the simple / old way, and when Re-Sharper suggests a conversion to LINQ, I will have Re-Sharper do the conversion, and then decide if it is easier or harder to understand at a glance, and often I will undo the conversion. Complicated or unreadable code is not "better" code. (obviously there is a minimum complexity required for every different problem/algorithm). Well, anyway, I would tell your bosses that any policy that forbids using C# 7 syntax, for example, is a bad policy since every new version of c# provides syntax that is better and/or more maintainable. Cheers, Anthony