When they said I was a programmer I worked daily in 2 languages while I knew to varying levels about 5. I used printed manuals since that was all I had available, no google, no web, the index was your friend and remembering was faster. Then they labeled me a developer, I was working daily in about 4 languages and knew many more. The web was just beginning so it still wasn't much use and there was still books and man. Now I am an architect, there are no printed manuals. I can be working at any time in any of around 10 languages. I now realize that all languages are basically the same, except for prolog. Now I think more along "I want to do foo, I have to use language bar, how do I do foo in bar?" Somewhere out on the web somebody has probably done foo in bar or at least something close enough to figure out the rest of the way. I use a calculator for bit masks over 8 bits, I use a regex tool rather than stare at the ceiling. I spend a lot more time thinking about how to make the resulting code/arch understandable to the next person who has to look at it. There are better things to do with my memory and time than tracking the various shiny objects in the field, knowing that I need to do foo is more important. I use the term software engineer to describe myself to people who ask but won't understand. In my head I am just a person that fixes things.

I prefer some variation on yyyy-MMM-dd, although for some cultures it may be yyyyy-MMM-dd or even yyyyyy-MMM-dd. But that's because I like easy sorting, something that is easy to do with a computer but not so easy in a paper ledger. If you know that the application is going to be used on a system that supplies a default date formater, always use that. If the user doesn't have it set to what they like at least it will be consistent with most of the other software the user uses. Or you can work in an industry that specifies the format that everybody has to follow. In my case that is ddMMMyy or ddMMMyyyy both of which are pain to sort if all you have is text. :( But to answer the question... It depends. For a legacy UI that you don't have time/budget/permission to recode and regression test, stay with the same format of data display. Changing it for your piece will generate user irritation because it is different, or will make them irritated with the older portion because it's not as nice as the new part. For new code, use system defaults. Maybe add a section to documentation about setting the system date. Of course that has it's pitfalls as well.

They need to teach problem solving. The problem with most ways of teaching problem solving is grading the solution. The solution to that problem is use mathematics, it's easy to grade and it's easy to come up with problems to solve. I've used mathematics when the problem domain requires it, otherwise not so much. Not that I had too but I took, and passed, 2 years of calculus and 1 year of calculus based physics. The most useful courses I took, outside of CS, were the anthropology courses. :)

Collin Jasnoch wrote:

Now if a developer can not figure out what
 
SomeRandomCollection.ForEach(item => {//Do stuff}); means then I do not want them working in my code base anyways.

If you are working for someone else it it this attitude that causes the most grief for the business. Which is the situation that the OP is in. In this case it is not your code base, you have no control over who sees it next, and you will collect bad karma as those who follow will curse your name. :)

Always. The next programmer to look at it will be yourself. Why make that future self curse you?

The language is irrelevant, whenever I've started someplace new there has always been a good supply of WTF in the source base whether it is perl, c, pascal, C#, VB, COBOL, x86 asm, Java, c++, etc, etc. First you have to decipher the mind set of those that came before, then all becomes clear. Long walks muttering to yourself also help. :)

For C#, VS although I hate the way it intrudes with it's 'helpful' hints about what it thinks you want to do. For everything else, Codewright, which has been EOL'd for years but still works best for digging through code.

First off, unless you are writing in microcode, maybe even picocode, you haven't been writing 'native' code. If the oldest CPU you wrote assembler for was the 8086 you probably haven't written 'native' code. If you are writing code for the Win32/64 system you haven't been writing to the 'system', you've been targeting OS level APIs that have been working with the system. Expect to see more languages that target a virtual processor, it's the only way to have a chance of getting a single binary to work under multiple OSes. Most of the popular web languages target a 'virtual processor', consider perl, javascript, PHP(?), those are 'interpreted' languages. C#, Java, UCSD P-System, many BASICs, all run on a 'virtual' processor, they could be called interpreters as well. The native vs. non-native binaries is a non-issue unless your doing embedded work, even your C compiler isn't targeting the metal. Yes, you can say 'but I'm closer to the metal' but the better interpreters use JIT compiling to get better performance. Eventually the difference between the JIT and pre-compiled will be nil. So the answer as I see it is, marketing. Of course it helps that MS bought the guy who designed Delphi away from Borland to design C#. Properties were a pain to implement in C++. :-D

I hates it. Hate, hate, hates it. It is the tool tip that insists on popping up when the mouse hovers over most items in the Source Window. For C++ there is an option to turn it off but I have not been able to turn it off for C#. I don't need to know that the mouse is over a string! ArrgHHH!!

I would caution against using the SP1 for VS 2008 if you are trying to debug large multi-threaded/multi-appdomain applications. It will stop at your first break point and then ignore the rest. Most frustrating, we had to drop VS 2008+SP1 and reinstall VS 2008 to clean it up.