Notice you guys are in the UK! I'm a self taught engineer (more back end focused though) and I'm trying to help my younger brother enter the industry. Is there a minimum earning threshold for the 10% salary deduction for UK courses? I think something like this would do him the world of good, especially looking at your curriculum, but don't want to saddle him with debt if it doesn't work out.
We used to use several different solutions with subsets of the projects, now though I use the solution load manager extension, http://visualstudiogallery.msdn.microsoft.com/66350dbe-ed01-... which brings down load times significantly. It basically lets you specify how projects should be loaded, so most can be loaded on demand. We have ~150 projects in total, ~10 million LOC, and VS handles it almost as well as a small solution.
I work on a pretty huge C# code base. Use of LINQ is the least of it's problems. If anything I'd say one problem is people not knowing about things like lambda expressions, linq, generics or whatever. It can really make code harder to parse when it's written in ways that don't take advantage of the full power of the platform.
If you're doing that it's crap code; you should have defined a few named object types. Maybe your "Dictionary<string, object>" is e.g. actually a "PropertyMap". this is not a problem in the c# language.
Not at all - you just missed a few facts that need considering. Lets rip it to bits some more:
It's in system.windows.forms isn't it? Don't really want that dependency and associated resolution being dragged in to a web app otherwise the compiler has to load the entire assembly's metadata.
Also, it requires full trust.
Oh and finally it isn't serializable.
Which is why we end up with SerializableDictionary<K, V> which is even longer and is an adaptor for Dictionary<K,V> which implements serialization.
That's why it all sucks.
And I haven't even included ConcurrentDictionary thread safety yet.
In my experience, that kind of stuff is usually a problem mainly because of C#'s verbosity from lack of type inference. Although, with 4 unnamed elements there, it might start making sense to create a new type, and then it's just "List<List<MyRecord>>".
Some of the code was certainly written before those features was available, especially some C# 4 features. I'm sure someone might look at my code someday and wonder why I didn't use async and await. I'm talking about code written today though.
To be fair I think all of that is good advice if you work at a certain kind of company. At my place of work I don't think any of those apply, nobody tracks your hours for example and you can work from home if you want so the never be late doesn't really work.
And this is from a reasonably sized company (~1500 full time staff)
Why not use windows 8? It has lots of small improvements to windows 7 (better task manager, better multi monitor support, new keyboard shortcuts, integrated cloud storage...etc) that's enough for me.
Plus the new Windows runtime APIs looks very nice, and most are usable in desktop or metro apps.
From an end user POV: task manager is fine in windows 7, for any deep system performance troubleshooting I use perfmon; multi monitor support is work brilliantly for me in Windows 7; I use Dropbox, works very well for me and is quite integrated enough!
As for Windows runtime APIs, it depends on whether I want to make he bet that Windows 8 is going to be successful enough to learn them. Jury is still our on that. Besides, I'm more of a Spring man...
