You're dealing with millions of dollars, on behalf of your customers. And if you're handling transactions for multiple brokers, that can easily be hundreds of millions of dollars. It's common in the financial processing sector that customers: * will not accept the latest version of your software without THEIR testing. * will demand full accountability when errors or problems occur - with detailed tracking & auditting * will switch away to another processing firm if you're not cost-competitive or reliable * your customers are often your competitors It's been this way for years. As someone else said, you don't have to give them the full internal description of the problem. But you should be honest and state the basic problem and that it was fixed. Unless you have an ongoing reliability or performance problem, your reputation won't be ruined. All of the financial processing (firms) fuck up once in awhile.

You are SO optimistic. Non-technical managers or management have no idea who's good or not, how much they produce or not.

Accounting / Order software - didn't have the logic for tax calculations in CA. Stubbed the code with a "todo comment". Forgot about it... time for QA. California too busy to send us test data. Six months later, the company realized that it had "forgotten" to collect $450,000 in sales tax. Financial trading software. One simple routine to convert an alphanumeric string to an integer. Tested by programmers, QA and customers for over 6 months. ONE customer sends the strings with fractions, "10.0". All other customers send the strings as integers, "10". The new version goes live, and that one customer has immediate problems (10.0 was being converted to 100). After 3 hours of waffling and hand-ringing, management decides to shut down the entire system rather than just the one customer. System was restarted, but all customers automatically switched to other firm's trading systems. By the time customers started using our software again... dunno, must have been millions of dollars in lost revenue. Shit happens, and then you get on with life.

One of the Mars landers had a fairly famous bug - one portion of the code in metric, the other portion in English units. Costs? Must have been in tens of millions. Another case of medical diagnostic machine that had buggy software (CAT scanner? or something similar?) The bug killed three people. "Cost" was in millions.

Well in my part of the world, you can't find a Windows C++ job in either servers or desktops. If it's even required, it's an afterthought for maintaining legacy code while you work in C# and .Net. 98% of the jobs I see listed for C++ are on Linux. So as far as I am concerned, Microsoft killed the whole C++ and Server development market for their products. There are some server positions for C#, but again what I see posted is well over 90% C++ and Java on Linux.

If you're using C++, I would stick with VS2008. I have VS2010 installed on several computers, Vista and Win7 - The help system isn't as good as VS2008 (ymmv) The IDE freezes at times. The IDE crashes fairly often. Intellisense is broken most of the time. Source browsing/references (ie jump to declaration or definition) often doesn't work. Some of the C++00x features aren't implemented in VS2010 anyway.

Well, I'm not an ISV but my personal feeling is that MS has given up on the small developer, and Windows "native" development. My personal observation is most "native" work is being done with Linux, and anyone who wants to do "native C++" doesn't have much of a choice except to migrate away from Windows. History: SCO Unix and then USL sold "desktop Unix" licenses for $800 per computer; everyone quickly migrated to Windows 3.1 which cost $30. IBM had OS/2 (again, at $800 and over per computer) and when Windows NT appeared, there was a fairly rapid migration to Windows NT (cost under $100 at that time.) Now MS Windows desktop lists for $200 to $400. Hmmm where is the market going to go?

In Visual C++ MFC, there's a CString. And to check if a CString has values, it's "if (!str.IsEmpty()). So the QA person, who had a degree from Stevens Institute of Technology, sat there and argued with me for 2 HOURS, and brought it all the way up to the VP, because it wasn't the "obvious way to do the logical operation." Didn't matter at all that is was the way Microsoft implemented it, and we had to use it.

I was reading something several weeks back that implied, with age, most people make more correct decisions (probably due to experience) than younger people with the same skill sets.

That has been the law in many US states for decades. NJ for example has had that law for 20+ years - a hospital emergency room can NOT turn away anyone for inability to pay. That's to prevent those nasty little issues where a hospital ER refuses treatment and leaves people to die on the sidewalk (and that has happened).... which was why the law was created in the first place. The result here in NJ of course has been increased medical costs for those who can pay. So as a society we have two choices: allow people to go untreated or pay higher medical fees either directly to the user or from taxes or other government funding. What's your choice? If you were out of a job for 6 months, no medical insurance, and it was your kid with a broken arm and 105 degree fever, what would you choose then?

Well I actually do tend to comment what the function does, ie, "FindCustomerName". But I think the reason was why a particular algorithm was used... which depends upon the complexity of the requirements and the implementation of the logic. // Find object by using custom mapping routine that locks nodes into memory. // This custom map does not need locking for existing items and multi-thread use. // Tested as fastest method and avoids double de-reference of pointer to get to the actual data. program logic blah blah blah // object was not found, must lock here and retry search. program logic blah blah blah // object still not found, create it and add it to the map while we're locked.

One of the comments that I remember (from an article about comments), is that experienced programmers don't always comment what a section of code does, but it was a very good practise to explain why the section was coded that way. Explaining why a particular algoritm was used was more useful than explaining how the algoritm worked.