when I had to enter my bios by hand when my clock speed jumped from 1MHz to 2MHz when my HD was 5M when my RAM was 32K http://www.imsai.net/

It's been awhile, but that's how the Amiga worked as I recall. only single click.

I agree with using multiple tools/languages in projects. I do all of my engineering work in MATLAB and generate C++ code from that (saves 100's of hours if the math is complex). I clean it up in VS. When I really need performance I drop into C and run it through my Lattice C compiler (20yrs old but still the best for generating super-clean assembly language) and if I really need to get scary I write pieces in machine code. IMHO I think the first programmimg language anyone should learn is assembly. When you understand the internals of a CPU you become vastly better in any language.

There's a billion (~) starving people in the world, does that make starvation good?

Couldn't agree more; I'm an EE :). I think the things you get as an EE are an understanding of the underlying hardware and what is actually happening in the processor for every line of code, a discipline for viewing everything as a (hopfully closed loop) system, and intense and applied math. (Most math majors I know don't really apply math to anything.) Next to EE's I find musicians pretty easy to train as really great programmers.

I always publish a data dictionary with every project and a style guide for any deviations from "standards" and to define which "standard" I am using. A single file holds the definion and type for each variable. Easy to find the datatype and you actually know what the variable means in the real world. This also helps keep business variable names distinct and consistant across an entire project (e.g., never "name", always clientName, providerName, and clientName everywhere) which I feel is a critical practice. I also publish "global" names that are reused. (e.g., ndx is always used for the innermost indexer in loops). You can write scripts that will find most variables and add them to a dictionary. For Property-backs I use _whatever so I know I will have a Property Whatever on the object. Though I sometimes shortcut when it is very clear. (e.g., On the "Client" object I may have _clientName on the back, but "Name" on the Property. I always (and only) use type prefixes for GUI object types in stuff like ASP.net (e.g., "asp:Button btn_SaveClient") and always publish the prefixes btn =button, tb =textbox in the data dictionary. This really helps in the code behind when VS creates event handler names for you - tb_Client_OnFocus, tb_Client_TextChanged. Every naming convention is only designed to make code clearer. A data dictionary does this best (IMHO), and if you inherit multi-convention code this really helps "fix" it. (e.g., if in one file I have clntCode and in another ClientID and another intClient I can add them all to the dictionary, make sure I understand them, and then find-replace for each - clntCode int; -> clientCode Int32; ClientID decimal(6,0); -> clientCode Int32; Not perfect, but a good start. Which convention doesn't matter if you are consistant and document well. A Data Dictionary does this, provides a big step in documentation, and helps provide a global view of your application.

In the end it's all goto's. The processor turns everything into a goto to a memory address or register. Contained within a procedural function a goto is much more efficent than a bunch of if-then-else's or cases. It is also much more readable to an experienced programmer when used properly. Goto's are not bad; misuse or no use is poor practice.