An Under-Appreciated Fact: We Don't Know How We Program | Hacker News Reader

An Under-Appreciated Fact: We Don't Know How We Program

paulspontifications.blogspot.com

33 pointspaulajohnson28 comments

I think he needs to read 'Zen and the Art of Motorcycle Maintenance'. Programming, like architecture, medicine, or sculpture, is an art. Those at the bottom of the profession see only the mechanical process of churning out code, drawing a room, prescribing medication, and making a pot from clay.

Those at the top are, for lack of a better term, at one with their profession, and programming is certainly no different. A good programmer can feel, in a very visceral way, the difference between good and bad code, in the same way that the average person can feel the difference between Michelangelo and street graffiti. I consider myself to be only a very mediocre coder, and yet every now and then, I see a program that is just... beautiful. Aesthetically pleasing. And I couldn't tell you why.

Things like that can't be diagramed or taught; it's up to the individual to grow that seed of what Pirsig calls 'Quality' within themselves.

You should add music as a comparison, since I think most people seem to be able to relate much better to it than say, sculpture. It may help with the analogy a little.

There's a well-known process for creating paintings. It's practiced by Thomas Kinkaid, a well-known, highly successful artist. For some definition of success...

You mention a well-know process for designing a house. There is none that I know of, other than the word "design".

My approach is to consciously absorb as much of the problem at hand as possible, then let my subconscious crunch on it for a while, the length of time depending on the complexity of the problem. Coming up with the big concept for a large design, both building or software, can take a few days if its revolutionary, or a few minutes if its not. The key is to have a process that helps you leverage the power of your subconscious. Trying to force a solution in your conscious mind on a harder problem can be both painful and a waste of time.

Exactly, he throws around "curing a disease" and "designing a house" as if they were easy. News flash, architecture is a 5 year program just to begin the apprenticeship to get your license, and you need a doctorate before you will start working on a disease. All that time doesn't teach you HOW to do your job, it teaches you the information you need at a minimum to start learning HOW to do it. Computer science on the other hand can be learned on your own or its a 4 year program, and then you get to that part of learning. Don't mistake the fact that there is less material to learn for saying it takes more intuition. It just takes less time to learn the material in a discipline that has been around for 40 years than one that has been around hundreds or thousands.

Don't confuse software development with computer science.

How much original thought is going into the floor plan of the next McMansion to be built? Or the next 3-storey steel-framed office block? Are these truly developed from scratch by deeply original thought every time? I admit I have no experience of the building industry, but I seriously doubt it. I believe they are created by following standard recipes and checklists (square feet per desk, maximum distance to restrooms, maximum distance to window). I work on a business park full of 3 storey office blocks. They are all minor variations on the same theme. I live in a housing estate where all the houses are also minor variations on the same theme. Thats what I'm talking about. Maybe architects don't design these buildings. Maybe I'm talking about a more junior part of the construction industry. Either way, it completely lacks any originality.

I work in an office that has a doorway that opens onto a brick wall. Fortunately they knocked a new doorway into another wall before walling up the old one, but it's a bit of a hack.

Even architects find it hard to plan for growth it seems :)

I think there are software analogs of your office park.

You hit on a good insight in the essay: we don't know how we program. But I think you incorrectly assumed that this is unique to software development. Instead, I think it's an inherent part of any job that requires problem solving.

I think the ratio of meaningful architecture to buildings is about 1:10,000, maybe even more. To make architecture, almost exclusively original thought is needed. I spent most of my University days unlearning preconceptions about solutions to building problems for that very reason.

Instead of comparing that to software written, compare it to software used. My copy of MS Office looks a lot like my neighbor's, my uncle's, my father's brother's nephew's cousin's former roommate's. While there are some unique combinations, the pieces are largely the same.

The McMansions and office blocks aren't that different from 95% of people using Windows or Mac. It's just more painful in architecture because it's so visible.

Think about other important areas of human endeavor: driving a car, flying a plane, running a company, designing a house, teaching a child, curing a disease, selling insurance, fighting a lawsuit.

driving a car, flying a plane: These are extremely poorly understood tasks, but fortunately parts of the average human brain are pretty good at things like that.

running a company: Smart people fail at this all time.

teaching a child: Why are so many people unable to remember the math they learned in grade school? Why are we engaged in a public debate about the value of teaching to standardized tests instead of some less well-defined but apparently better approach?

curing a disease: Come on, new methods and approaches are constantly being invented in medicine! We have no general way of doing this.

