Reply to Message

Looks like a good list to me.

Not that I'm any great shakes as a programmer. I do program for a living, but in a highly specialized field which has its own unique requirements and expectations. I program DDC devices (dedicated computers in a "Black Box") which in turn control real, physical mechanical and electrical equipment. Originally done in a programming style called "ladder logic"; these days the programming languages (mostly proprietary) look more like Basic, Visual Basic, C and it's cousins, or Java. Throw in regular Java, HTML, SQL, etc which are used on front end display and control consoles (which are regular PCs). None of which make me a programming guru by any means. In my field it is important to be an "adequate" programmer, but MORE important that you have a mechanical or electrical engineering background and have an excellent grasp of the science and technology of the equipment that you'll be controlling. The actual apps we develop are normally neither long nor complex (from a programming point of view). The general practice in my field is to go for shorter, simpler apps, that accomplish a few functions. And if more is needed, to create multiple, discreet and independent apps, each of which will run independently of the others (altho they might share information) within their own memory spaces.

In any event, I'd hope that any young developers out there would pay heed to your advice. Its good.

The learning of alternate programming languages is important. For a number of reasons. Not the least of which is that I've experienced numerous occasions where some technique or method I learned in an alternate programming language could be advantageously used in some other. Besides, one doesn't ever really know when or if that knowledge of another language might come in handy.

For instance, years ago I learned (just as a hobby) VB. At the time my bread and butter programming languages were QB and Clipper. But then at the place where I was working we started using a certain proprietary and specialized programming language which was so similar to VB, that learning it, for me, was a snap. Likewise, some years ago I learned to be proficient (but not expert) in Java. But then let it drop as at the time I wasn't into Web apps at all. But here recently where I work we started working with platforms which have what is essentially an embedded Java framework, and all programming for these devices is in Java. Not just for web apps, although these devices besides their other functions are also web servers, but ALL programming of ALL functions is done in Java. An attempt by the manufacturer to make these devices OS independent while using a common programming language that is free and open source. In fact, one can buy these control devices in the form of a "black box" with microprocessors, I/O controllers, memory, etc ... which have an embedded form of Unix as the underlying OS. Or one can buy a software version of same written to run on a standard Windows based PC. And control programs you've developed run on either, unmodified. Because said programs are in standards compliant Java.

Add, its always a good practice to be exposed to new ideas, techniques, and so forth. It keeps one's mind fresh and agile.

The learning of basic theories is something I couldn't agree with more. The only guaranteed constant in life ... is that things change. But if you know not only the "How" and "What" to do, but also the "Why" of it ... adapting to change, or being able to figure out what a problem is will only be that much easier.

Learning from senior programmers is also a good one. We have one such where I work whom I'm always asking questions of. Often, I'll look at some original code he generated, and wonder why he did something this way as versus that (some other way that looks to me to be a better method).

All too often, often enough to keep me from ever getting a fat head, I find out that he's got a darn good reason for doing what he did, the way he did it.

Often, it's some aspect or consideration I never even thought of. Something he learned or figured out via the old "school of hard knocks". His answers as to why are not always insights into some new, fancy algorithm, or advanced line of thought or methodology.

Chuckle, sometimes its as simple as, "It's less obfuscated code. Plainer, simpler. Done this other way you are suggesting, there is more likelihood that another programmer using that function in his application is gonna make an error or screw it up. My way is more immediately understandable and more easily re-usable by others."

On another occasion he explained that for a certain function he went about coding it a certain way simply because the way the resulting info was presented to the user was more intuitively understandable to them than any other way he'd seen. In this instance, I THOUGHT I had the better idea. And did it differently. I was wrong. My way looked better to me, and seemed to be perfectly understandable to me. But in field experience showed that my way resulted in more complaints and misunderstandings than his way.

In other cases, his reasons were more obscure and technical. A case in point. A certain routine he wrote which had a built in time delay in it (a Wait). I saw that and thought about it and thought about it. Could not figure out why he had that wait statement there. Finally asked. He explained that the main microprocessor in the target device was so fast that if one did not slow down the program execution, it COULD outpace the board's I/O bus and their independent processors in certain situations. Old data was overwritten by new data before action was ever taken on the old data. Occasionally, at unpredictable intervals. And sometimes registers or other memory locations went into overflow conditions. System might work for an hour, or days. But sooner or later you got a crash, abort, or other adverse result. Usually in the middle of the night or some other most disadvantageous time. Wasn't an unrecoverable error. System would just reboot the app. But this tended to irritate customers.

That kind of thing is NOT something you learn in books or in a classroom.

It's not that this fellow always has the better answer and method. I've managed to teach him a thing or two. But nothing as compared to what I've managed to learn from him.