I am also interested in PSP and would like to know when it (courses) will be offered, and where. Is there reading material on this?

I am a programmer but I cannot really tell whether I am ‘good’ or not because I have not been measured. My job entails developing new software as well as maintaing existing software.

(Capitalization of the words “ART” and “SCIENCE” by myself, not in the original titles).
Barry’s term “good” can thus either mean: “good as art”, or “good as science”.

The question, whether programming is still (only) an “art” or whether it has already reached a status of “science”, is still an open question in the domain of philosophy of science, particularly philosophy of computer science (which is still a fairly new branch of modern philosophy).

However, in between these two extremes – “art” on the one hand, and “science” on the other hand – we can find the concept of “engineering”, which features particular elements of both, arts and science. Consequently we could ask, if Barry’s “good” programming could also be understood as: “good as engineering”.

Engineering in all classical engineering disciplines, however, has always been characterized by the availability of pre-digested and standardised “handbook knowledge”, which the engineer can easily look up and apply in the circumstances of his particular projects. Much of “engineering” is thus the repeated application of standardised “handbook knowledge”, whereas the unforeseen emergence of groundbraking new ideas of highest originality is only a rare case and only the smallest part of typical “engineering” activities. [Acknowledgments to Tom Maibaum for several related discussions I've had with him about this topic.]

Consequently the question arises now in this context of Barry’s Blog: Do we have such “handbook knowledge” in the domain of programming? The answer is loud and clear: YES! We sit indeed on an enormous pile of knowledge about Algorithms and Data Structures, which have been investigated since the late 1950s (!), and which can be readily applied to MOST of our usual, standard application problems.

The “good” programmer in this context is thus NOT the out-of-this-world “genius” who suddenly comes up with something utterly new and unheard-of. The “good” programmer is here the one who is well familiar with the vast body of knowledge (BOK) in Algorithms and Data Structures, as it has been developed since several decades, and who is able to choose wisely the appropriate “recipes” from this “cook-book” for application and re-application in his daily projects.

The BAD programmer, on the contrary, is then the one who’s trying hard to be smarter and more “inventive” than everybody else, and thereby only re-invents the wheel, because of having ignored or forgotten the ample historical repository of already existing and widely applicable BOK-solutions. The good programmer, so I may conclude, is the one who knows the HISTORY of his trade.

In summary – i feel that discipline and a good understanding of the fundamental concepts of programming create a good programmer, Once you have these coupled with a good attitude you should be able to adapt to whatever language you come across. Just my 2 cents worth.

I have an interest in PSP as it seems it works very well for you. Where can one take the PSP course? Any recommended books one may look at?

Your customers keep buying your products even 10 years after the “new car” smell has worn off.

I try in my company to have software that just works and aim to make it such that if it went to mars we would not have to send anyone there to fix it.
Today with the dev tools and everything connected and flash-able it makes for sloppy lazy programmers that slam dunk solutions together and wait till run time(or customer cancellations) to bug fix.

I started out coding in assembler on Z80′s and burning proms.
If you didn’t have attention to detail you could end up with an expensive and time wasting delay or even worse a buggered processor.
I do not want a return to those days, however I have found that today’s young engineers seem to have a “just throw more processing power or Ram at the situation rather than really understand the problem.
Also with abstraction has come a lack of understanding of the fundamentals of processing and memory management.

I hired two very well qualified software engineers (MSC’s from Wits) a few years back and had them working on a RS232 comms controller for a Radio Data network.
It took three months, thousands of lines of code and endless late nights with these guys trying to debug a complex multithreading C# application complete with multi agent architecture(why?)
The system kept on locking up and running out of steam even though the PC processor was a latest dual core pentium and the Radio network driving it all was only a simple 8 bit processor.
“We can’t use SQL express we need a full licence” I was told and maybe more Ram.

Fortunately for me these geniuses were “headhunted” out of my company and I ended up having to re-write the application myself.
I am an electronics guy not a software guy so I did what was the easiest for me and re-wrote the application in VB6.
150 lines of code 1/100 of the processor load compared to the other app as I use the hardware (uart) to do half the processing for me in hardware (Data and header detection) and buffering and interrupts(sorry “events” in sw speak).
No bugs and the client is happy.
No threading no Agents running around “polling each other”, just simple code and its still working bug free a year later.

As an engineer, I like solving challenges in a simple and sometimes unique fashion, as a business owner all that is important is that it works reliably and it does exactly as the customer wants.

I would like to make some comments on your blog about a good programmer.
I also started as a programmer in 1983, my world at this time was IBM-MVS Hosts, Cobol, IMS.

I started with a big Insurance company in a 2 years trainings course. In the first 9 months we did not write one single line of code but trained structuring programmes. The company was heavily committed to Jackson programme structuring methods (I don’t know if you know about that, but at that time it was quite famous). However we trained structuring programmes until we dreamed about it at night. We also learned how to test programmes methodically, how to test exception (e.g. if no input, if impossible input, etc.).

When I came out of this course I was a good programmer and I programmed good in the sense of your blog. Something I also learned was to re-use code; copy/paste was the most efficient way to write programmes at that time: The coding was quick and the code was tested already.

However i moved forward and since a number of years I work as Project and Programme Manager. When I look at the young programmers in our teams I always find they are brilliant with ideas on how to solve a problem, but they completely lack the good old craftman ship of programming.

As a result the solutions are often brilliant, the quality is lousy. Maybe going back to these old programme craftman ship values would not be such a bad idea.

regards

Peter

But I am a writer, and I found tremendous similarity between the processes outlined by Barry for planning, coding and executing programs and those for planning, writing and publishing an article. Without a doubt, my best work comes from pre-planning the objective, structure and content before putting fingers to keys, carefully checking the accuracy of the key depressions while typing and then doing a run-through before hitting the “send” or “publish” button.

Maybe we can take PSP into the world of journalism?