>Why are so many people unable to remember the math they learned in grade school?

You mean like 2+2 or 9x5? Most people forget the advanced math that they learn in high-school, but the basic stuff is pretty well ingrained into the average subject, accounting for variations, of course.

From the article, I recognize that the author is differentiating programming, that is to me "coding" from all the other activities in the software development lifecycle, as he mentions in his third paragraph. I assume that many of you also recognize this, but that some might not. I bring this up because in replying back to the point of the article and whether or not we "know how we program" it is important to define what we mean by programming and what boundaries we place in the activity "programming" which is different than the activity "design" or the activity "testing."

This isn't really true for all software development. If you write a detailed design, the process for writing the software is as simple as "write what the design says you should write, then test it conforms" It's only true for the sort of software development where you design while you write, AKA hacking.

I'm not against hacking per se. I'm doing it right now. But to take it as the de facto way the software industry functions is wrong. Hacking has certain problems, like unanticipated problems tend to stall the process (My own recent encounter had me blocked for three days, trying to think of an adequate solution to the problem of how authentication should work in an environment where HTTP servers and clients are essentially "decoupled", that is a solution to the problem of where presentation and application data are coming from two different sources, how does the data provider verify the presentation logic is trustworthy? It's a hard problem to which I have only a partially satisfactory answer... but I digress.)

The process for writing code tends to be unwritten, simply because in the best case it is so trivial that writing it is an insult to the reader. I guess the industry's collective problem is that the best case happens so seldom.

So where do you think the "design" comes from?

<i>It's a hard problem to which I have only a partially satisfactory answer... but I digress.</i>

On the contrary, you touch the heart of the matter. You say what you are doing is "hacking", with the implication that there exists some other process by which your problem could be solved. Can you tell me what this process is, and why you are not following it?

You’re making a basic assumption that your design has sufficient detail to produce the program. The problem with this idea is your moving programming to the design phase (using pseudo code) but you’re not eliminating the act of programming.

AKA, I need a function called add that adds each element in an array and returns the result.

Now what data type is in that array? What should you return if the array is empty or null? etc.

The design phase is like map making. You can't make a completely accurate map at any scale, or that map would be the size of what it represents.

So, you can't make a design doc detailed enough to make the programmer make zero decisions, or you could just compile that design doc.

Yes we do.

Perhaps not all schools teach it this way, but my computer science education included a semester of lectures that started us off in the process of Stepwise Refinement.

In S.R. you start with a goal and progressively, or step-wise, refine it until you are at a level in which it is obvious what code should be written, whether it be an assignment, expression, loop, functional call etc.

I believe S.R. dates from Dijkstra and the Algol-W period.

It seems to me that you ignore creativity. You don't want to put this in a process.

>> The fact is this: there is no process for programming.

I disagree. There is a process, but it is so basic we may not realize it:

1. identify the big problem

2. break it down into smaller problems

3. solve the smaller problems

4. repeat as needed

Step 3 though has no process, hence, the entire function has no process. (None that can be useful at least.)

Your process is so vague, it's like saying the process to get from Seattle to Hawaii is:

1. Leave Seattle.

2. Travel.

2. Arrive in Hawaii

That sort of divide and conquer method does not work well for all scenarios, and certainly will not get you the optimal solution for all scenarios.

Consider writing a connection counter for linked in. How many connections do you have, and how many 2nd level connections do you have through those people. If you decide to break this down into smaller problems, you are going about it the wrong way in all likelyhood. An optimal solution will involve a dynamic programming algorithm, which solves the entire problem in a tricky way (a clever hack).

There are many processes. Some of them call themselves software development methodologies, some don't. Some step-ones:

* Make a list of use cases

* Grab a stack of 3x5 cards and start writing nouns on them

* Check to see if someone else has partly or completely solved the same problem already

* Write down the basic data structures associated with the problem

* Identify a minimal command-line program you could write to investigate the hardest problem(s)

* from __future__ import solution (or: M-x solve-problem)

The completely described process for buttering bread is of sufficient complexity that we should never attempt to make a process for developing software. Unless you keep it simple:

Step one: Look medusa in the face.

Any really good skill is completely organic this way. Your brain fuses a whole bunch of thoughts, instead of producing just one that you can put into words, and you just do it.

That's the fun part.

This is basically right but you're wrong in distinguishing programming from other design tasks. There's never a "process" for design; there's only the meta-process of creativity.

Reply on news.ycombinator.com