Programming Is In The Mind

Coding is a mental activity that eventually becomes transcribed into a particular language, in a particular file, in a particular machine. In other words, ProgrammingIsInTheMind.

But see SapirWhorfHypothesis and ToolsThatTeachPoorHabits for an examination of how programming shapes the mind.

Well where else would programming be? Your legs? Don't say your hands because that is a straw hand.

Some mistakenly believe that it's "in the computer", or at least that's where the "important stuff" happens.

Another way of saying this is that code is mostly for humans, not for computers. "Silly rabbit, code trix are for humans!"

All this is essentially a restatement that there is NoSilverBullet. (EditHint: Merge the 2 pages?)

Or, that silver bullets vary from person-to-person

{Or, perhaps, the SilverBullet is matching individual heads. In other words, the bullet may not be a universal tool, but a semi-custom tool, or at least in matching tool to individuals. It may be that PsychologyMatters. (By the way, I didn't create this topic.) - t}

Many factors such as the keyboard, mouse, monitor, OS, IDE, compiler, and language environment can affect the quality of the code that eventually gets expressed, but all these other factors are negligible compared to the programmer's mental activity. The creative act of programming is still, and probably always will be, an art rather than a science. The quality of the artwork (code) is primarily and directly dependent on the quality of the artist.

Nevertheless, the other factors mentioned above can impede or assist the coding activity to some degree. A bad keyboard can drive a programmer nuts, while a good one can be a joy. Likewise with the OS, IDE, etc. However, I would say that the choice of programming language is by far the second most important factor in determining the quality of the code.

A programming language provides a context into which the programmer must fit their thinking. Some languages provide better contexts than others. Or, perhaps a better way to put it, programming languages vary regarding the ease of expressing various kinds of thinking. For example, I may think of some great names to use in my program for variables and such, but the FortranLanguage will tend to make it hard for me to express them well due to its limited name length. However, the JavaLanguage will make it easier for me to express those names well because of its greater flexibility in naming. Nevertheless, I can use bad names in either (and Fortran could be considered to encourage that). Therefore, BadCodeCanBeWrittenInAnyLanguage.

One of the best examples of this situation is ObjectOrientedProgramming. Many people argue about whether a particular language is object-oriented. In reality, ObjectOrientedProgramming is a mental activity of the programmer far more than it is a feature of a programming language. A programmer that thinks according to an ObjectOrientedProgramming paradigm can express it in any programming language. Likewise, a programmer who does not can also express that in any language. The choice of language is still important, though. This is because each language varies in its expressiveness of that kind of thinking. It is not a boolean characteristic (OO or not OO), but a nearly continuous spectrum (how much OO). ObjectOrientedProgramming is usually defined based on abstraction, encapsulation, inheritance, and polymorphism. Each language varies in the degree to which it supports each concept, and how effectively it allows each to be expressed.

-- RobWilliams

Agreed. Whenever I try to get to the bottom of why someone thinks "OO is better", it seems to usually lead to mental perceptions and conventions rather than any objective, externally-verifiable metric or results. Initially they perceive it as objective and open-and-shut, but when I try to turn it into a specific claim, then it falls apart under scrutiny or is available in other paradigms also. Everyone seems to think that their view of the world is a kind of central standard. I admit that I have made this same mistake. I have learned from this and am less likely to claim that my favorite approaches are an absolute truth, just that they work for my head. -- top

By the way, I take exception to the suggestion that OO is "better abstraction" or "higher abstraction". Determining what exactly "abstraction" also seems to get into mental-land. Mere "hiding implementation" can be done by functions. MeasuringAbstraction

I would agree for the most part but would be wary of accepting this as gospel. One reason is that tools can help programming to a large degree. An example would be a RefactoringBrowser, or possibly a TestingFramework. If programming were 100% in the mind, then these tools would have no effect. However, since we are limited by BoundedRationality, these tools help us organize our thoughts and try out different ideas in an automated fashion.

I'm sure that in the past people would say that MathIsInTheMind, but then calculators came along.

Math still is in the mind. First, it's quite a narrowing point of view to reduce math to calculating. And second, a calculator is not a self-serving thing, you still must use your mind to interpret what the calculator tells you. Maybe you should clarify on what you are talking about, also with programming: Are you referring to the mental activity of modeling, or to the more physical activity of telling the computer your model? Maybe one could describe a RefactoringBrowser as a way to talk with the computer about the model in your head (as opposed to the a ProgrammingLanguage as a way to express this model).

[Somewhat later] I realized that you seem to misinterpret the title: ProgrammingIsInTheMind does not want to say ProgrammingIsOnlyInTheMind. -- AndreasHaferburg?

Or LogicIsInTheMind?, but then PrologLanguage came along...

Lets flip this around: it seems more truthful to say that bad tools can hinder programming to a large degree. A GoodProgrammer may or may not be able to overcome the limitations of his/her tools. To me, a BadProgrammer is someone who is not a GoodProgrammer even when they have the use of good tools. A BadProgrammer simply does not think the way a GoodProgrammer does, and will not always/usually/ever solve the program in an elegant/efficient way. Consider a different art (such as woodworking). A bad- or non-craftsman will never produce a good work even if you give him expensive, high-quality tools. If a bad craftsman does start to produce good work with the high-quality tools, it means he has become a good craftsman.

Yes, tools can assist programming and calculators can help in solving math problems. But, they only do so by operating on the expression of the thinking behind the activities.

A refactoring browser works on the source code, not on the thinking behind the source code. Also, remember that the refactoring browser is itself a program - the expression of a programmer's thinking in a particular area. So the refactoring browser is limited by the thinking involved in producing it. Solid thinking is required to properly apply the browser.

Likewise, the calculator facilitates mathematical activities only in the most trivial aspects. You can add, subtract, etc. But most of math involves mental activities that the calculator (or even far more sophisticated tools) can not address.

All of the important aspects of programming or math or nearly any other human activity involve the mind; the human thought process is essentially irreplaceable and unignorable. This is especially true when addressing creative activities such as programming or various other artistic pursuits. I would not dogmatically state that such activities are 100% in the mind, but I think that it is close enough to make it the primary focus of our efforts to improve those activities. Calculators and refactoring browsers are wonderful tools, but they are essentially useless without a good mind to properly employ them.

-- RobWilliams

This pattern of argument is the first flake in the snowball of MovingGoalPosts. Let's avoid it before anyone gets too entrenched in their position. You might be interested in reading about GeneticProgramming, which has produced patentable software through an artificially-intelligent process.

But even more importantly, what is the purpose of this page? What specifically are you trying to say about programming? Why is it important that ProgrammingIsInTheMind? Maybe an anecdote about how this has applied to your own programming would be interesting.

I do not see any moving goal posts. Nothing has changed. My response simply clarified the point I was making, and why the proposed tools do not make a difference.

I think that this page can definitely say more about why ProgrammingIsInTheMind, but I think that it has also made a good start. Thanks for focusing the discussion.

The fundamental point is that good programming comes from a human practicing good thinking. Bad programming comes from a human practicing not-as-good thinking. Focusing on the creative and high-quality thinking will allow us to improve the quality of programming. Focusing on other issues such as tools will have a much, much lower impact.

For example, we do not evaluate mathematicians by the quality of the calculator, or even by their skill in using one. Calculators are useful, but their impact on the practice of mathematics is entirely trivial. Likewise, the calculator's impact on programming is entirely trivial. The real value comes from a well-trained mind tackling a nontrivial problem.

-- RobWilliams

I'd say that our tools are lagging considerably behind our good thinking practice. For instance, my particular tools happen to still fail catastrophically to DoWhatIMean. Please let me know when that gets any better. -- LB

Regarding GeneticProgramming...

Being able to patent something says essentially nothing about its quality or value.

Furthermore, I would assert (along with many others) that artificial intelligence has been revealed to be a dead end, even an oxymoron. At best, it is a ridiculously inefficient means of producing questionable software. Artificial intelligence consists of programmers writing software to produce software in a non-obvious manner. It complicates an already complicated endeavor without adding value.

-- RobWilliams

And this just makes me even more skeptical. I noticed that you said, "The fundamental point is that good programming comes from a human practicing good thinking. Bad programming comes from a human practicing not-as-good thinking." I'm of the opinion that you can factor out the 'human' and replace it with 'system' without losing any important information. Of course this is going to diverge the conversation into a StrongAiVsWeakAi? debate, which I'm not really interested in. Suffice it to say that I consider the onus to be upon you to produce positive evidence that ProgrammingIsInTheMind is valid and important. So far it's just a claim. Now it needs facts to support it.

Nice try, but I am not willing to accept your shift of the burden of proof. Historically, the tools have always held the subordinate position to the human worker when determining the quality of the product. Computers are nothing more than very complex tools -- they are quantitatively different but not qualitatively different. In particular, the advent of transistors et al did not grant the new characteristic (quality) of intelligence to our tools.

Therefore, the burden of proof rests with anyone who asserts that such a tool exists and that it can make a dramatic impact on the ability of a human to produce high-quality results. The closest that a tool can come is to encapsulate the specific expertise (thinking) of one human into a form (such as a computer program) that allows another human without that expertise to easily invoke it. This is only viable in very well-defined problem domains, and it usually has limited success because the user often misuses the functionality.

Calculators and refactoring browsers are both perfect examples of this. They help the user with a very specific task by encapsulating the detailed expertise of another human (often several humans). But neither of these tools can really help the user much in deciding when and how to best invoke their functionality; although a refactoring browser would definitely be expected to be more helpful than a calculator in this respect. For example, the calculator will properly calculate square roots all day long, but it can not tell the user that a square root is irrelevant to solving the particular word problem on their math homework assignment. The user is given the right square root, but the user uses it to produce the wrong answer to the word problem.

My intent with this page is to point out that we routinely forget this fact, and that we particularly do it with regard to the programming activity. It is a physical impossibility to produce a tool that will significantly supersede the human in producing quality software, except by trivially automating well-defined steps which will often be misapplied.

We should still try to produce such tools, but we need to focus our attention on improving the abilities of the people involved instead.

-- RobWilliams

Do you have any evidence or references to back up (and/or quantify) the claim that 'focusing on other issues such as tools will have a much, much lower impact'? I agree that human issues currently have the most impact, but I believe this for a different reason than ProgrammingIsInTheMind. And I'm skeptical of the wording 'much, much lower impact'.

Professional programming is closer to engineering than it is to mathematics. One of the first things I noticed after leaving university and entering the real world was how little I understood about the place of programming in a business context. I would argue, from this perspective, that most engineers are evaluated on how well they can use a calculator (and the other tools of the engineering trade). Now, I'm not an engineer, so I might be wrong, but I suspect that like so many other fields in life, most engineers are implementing someone else's ideas. In software, it's not so much different. Witness the overwhelming instinct of companies to hire based on '5+ years experience in technology X'.

There may be something to the idea that ProgrammingIsInTheMind, but I am still skeptical as to its practical (as opposed to theoretical) value.

Most engineers are not evaluated based on their ability to use a calculator, they are simply expected to be able to use one and can expect to be fired if they cannot. They do not typically list calculator use on their resume', nor is it typically discussed in their interviews. Their real skills are much more difficult to identify and quantify, but they start with relevant problem-solving skills at a much higher level than using a calculator.

Yes, companies focus on things like "5+ years experience in technology X", but they do so foolishly. Stating a number of years of experience with anything as complex as the typical computer technology is a meaningless measurement. Years of experience will definitely make you older, but it only might make you wiser. Smarter companies perform some sort of actual skill verification such as a detailed technical interview or a test, which is definitely nontrivial and problematic. Ultimately, hirers are essentially gambling. Also, such a focus ignores such things as the transferability of skills, e.g. a C++ programmer does not have to start from scratch when he shifts to Java.

The truly important skills in the technology industries (such as programming) are usually ignored completely. The focus is on the trivial (how-to) tool skills: do you know Java? Sometimes, the focus will expand to include the first level of nontrivial (why & when) skills: do you know how to properly apply Java as a software engineer? Only very rarely will the focus encompass a holistic viewpoint: can you help me address my needs by implementing a technology-based solution, advise me throughout the process, work with every one else involved, and deal with the obstacles of every kind that will arise? Even if your role will not involve the entire scope, it is rare for anyone's attention to fully encompass the complete set of skills that are truly needed to be successful in that role. Indeed, many of the most important skills are difficult to even describe.

More relevantly, even the best tools envisioned can not hope to assist with more than the trivial skills -- making more effective use of the other tools. When you give careful thought to the true nature and range of skills that a human typically uses in a software development project, or most any other endeavor, perhaps you can begin to appreciate just how little of a difference the tools really can make.

And yet, a great tool can dramatically boost productivity in the right hands. But the boost is only quantitative (less time), not qualitative (at least not much). Since quality is the point of this discussion, the conclusion follows.

-- RobWilliams

I think this is going to go around in circles unless we can agree on a common, observable criteria for evaluating the "importance" of the mind versus the tools. For example, you mention that an engineer would get fired if they couldn't use a calculator. To me this just highlights the importance of what you would probably call "trivial skills". They are only trivial because we expect people to have them. It's only when they don't have them that it becomes apparent how important they are.

As an example of this trivialization, there was a study of what was most important to people. They had things like money, respect, power, health, etc. Surprisingly, health was the lowest ranked thing. Yet, among sick people, it was ranked number one. After all, what are you without your health? Dead, I'd imagine. Health is obviously the most important thing to anyone, but most people have it, so they take it for granted.

So, we must come up with a criteria for judging the importance of something related to software development. I would suggest that a good criteria would be the time/expense required to achieve a particular result. For example, if you know your ABCs of computer science, writing a sort routine is pretty easy. I believe it took 20 years to get the first O(n log(n)) sort correct, but now it's 'trivial'. So for writing sort routines, a knowledge of algorithms is very important. Another example, using a tool such as RegularExpressions, it is possible to write information extraction routines very quickly and typically with good results. Before RegularExpression tools, it was difficult and error prone, and took a long time to get it right. So, for doing data extraction, using a tool such as PerlLanguage is very important. Here, having the knowledge is not enough, you still get a huge benefit from using a tool. In fact, you can forego much of the knowledge and still use the tool for a huge benefit. In this sense, programming is not in the mind (at least not 100%).

Here's a template of an experiment to evaluate X vs. Y. You've got two generic programmers (assume identical). They both have the base set of tools and knowledge. One has X but not Y, the other has Y but not X. Set them both at a particular task. The one who finishes first wins. Presumably, X is a 'non-mind' technology and Y is a 'mind' skill (but I guess the experiment would work tech vs. tech and skill vs. skill as well). You can include the achievement of a certain level of quality as part of the task, as well, if you want to control for quality. You can also vary the base set of tools/knowledge to make claims of varying strength.

Example, changes in computer languages over the years have had a huge impact, so much programming is not in the mind. The time it takes to finish a typical project of today with machine code versus say VB would be huge.

According to sources like RapidDevelopment, human factors among programmers vary at about 10:1 ratio. I'm not sure what tools are, but I think it's somewhere around 3:1. Certainly, people are key, but I think you discount tools too much.

I think you're thinking about this the wrong way. The better man will always win. He'll probably also be better at using (or possibly learning) tool usage. But the source of this is that he is the better man, not the other way around.

FWIW, when I hire, I always hire the man, not the tools. -- AlainPicard

The better man will always win? What does 'better' mean anyway? Does it mean 'the winner', in which case it's a tautology, or is there some other observable criteria? That's the point. The claim that ProgrammingIsInTheMind is empty unless there are clearly defined criteria for evaluating 'where' programming really is.

This thread reminds me of one of my favorite quotes from a great basketball player from the 1970's. He was a skinny "small forward" with a great shot and silky-smooth moves around the basket, but he wasn't a muscle man who could "bang" under the basket with other, bigger men.

His coach wanted him to increase his rebounding numbers and asked him to play more in the paint. His reply was...

"I'm an artist, not a house painter" - Bobby Dandridge

I've never looked upon programming as "just a job". It's my "art".

It is regrettable that in these times (as opposed to the early days of computer programming) it is the tools that shape the thinking, whereas in times past the thinking shaped the tools. Proprietary operating systems, GUIs, and IDEs all hide important details of how computers really work so much so that perhaps 80% of the world's professional programmers may not even know how computers work - thus limiting what *CAN* be done.

Always remember that sacred cows make the best hamburger. :) - BillZimmerly

What's the sacred cow here, though? I'd say it's that ProgrammingIsInTheMind. At least that it is 100% so.

On what basis do you claim that today the tools shape the thinking, and in the past it was vice versa? And what makes this regrettable? I'd like to be clear that I'm mostly playing DevilsAdvocate, but I think rightly so. There are a lot of claims made on this page with nothing to back them up, and no purpose given. Why is it so important that ProgrammingIsInTheMind? And what evidence is there anyway? What does it mean for programming to be 'in' the mind as opposed to 'in' the tools?

Consider this:

If the tools were of primary importance in determining the quality and quantity of programming output, then we should see solid trends as evidence. We should be able to identify many tools for which the majority of users are significantly more effective. This trend should be evident across a wide variety of user demographics. If tools are preeminent, then it should be rather easy to observe, document, and sell. It should be obvious to the majority that we should be consistently using some tools over other tools, with little basis for debate.

But what do we actually see? BadCodeCanBeWrittenInAnyLanguage, with any tool, on any platform. We also find GrandMasterProgrammers, who can produce high quality and high quantity in essentially any language, with any tool, on any platform.

Why is this? I suggest that learning "tool skills" is relatively trivial - most of us can read the documentation sufficiently enough to translate our intentions (e.g., generate Fibonacci numbers) into the corresponding computer activities (an actual program that generates Fibonacci numbers). What is hard are the "application skills" -- identifying and distinguishing between alternative intentions, and choosing between the available tools and among the available tool features, to produce a computerized solution with desirable characteristics.

Tool skills are easy to acquire (hence all the "Learn X in 21 Days" books). BadCodeCanBeWrittenInAnyLanguage because someone who has tool skills without application skills will consistently misapply the tools. Conversely, a GrandMasterProgrammer will typically have excellent application skills which they can quickly apply to any new tool that comes along; they will sidestep the pitfalls of misapplying the tool, resulting in a better solution faster.

Application skills are hard to acquire (consider the challenges of learning, applying, and eventually creating patterns). We can identify GrandMasterProgrammers, but we can not consistently create them. We are making progress in identifying the characteristics that make them so, but we have far to go. Meanwhile, creating additional tools and teaching them to people without application skills simply results in them misapplying another tool.

Of course, none of this is as trivially simple as my brief treatment might imply. There is significant variation in tool skills, and massive variation in application skills. Some tools seem to evade any attempt at proper application, while others make proper use seem almost natural.

Furthermore, measuring programmer productivity, whether quantity or quality, has been consistently intractable. We have made some progress, but we are no where near able to conduct "scientific" treatments of the subject.

Nonetheless, I find that the quality of a programmer's application skills far outweighs the choice or quality of the tools.

-- RobWilliams

Since you're not using objective, observable criteria for making the distinction, there's no way of confirming or denying your claim.

As I said, there are no objective, observable criteria for me, or anyone else, to use. Programmer productivity is currently unmeasurable. Therefore, my claim can not be verified, but it can still be meaningfully debated.

-- RobWilliams

I hope this isn't just semantic nitpicking, but it seems that this issue hinges on WhatIsProgramming?. If programming is generating a list of instructions to make a computer to what you want it to do, at least one tool is unavoidably necessary -- the computer. So programming can't be all in your mind.

OTOH, you can think of programming as identifying a way to solve a problem or accomplish a task in a form that is (ideally, at least) completely unambiguous. You don't need tools to do this; it's a purely mental exercise. However, this is a pretty broad way of looking at programming -- you could replace a computer with a set of literal-minded employees, for instance, and get the same thing. This definition may describe a real phenomenon, but I think my first definition is more useful, particularly to software developers.

Given that, it seems impossible for me to pull the computer, at the very least, out of the definition of programming. It is essential to validate your program, if nothing else. I can also think of times when I wrote a program a certain way because that was the only way I could find to make it work on the computer (or because it was the best of a few ways, none of which I knew about before I started trial-and-erroring on the computer).

(If you want to get really pedantic, I suppose you can think of the computer itself as an embodiment of a set of rules which someone else came up with, so this type of trial-and-error would be in your mind and, indirectly, in his/hers. But eventually, you get down to the laws of physics that all computers have to obey. I don't think we want to get in an argument over who created those.

That isn't to say that learning to use the tool is anywhere near as difficult as mastering the mental aspects of programming; for this reason, I agree with the folks above who say they hire people for their non-tool use skills. Tool skills are much more easily acquired than thinking skills. But divorcing programming from the tools of programming doesn't seem possible to me in a useful way. Besides, there's a lot to be said sometimes for throwing your mental work at the feet of your tools and seeing what happens. Does it compile? Do the tests pass? What does that tell me about the program?

ProgrammingIsInTheMind, but not exclusively. It is also in the computer, and in the relationship between the two. -- PhilGroce

Though this is all quite over my head and written by more skillful programmers than I, I feel I want to throw my two cents away at that genetic programming example, as I feel it is a straw man. Genetic programming does *not* produce code on its own through some purported stab at AI. In fact, it's sort of not AI at all. Genetic programming takes a quantized set of goals and a quantized set of things that may be changed, and iterates through random permutations by a set of quantized rules until it finds a solution set which provides a superior result to its other resultant solution sets.

Why is the difference important? One, because Genetic Algorithms were being touted as a reason that programming was not all in the mind; this is a fallacy, because all that the GA actually did was to work with what the GA's creator set down and roll dice until it found a good set, and 2) because that ignores the role of the programmer in determining the tweakable parameters, the goals, and the evaluation mechanism which told the GA how well its results came about.

It is true that there is no simple, quantifiable way of measuring how in-the-head programming is. However, as RobWilliams pointed out, there are many things which while not quantifiable are still quite debatable. Moreover, I'd like to suggest that the debate is what /leads/ to just such quantifiability, and moreover that if one desires for something to be measurable, that said debate is critical to the development of measurability. It is unfortunate when someone waves bad logic flags at something which was presented as an opinion (inherently unbound of logic) in order to disparage said opinion.

For my part, I am with RobWilliams in that programming is largely in the mind. Whereas tools can make programming easier, more productive, less bug ridden and so forth, those tools came from someone else's mind, and just as software which is isolated comes from the original programmer's mind, software which aids software development is the result of a mindset. All that has been identified here is that much software doesn't come from just one person's mind. For instance, much of the software I write today draws on the minds of Knuth, Stroustrup, Kernighan, Ritchie, Wirth, Wall, etc. I am not of their caliber, yet because of what came of their minds and those of so many others, I can write applications which would be out of my reach given machine code or assembly mnemonics. (And if you want to take it to an extreme, I am also indebted to the people who worked on the underlying technologies, to Babbage and Lovelace, to Al-Khwadzimi, etc. I would not have been able to invent mathematics, electricity, circuitry, or chip fabbing, either. But I can write a hell of a tetris.)

What this all boils down to, in my limited mind, is a version of Newton's quote: "If I have seen farther, it is because I have stood on the backs of giants." Whereas my sight is limited, it is furthered by the tools and paradigms I have been presented. All of these tools and paradigms stem from one or more minds before me. I will not be convinced that a piece of software is not dependent on a mind until a computer can be given a non-quantized task and have a result delivered. This does not mean GAs, NNs, or other misunderstood such tools, but rather something along the lines of a natural language query: "give me a module which parses this format into that format", providing no details but the formats involved.

Once you realize that what's in the mind of the programmer is the creativity used to lay the actual functionality out, not the amount of functionality which comes from tools, from libraries, or from languages, you realize that programming is indeed in the mind. -- JohnOrder

As I read this page I am struck by the amount of effort spent trying to say that if the tools are more complicated they begin to "do the work" of a person. If you are content with the specialized definition of "work" (as, say, used in physics) that means "amount of energy transferred" then machines "do work" -- however, in no sense are machines responsible -- so in fact the "work" must be assigned to a person.

A crane is a machine. Levers and pulleys and motors. It "does work" as a function of the applied skills of the crane operator. The crane operator is the responsible entity and thus is the one to whom the "work" is assigned. A good crane operator will do better work and more of it than a poor one. The tool is still a tool, regardless of how complicated it is.

Automation is machinery plodding along prearranged paths repeating "tasks" at greater or lesser speed, relieving people of the expenditure of effort. Still, the work is assigned to people. Automation is not a responsible entity.

Compilers are machines. Editors are machines. IDE suites are machines. The developer makes it happen. He is therefore the responsible entity. The work is therefore assigned to him, not the compiler. A good developer will do better work and more of it than a poor one. The tool is still a tool.

Do better tools reduce effort? Yes. Do better tools think? Only to the degree that submarines swim. The only way that programming is anywhere but in the mind is by arbitrary declaration. Machines don't think. Programming is applied thinking.

Programming is the application of thought to problems, including the contemplation of consequences of the decisions and actions mechanized in the code. It is an exercise in imagination governed by understanding.

Thinking, imagination, planning, contemplating consequences are all in the mind. Programming is made of that stuff. Programming is in the mind. -- GarryHamilton

I agree with much of what you say, but I make the following observation, largely echoed above. A person may solve difficult problems, or create marvellous poetry, but without effective communication they give no material value to the world. You may be the greatest programmer by your definition, but without a computer your programming will produce no material value. If your computer has a front panel with flip switches, a load button and a Run toggle, your output will be rather less than my output using Python, C, C++, Smalltalk, Haskell, Lisp, and a great development environment. The tools help, the right tools help a lot.

Well said, GarryHamilton.

It seems that our detractors have only one real issue--that the tools do help and they need to be given proper credit. Fundamentally I think that we all agree that the tools play a part. The question of whether ProgrammingIsInTheMind hinges on the relative degree to which the tools contribute.

I suggest that our industry currently credits the tools far more than they deserve, and nearly to the point of ignoring the person using the tools. The literature, the media, and the hiring process all heavily emphasize the tools in every practical measure. I would estimate that the tools are emphasized somewhere around one to two orders of magnitude more than the ability of the person to use them.

I assert that the emphasis should be reversed, and that it is so among those that recognize that ProgrammingIsInTheMind. I further assert that a person's ability can easily be more than one or two orders of magnitude more relevant to success than the tools that they use. In short, a person's ability to think and apply tools is so much more relevant to success (given any workable criteria) than the nature of those tools, that the tools can be all but ignored.

-- RobWilliams

I would certainly agree that ProgrammingIsInTheMind. The actual tools used are just that, tools. It's not the tool that makes a good programmer, it's the ability to recognize which is the right tool for the job.

The object of programming is to solve a problem. Before I even touch the keyboard, I sit and think about how to solve my problem, and what the code needs to do, and think or write a few lines or half a page of pseudo-code. When I have a pretty good idea how I want it to work, I start to convert it to real code, writing functions or methods to do the things needed to solve the problem. Programming languages are interfaces that allow programmers to tell a computer how their solution works. Familiarity with a selection of languages allows me to think through different approaches to getting a working solution, and to select the language that will allow me to get there in the simplest way.

If I'm writing a web-based database, I'd use Perl or PHP, as they're designed for that job. If I were writing a least cost network solver, I'd use Java or C++, as OOP makes this very easy. If I were writing a small phone book application for my Psion, I'd use OPL, because it's designed for interfacing with that machine. Anything involving a lot of calculation, such as geophysics data plotting, would be best done in a functional language, because it's the best way to express a mathematical solution.

The only tool a programmer really needs is a good multi file text editor that they are comfortable using and know their way around. It provides a single interface for all the languages you'll ever need, and you can even write home to your mother with it.

My mates would irrefutably summarize this, when we were the only ones working late, by reminding me that bottle of whiskey is not going to drink by itself. -- LB

In regards to people saying that programming isn't in the mind because it requires tools (the calculator argument), I'm curious. What discipline then is all in the mind? Is philosophy? We need our speech organs (communication tools) or written language to convey them. Painting maybe? You need brushes, canvas, and paint. No discipline that affects the real world will go without some kind of tool. This does not mean that the trades themselves are primarily physical and mechanical.

Painting is a good example. The rote act of placing paint on canvas is something anyone can learn. Doing it well is something anyone can learn with practice. Making those patterns you place *meaningful* and *evocative* is what separates a real painter from a kindergartener. Give a young child the brushes of a master, the finest canvas, and rare paints and inks. You still get finger painting.

We know good software can be made without all these modern, high-quality tools we are creating. It has been done. We also know that bad software can be created with them. We can look to examples in our own lives. In painting, rare inks, fine canvas and good brushes make a good painting better (or faster), but they don't do a whit if the artist wasn't any good to begin with.

Going even further with this idea; ask yourself how you remember quicksort. Do you think of quicksort in terms of the first language you learned? In terms of what the machine's registers are doing? In terms of some mathematical notation for it? I know that is not the way with me. I think of quicksort in terms of how it works. "You take the array, pick a pivot, then recurse, ordering as you come back up." When I write it, I mentally translate it from my abstract representation to the language I am working in. Good tools can help me prevent errors in this transcription, or they can help me find trivial errors in my logic. They can't tell me my logic was utterly flawed to begin with, that's called the HaltingProblem. :)

As far as I can tell, ProgrammingIsInTheMind. -- DaveFayram

I agree with your general idea, but it's a scary analogy. Any graduated CS are expected to have learned the theories and foundations of logic which our higher level daily thinking implicitly sits on. I, for one, would probably never keep such formal notational knowledge on my RAM, but I can bet my ass it's on a big tarball somewhere. I might have, however, backed it up on a floppy-disk I must've left around. Maybe it became so natural I may have deleted the intricate analogous associations and just "got it", somehow.

Although, I gotta be honest with you, as much as this amazing gift seems to be stuck here, there are times when TheProgrammingInMyMindSmells?. :) -- LB

CategorySubjectivityAndRelativism, CategoryPsychology