Slashdot videos: Now with more Slashdot!
I have found that the overhead of understanding Frameworks generally outweighs their usefulness. I'm sure there are exceptions, but I have not found them yet personally. Many people use frameworks to do things that are absolutely trivial and I just do not get it. Generally, the requirements I see NEVER map to something that's out there exactly. If you can program, you just write what you need and it always works, it's fast, and probably most importantly you understand it completely.
Also, I totally disagree with the point that "Machines today are fast". I mean, obviously yes machines today are fast. But, in particular if you are writing a server side app, it's very easy to write something that does not scale. I have seen an app that used a lot of libraries and frameworks, etc that ran SO slow that could only process something like 1 request every 5 seconds. The same app was re-written (without using any libraries or frameworks at all) to be able to support tens of thousands of requests per second on the same physical server. Needless to say the guy who wrote the original app was fired and the guy who wrote the thing that supported 10s of thousands of requests per second got praise/bonuses/etc. The key to this kind of improvement was using the correct algorithms and data structures. When you just stitch whatever is free together you are rarely able to optimize things in such a way and you typically end up with a VERY slow app. I realize that not everyone is working on complex server side apps that need to scale, but even on front end apps, why make your app slower, lose the understanding of what you're doing, and understand some complex frameworks when you can actually write your own code in maybe less time? I mean, isn't this why so many apps are so slow. Every time i use an app that doesn't run instantly, I think about this concept. If everyone has this attitude that hardware is fast, then why do we all experience slow apps? It's because developer A thinks it's ok to reuse slow bloated code and it's still fast enough, but then developer B adds in a new feature that slows it down a bit more and uses a slow framework, then developer C adds in some other feature that slows things down further and in the end your code gets so bloated that even these really awsome machines can't run them in a way that the user expects.
I have heard this perspective before but found that when you have a team of developers that share this philosophy, you end up with VERY slow software. When you are writing software used by one person maybe you can focus on readability, but if you're dealing thousands or millions of users, forget about it. Readability does not have to come at the cost of efficient code either. There are very few occasions where making code fast makes it very confusing. In fact, I would argue that there is a lot of slow code that is very confusing to me. If people take the time to optimize it, it usually is easier to understand because there are no un-needed execution. In these few cases where very fast code is a little hard to understand, you just need to add a few lines of documentation to explain what you're doing.
I would imagine it would be a deterrent to other employees regarding "violations of company procedures regarding expenses reimbursements". So that might be the reason for disseminating the info.
Just forget about it. You can get references from the co-workers who you are still on good terms with. If your boss is the one causing the problems, I assume that in 7 years, you had at least one other boss or supervisor that you can use as a reference.
Given that Microsoft has $37 billion in total current assets as of the end of Dec '08. I think they'll survive if it IS only $1.4 million.