by Vincent P. North
Introduction: Just Call It A Careers Experience, Condensed Into Six Key Topics
By manner of introduction, I have been a professional computer programmer and, software project manager for about thirty-five years. I was fortunate to have begun that career when the personal computer had not quite yet arrived on the scene. (They were still, for the most part, a tantalizing future curiosity, then found only in the pages of Radio-Electronics and Popular Electronics magazines.) Computers either filled air-conditioned rooms or, more recently, were about the size of a breadbox. Although integrated circuits, including microprocessors, were a standard part of electronic design, computers at that time were neither small nor fast. Computers, also, were devices that other people owned: companies who could afford to buy the boxes and the air-conditioned rooms to put them in. It was in this context that I first got my start.
As you well know, the subsequent years have witnessed dramatic changes. Moores Law continues to hold true, as semiconductor manufacturers continue to astonish us all with how much more computing power they can somehow cram into a single tiny piece of sand. Builders of flat-screen and touch-sensitive displays also continue to astound us with what they can do, as have the builders of sound-chips and nearly-microscopic digital cameras. We live in interesting times that certainly show no sign of slacking off.
Into this whirling dervish of a technological world, then, comes you, Gentle Reader. Tasked not only with keeping up with the hardware technology that will never allow itself to fully be kept-up with, but also with the task of computer programming itself.
It has been said, by some, that computer programming is an innate ability. That you either have it (whatever it is ), or you dont. But, I dont agree. I never thought of myself as being a natural in what became my career. I was merely naturally interested in it, as I still am. I was interested enough, and found it to be engaging enough, that I persevered to learn how to do it. But I made a lot of dumb mistakes along the way which I would like to try to help you avoid.
Most of all, my experience has shown me a list of fundamental technical skills of a professional programmer, which I have now sought to reduce to a succinct list of six items. The actual list is longer maybe, much longer but after some reflection, here are the six that in my humble opinion are key. These are the things all of them technical abilities, procedures and perspectives which you will use on the job most every day. These are six things for which, in my opinion at least, your command of these skills will make the greatest difference in your success and longevity in the craft.
Computer programming, by the way, still is a craft. At this writing, it still requires skilled work and the product of experience. But we should recognize that this aspect also is changing. Thanks to the influence of open-source programs and cooperative development, computer programming is tilting in-part toward the assembly of new solutions based substantially on pre-existing components that the programmer(s) in question did not themselves develop. This, itself, constitutes a new fundamental technical skill that is one of the six that you will now find in this book.
And So, And Without Further Ado: Here Are The Six
As I said in the Introduction, the following is a list of what I consider to be six fundamental technical skills that every computer programmer needs to know. Technical means that these are things which you need to know and which you will apply when crafting (and troubleshooting) the computer software that you write, and/or that you (and your team) maintain, for your client or employer. These skills are not particular to any single size, type, or brand of computer hardware, and for the most part also are not limited to any computer programming language or tool. These also are not social nor organizational skills. (That would be a separate list, entirely.)
The List
Internal memory management and data structures.
Objects.
SQL Database Queries and Concepts.
Precise specification, strategy, and implementation.
Front-End, Back-End. User-interfaces and frameworks.
Pragmatic Debugging skills.
This list is not in any particular order, although I will choose to address it in the sequence given. My treatment of each topic will also not be extremely detailed. Please understand that I am seeking to provide you with a 30,000-foot view, and to point you in specific directions from which you can pursue additional research on your own.
This list is also not a primer, and I emphatically do not by using this phrase intend any negative slight to you. The topics that I will present here might well, section-by-section, require re-reading. (And, they might require clarification. Since this is an e- book, we can do that.)
David Intersimone, the original director of development a (now, long-defunct ) Borland International, referred to this experience as a sip from the fire-hose. I find myself unable now to acknowledge that your superficial experience with regards to the forthcoming material might well be the same. However, as your Gentle Author, I hope that you will not in fact expect anything less from the text that you are about to consume.
And so, with all that now said: Let us begin.
One : Internal Memory Management and Data Structures:
Every digital computer room-sized or pocket-sized consists of the same three functional parts:
CPU = Central Processing Unit (the microprocessor, GPU, etc.).
I/O = Input/Output.
Main Memory.
Memory, of course, consists of (today ) billions of individual storage-compartments, each one character (byte ) wide, each with an individual address. The CPU retrieves both instructions and data from memory, which is the only part of the computer system which is (must be ) [nearly ] as fast as the CPU itself.
All modern operating systems through interesting devisings that need not concern us here are magically able to provide each executing program with the functional illusion that they have some certain amount of memory all to themselves. They never have to worry about stumbling into anyone elses memory, because no one elses memory is ever visible or accessible to them, unless both programs make special arrangements to share a certain part of it which very-interesting topic I hereby simply declare to be out of scope for the purposes of our present conversation.
Thus, we have, for each process which completely defines how each process actually perceives [its private view of ] Main Memory. This view, as it turns out, consists of exactly two things:
The Stack: Every process, from the operating systems point of view, consists of one subroutine. The operating system launches the process by calling that one subroutine, and, when that one subroutine finally returns to its caller, the entire process ends. This subroutine, directly or indirectly, launches many other subroutines, each one of which is called and then, finally, returns to its caller. Each subroutine, during its finite lifetime, possesses some certain set of local variables which are peculiar to itself, such that, if the subroutine (by whatever means) happens to call itself, the local variables owned by each instance will be distinct. The entire portion of memory which is used to accomplish this feat is called, the Stack, because it has the effective functional organization of a set of dishes stored at the start of any cafeteria line. The call-and-return flow of control, and the storage of all local variables, is managed using this single area of storage.