OT: Programming as a profession-the "practice" model

[Joe Lewis Wilkins]

Some excellent points, Marian.

I'm a little disappointed that you didn't include Architecture in your  
listing of "practices"; even more so by computer science's use of the  
term architect in various aspects of the work to be done. Actually,  
following my involvement with computers, I became a much better  
Architect due to several realizations. I've mentioned this before,  
elsewhere; but I believe it is worth mentioning again. In my earlier  
days as an Architect, I found myself procrastinating, being unwilling  
to actually start work on a project; mostly by being overwhelmed with  
the magnitude of what needed to be done.

Once I started breaking things down, solving "little" bits and pieces,  
the project started to be less imposing. Then it even started to be  
fun. But I always felt guilty about the earlier procrastination. After  
spending some time trying to program Macs, reading a lot of books on  
many programming languages, making a whole bunch of false starts, I  
came upon the concept of breaking the problem down into small,  
resolvable pieces; solving what I knew how to solve; and researching  
how to do the things that I didn't already know how to resolve.

Unfortunately, this was never taught "specifically" at U.C. Berkeley  
where I got my architectural degree. Maybe it was implied, since we  
did spend an enormous amount of time with preliminary designs and  
working with "programs" for projects; however, the programs for the  
projects were always handed to us as a part of our assignments, with  
no realization of the process. Had I been studying Computer Science,  
that would have been one of the first things I would have be taught.  
(I think!) I learned this very quickly when I started writing Handlers  
and Functions for my computer programs.

I now apply this mentality to Architecture, and have come to realize  
that "procrastination" (but by a different name) is part of all  
problem solving. It is during this "procrastination" process that we  
digest the requirements of a project, and start breaking it down into  
"aha! I can solve that" bits and pieces. The time is not wasted.  
Sometimes it even saves time by coming up with a better approach than  
might have been taken had we plunged right into "doing it".  
Incidentally, this list is a great resource for that "procrastination  
process", and then for the subsequent "researching" process. I only  
wish Architects had a similar resource, but I'm afraid we're too  
egotistical to admit that we don't have all the answers ourselves. You  
never hear an Architect self-label themselves as "newbies".  (enormous  
smile!)

Joe Wilkins

On Mar 16, 2008, at 10:57 AM, Petrides, M.D. Marian wrote:

> At the risk of opening a can of worms, I offer the following as a  
> synopsis of the  sentiments underlying the posts about the "Learn  
> Programming in One Day" ad. The common thread seems to me to be that  
> programming, like any other profession, is not so much taught as  
> practiced.  Just as medical or law schools teach the rudiments of  
> the profession, the real learning takes place in the day-to-day  
> practice.  Without lifelong learning, no lawyer, doctor, or  
> programmer will come close to achieving his/her full potential.
>
> Someone once told me in my first year of medical school that  
> "medicine is a personal philosophy, tempered by science and  
> experience, and put into practice."  It seems to me that the  
> statement applies equally to programming.  My 2 cents.
>
> M