Showing posts with label programming maturity. Show all posts
Showing posts with label programming maturity. Show all posts
Sunday, December 10, 2017
Do programmers really know how to program?
I was asked, "Do programmers really know how to program?"
I believe this question is unproductive and vague. What does it mean by “program”?
The person who asked this question seemed to think programmers were not really programming when all they did was copy some existing program, using it whole or perhaps pasting it in as part of a shell.
To me, programming a computer means instructing it to do something you want done, and to continue doing it as desired.
If that’s what we’re asking about, then yes, of course, some of us out here know how to program. (Some do not, of course.)
It is irrelevant how we do that. Whether we use genetic algorithms, cut-and-paste, or divine inspiration? Do we use Scrum or Agile or Waterfall? How about the programming language? C++, or Java, or Lisp, or Python, or APL? Well, none of those choices matters.
Then what does matter? How about, "Can we satisfy someone’s desires?" In other words, can we provide something that someone wants enough to pay what it costs, in time or money? That’s what counts, and we certainly know how do that—sometimes.
Sure, we fail at times, and probably too often. But no profession succeeds in satisfying its customers all the time. Did your teachers always succeed in teaching you something you wanted to know? Do surgeons know how to do surgery?
So what about using existing programs? To my mind, the first and foremost job of a programmer is knowing when not to write a program at all—either because the needed program already exists or because no program was needed in the first place.
In other words, not writing a program when no program is needed is the highest form of programming, and one of the marks of a true expert.
or Kindle for the book in paper or ebook format
Tuesday, November 07, 2017
When do I know I'm not a beginning programmer any more?
I was asked, "When do I know I'm not a beginning programmer any more?"
I wouldn’t answer this question, because it’s the wrong question.
You should not ever want to know you’re not a beginner, because a true professional is always a beginner. The world in general, and the world of programming in particular, is so complex, so huge, that one lifetime is not long enough to stop being a beginner.
Your beginner’s mind is one of your most valuable tools. It requires you to look at each situation afresh, and to innovate. (Fundamentally, that's what the Agile movement is all about.) If you know children, watch how they use their beginner’s minds to conquer their world.
I’m very suspicious of people in the programming field who think they are no longer beginners. Myself, I’ve been programming for about 70 years, and I still consider myself a beginner.
Thursday, November 02, 2017
How do I become a programmer who gets stuff done?
The young man wanted to know, "How do I become a programmer who gets stuff done?" He received a number of good answers, like how to organize his work and schedule his working hours. Yet I had a different view of things, so I gave a different sort of answer, as follows.
Some good advice here, yet even if you do all these suggested things, you may be having a different problem. When you speak of getting stuff done, you may be speaking of “finishing” things.
Defining what “done” means has been a classic programmer problem for more than 50 years. Part of the problem is that programmers with different personalities have different ideas about what “done” means. For instance, look at the situation from the point of view of MBTI personality temperaments:
NTs tend to think a project is done when they have a clear description of the problem and a general approach to solving it. Someone else can work out the details.
SJs tend to think a project is done when it’s “code complete”—though research at Microsoft and other places seems to indicate that only about two-thirds of the eventual code has been written by that supposed benchmark. Perhaps this work isn't thought of real programming, but only "clean up."
NFs, such as me, tend to think that a project is done when everyone involved is satisfied that it’s done. Of course, because these "others" are of various personality types, our NF estimate of "done" isn't very reliable.
SPs tend to think a project is done when they are bored with doing it. They share this feeling with lots of other temperaments, too. Programmers in general don't tolerate boredom very well.
Not taking that last step to "clean up" is a curse of our profession, leaving many programs in a less-than wholesome state. Unclean, unfinished programs are the source of many maintenance problems, and of many errors shipped to customers.
Of course, this classification is only a rough model of non-finishers. Many good programmers of all temperaments are excellent finishers, having taught themselves to be aware of their tendencies and counter them with a variety of tactics. Primary among those tactics if the technical review by peers (which is an integral part of the Agile approach but by no means is not confined to Agile).
So, you offer your “finished” project to your peers for review, and if they agree that it’s finished, you’ve truly gotten something “done.”
If they don’t agree that your work is done, they will give you a list of issues that you need to address before you’re “done.” You then go back to work and address these issues, then resubmit the newest version to another technical review.
Finally, you iterate in this reviewing process until your work passes the review. Then you know you’ve gotten something done.
For more detail on the review process, see,
Tuesday, August 15, 2017
Must a Developer Know the Language?
We were asked, "Have you ever applied for a software developer job where you didn't know the language?"
My story is not exactly the same as others might have, for several reasons, but I think it does answer the question.
There are two phases to my story. My first job developing software was at IBM, in 1956. At that time, I didn’t know any programming language, largely because there really weren’t any languages other than machine code. So, I spent two weeks in a closet learning my first computer language.
Actually, it was three languages at once: machine codes for the IBM 704 and 650, plus the wired “language” for the IBM 607.
The second phase of my story takes place some years later, when I became a consultant. In that role, I have helped many, many clients who were using languages I didn’t know—even though I knew quite a few by that time, including LISP, Smalltalk, APL, PL/I, COBOL, FORTRAN, C, Pascal, Simula, several home-grown special application languages, and the machine code for the IBM 7090, 1410, 705, STRETCH, Dec’s PDP-1 and a few other machines. I had also studied in a bookish way quite a few other machines while doing competitive analyses for IBM.
I was able to help those clients largely because their problems seldom had much to do with the details of their chosen language(s). Instead, they were people problems of all sorts. The problems that did wind up with a language embodiment were usually easy to spot using my general knowledge of computer languages and typical errors people made in using them. That’s why I’ve always insisted that professional developers should know at least a handful of different language.
I think there's an analogy here with the term "mathematical maturity," something we might call "programming maturity." Here's how Wikipedia defines mathematical maturity:
Mathematical maturity is an informal term used by mathematicians to refer to a mixture of mathematical experience and insight that cannot be directly taught. Instead, it comes from repeated exposure to mathematical concepts. It is a gauge of mathematics student's erudition in mathematical structures and methods.
For instance, a mature mathematician is able to transcend notational differences, unlike my tutorial student who flunked algebra because he had learned to "solve for x," but said, "You didn't teach me to solve for y."
We could easily use most of those words to define "programming maturity," the ability that allows you to succeed in a developer job using a language in which you have no previous experience.
Subscribe to:
Posts (Atom)