Matt's Homepage

Fascinating analysis of job sectors and projected areas where high-job growth will be/not be.  Who knew the bureau of Labor actually did semi-useful and interesting work?

http://www.bls.gov/oco/oco2003.htm#industry

Big winners (they have really detailed breakdowns too – quite fascinating):

• Medical
• Professional/technical

Big Losers:

• Utilities
• Farming, Forestry, Fishing
• Manufacturing

Green safety bike-boxes ‘do nothing’:
http://www.portlandmercury.com/portland/thinking-outside-the-bike-box/Content?oid=2122941

Portland paid $200,000 to paint little green bike boxes at a few intersections to curb bike/car accidents.  When this idea came up – a great number of voices lauded it.  Well, after an actual independent study – it’s proven they don’t do much either way – mostly because there were statistically so few accidents to begin with involving intersections such as these.  Maybe it helps raise awareness of bikers by putting them in front of you?  Don’t know, but glad someone is actually studying the effectiveness of these efforts.

I’m becoming more and more tired of Microsoft’s mindset of how software should be written.  As an engineer, I can see exactly how they’ve gotten to where they are design-wise – but think it’s time they took a step back and take a look at exactly what they’ve gotten themselves into.

I often frequent a MS insider’s blog who fields problems that end-developers encounter using Microsoft’s interfaces and API’s (The New Old Thing).  Again and again I’m struck by how un-developer friendly some of the newer API’s are.    The API’s can be very unforgiving and inflexible – and confusing.  And the reply you usually get when confusion results of the design decisions and logic are often condescending (actual clip from responses when users/devs give feedback):

“So, I’ve done everything according to the docs and it isn’t doing what it says it should – is the b operator broken?”
No, the b operator is working just fine. The problem is that the b operator doesn’t do what you think it does.

Back in their Win32 days – the API was relatively clean, pretty understandable, and fairly easy to pick up.  But now, with some of the ‘programming features’ in .NET stuff I’ve seen – it makes me glad I’m still in good-old C++ land.  Auto-initializers, massive use of custom data types with strange member functions for interacting with the data, metadata with your classes (Metadata EVERYWHERE in fact), it’s very hard to know what’s really going on under the covers or why the design ended up the way it did.  Maybe I’m old-fashioned or write things that don’t fit nicely into their wizards, but I LIKE knowing what’s going on under the covers. Just ‘trusting’ the API to figure out what I’m trying to do has never done anything but get me into mysterious corners that reason and logic can’t get you back out of.

What I really want as a developer is to be able to develop QUICKLY.  However, I think MS has misunderstood that term.  QUICKLY doesn’t mean getting “Hello World” up in the fewest number of mouse clicks/lines of code typed.  Quickly doesn’t mean I can use some kind of wizard. Speed of development depends firstly on how quickly I can LEARN THE PHILOSOPHY AND DESIGN OF THE LANGUAGE I’M USING.  If I understand those two things – then when I hit a moment of saying “I need to do operation X (which I currently don’t know how to do), I can REASON OUT what it is I need to look for.  However, if you say to yourself, “I need to get the current working directory”, then find out that you need to learn a special new kind of string class with all kinds of new struct types for initializing/interacting, a new kind of file system iterator, etc – you find yourself spending 2 hours trying to learn how to interact with the monstrosity of the language instead of developing real working code.  I could do the above operation in 1-2 lines in Unix c and Win32, but some .NET and other MS API’s have becoming horribly confusing to figure out.  Why?  Because the API’s seem so certain that you need lots of help to write anything, they’ve re-worked every old data type and API call you know and love. THIS kind of attitude is what slows development to a crawl when working on new API’s/languages.

The final nail that makes it all disappointing as a developer is knowing that NOBODY else is using the language that you’re now spending all this time learning.  You feel like you’re spending all this time as a wasted effort in learning non-transferable knowledge.  As a computer scientist – I know the theory behind languages – I have the transferable part of computational/languages theory down.  What I’m really doing is learning the non-transferable parts – and I find myself doing that in spades with some of Microsoft’s newer API’s and not in a good way that helps my career along the path of inevitable growth and change.  At least it’s starting to get compacted down in C#; but it’s taken a LONG road from Win32->MFC->COM to get us there – and I’ve forgotten more of that stuff than I care to try and recall.  But if I learn C or Haskell or Java – at least it works cross-platform and I know I could write it on a Mac/Unix too.  It’s a good use of my time.  But I just don’t get that feel with most modern MS stuff.

It’s frustrating; but I don’t know what the right answer really is.  Maybe this is the way things need to develop.  Perhaps I should ponder and write up a bit about the comparison of how new platform solutions are designed by MS, open source, and Apple OS’s…