Let's get a little more specific...

Most code sucks because the programmer:

  - didn't name his variables what the really were
  - didn't understand variable state
  - didn't understand variable scope
  - didn't understand the basic concepts of iteration
  - didn't understand any of the algorithms he needed
  - wrote the same lines of code multiple times
  - didn't know enough about the language to find a better construct
  - didn't understand concurrency
  - didn't understand fundamental data base concepts
  - refused to follow well worn standards
  - didn't have any well worn standards to follow
  - built code on top of hopelessly designed data structures
  - didn't understand deeply enough what was going on under the hood
  - built to requirements that changed too dramatically to recover from
  - didn't even consider the concerns of the "next" programmer

  - was just good enough to get "something" (no matter how bad) deployed on time

This usually happens when the programmer at fault is really smart but still hasn't learned that at some point in the future, someone needs to come along and understand the code he/she wrote.

Maybe we need editors?

It would be nice to have the senior folk guide the developer as opposed to handing off a blueprint and getting out of the way. (Not that its like that everywhere, just some places I've been)

Linus has deputized a few people to commit without his review, I believe.. but this is after years of working with them.

*professional means good quality balanced with maintenance and time available during development.

Just putting this out there, besides the undoubtedly negative sentiment it will bring. Try pairing. You don't have to do it all the time, but if you are working on something that you have to think about, bring another developer over. The best way to ensure what you are writing is good is to get another set of eyes on it. Preferable a set that will actually need to do something with the code at some point.

Besides, you could always send a message to the author and ask if you're interested.

1) Every check in required a code review by a peer. In your commit statement, you specify who reviewed your code.

2) If a senior programmer wrote code for a feature that wasn't too complex he would get a code review from a junior programmer. The junior programmer doing the code review, learned what good code looks likes and second learned how to give feedback in a constructive manner as he was talking to someone with more experience than him/her.

If you're writing something totally new, you usually throw ideas and mocks (either UI or code-structure) until you decide on a solution that works.

I've found this to be pretty good at helping newer engineers write good (and idiomatic) code without hindering development speed much.

On the other hand having the Architect act as editor after the code is written not only provides the "code review" function, but it provides the additional benefit of providing the Architect with feedback on the original design, and how the abstract design ideas are translated during the construction phase.

I think it would improve communication on both sides (Architect and programmer) as well as overall quality...very nice...

It is not in the interest of the programmer to allow others to understand his code. That would make him easily replaceable. I know quite a few consultants who write like that on purpose and secure their jobs this way.

Programmers are also not rewarded for clean code. They are rewarded for quickly delivered code. Beautiful code that is delivered two weeks too late is usually a bad idea. This is business logic.

It is easy to measure, how long it takes a programmer to develop code. It is much harder to measure, how much time is wasted to maintain badly written code.

Much speaks against writing clean code, little is in favour. The only persons interested in this are later maintainers and academics.

Lets face it: whats wrong with code that is a bit messy but does its job correct and quick? If the author himself has to edit it and does not understand it anymore, then he/she will refactor. If there is no need to touch this code because it does its job, who cares? If the original author is already gone and there was no time to make someone else familiar with his code and style, think about how people are treated in your company and refactor management instead of code.

Also, we practice code review at our work. That is definitely a way of fulfilling the role of being editors.

    - didn't have a frickin' clue what the code was supposed to do

Being open to refining your idea or pivoting as you go is a horse of a different color.

But trying to write code without a clear purpose in mind is the equivalent of monkeys banging away at typewriters, to return to our "writing" metaphor.

I wonder what the average startup codebase looks like?

Code gets complex as hell very quickly. If it was building a house, it would be built in a week and architected on the fly. The person mixing the concrete, who has to know the concrete grade and drying time, also has to know that the upstairs has just shifted and now the load is too much on the center beam.

The reality is that, unless your dealing with tiny apps, that "bad programmer"? It's you.

That said, there are programmers who are legitimately lacking both in basic skills and desire to attain those skills. It's orthogonal to the problem you're talking about, but these people do exist, and they're not as uncommon as one might hope. I can teach the difference between pointers and references; I can't teach you to care.

Needless to say, it failed. The guy was irreparably lazy, and trying to get him excited about building the things we are fortunate enough to get paid to build only made him try to put me under a bus when he got the chance. I had to let him go, and have slept better ever since.

For the most part the Django codebase has clean code, and its rapidly understandable. Where that's not true is the original SQL db, and the Forms library. Elsewhere its a dream to hack with.

I'd also praise the codebase of SQLite, and Lighttpd---these two are very clean.

teams reacting to changing or poorly-understood requirements (think enterprise and defense software contracts) have a much harder task. nobody has solved the problem before, nobody understands the problem, and project managagement is typically forced into waterfall in order to make sales, so its not like there's time to redo things that get duct-taped together, if the duct-tape holds.

The worst writing I've seen:

* is ungrammatical to the point of incoherency

* loses its train of thought mid-sentence and talks about something unrelated

* is full of irrelevant details

* simply ignores everything above the sentence level, producing mere text, no argument, story or whatever it was supposed to be

Not really the same failure modes.

Really? Because except for the first one (which we have compilers to thank for), your three remaining points apply equally well to a lot of code I've seen.

Who has not seen a piece of code that is so bad they don't even understand how it can compile, coming out of a newbie?

Doing strange undefined things in C comes to mind as a usual case where this happens.

"How do I do what I want here? Aha, someone already wrote ExactlyWhatIWantHere.... WTF, it doesn't even compile? But how is anyone using it? Oh, it's not being used anywhere? How the heck did it get here? Ugh..."

In college, my CS 2 class was taught by a professor very different than the rest of the teachers there. He wanted all of your programming assignments on paper[1]. Then, you'd get it back with every possible bug marked in your program, and he very rarely missed any[2].

That was the first time in college I thought "I really need to learn how to do that!"

I went to a state school, so maybe all you guys with your degrees from fancy schools wouldn't be that impressed, but the difference between this professor and the rest there was gigantic. (He retired that year in a round of state-wide budget cuts, so that's the last class I had him.)

[1] A lot of the other teachers wanted you to hand in binaries so they can see it run. Sometimes with the code, sometimes not.

[2] I actually don't know of any case where he did, but I'm not saying "never."

tl;dr Pretending to be an expert until you actually are seems to be one of the fastest way to learn something.

I've decided my new method of training employees will have the most recently hired employee train the new hire.

If he missed it, chances are, pretty much any student would have as well.

I've also noticed that peers struggling with implementing solutions usually have an inconsistent language.

In the class it was often referred to as psudocode, but unlike psudocode in examples in random books/specs, it had a real syntax and you had to put everything you would in a real language or you'd get points off.

It was a great way to learn programming (and teach it too).

*(To disambiguate for the left cost people, GT isn't like ITT, it's of quality closer to Caltech, but much cheaper. Best salary for the tuition school in the nation apparently today)

Most people passed; it was not a "gotcha" problem, you just had to be able to read carefully and pay attention to detail. Andersen hired a lot of liberal arts majors who had done a lot of writing, I was one of only a few in that group who had done a C.S. curriculum.

A couple of my programming instructors use a build system that compiles your code with three different compilers, and runs it with various tests and diffs the output with a master copy (or sometimes stress-testing and tracking memory/time/probe counts). One of them also ran valgrind on submissions. So you'd get your "accuracy score" on the same day or so as the programs were due, then the teacher/TAs would grade the source and dock points for bugs not found in the test, supreme ugliness, etc.

The opposite can be true too, I expected to get tanked at CMU and did pretty well (3.65 gpa, senior thesis, going to Facebook). If I'd gone to Ohio State like the majority of my peers from High School (Hilliard Darby High School has sent a whopping two people to top tier engineering schools (CMU and MIT) and none to Harvard) and even gotten a 4.0, I never would have believed I was more than a "talented state school kid."

At the end of the day, it's on you to put yourself in the most challenging situation you can possibly survive so that you can learn the most. Sheltering one's fragile ego never did much for anyone in the long run.

(former small town kid, went to Carnegie Mellon and realized I wasn't "the smart one" any more)

That doesn't really mean that these things are any more similar than two random areas of human activity. Our brains are just good at finding analogies, finding analogies is like spotting patterns, we see them even when there aren't any and when there actually are some their appeal is difficult to overcome. And if you know two subjects well you have more material to cherrypick analogous things from.

An old friend of mine had a master's degree in French literature. She used to live in Ottawa, Ontario and was fond of a pizza place just across the river in Hull, Quebec. One day she called to order a pizza, and when it came time to ask for it to be delivered she realized she didn't know how. She asked if the pizza place could put the pizza into a car and drive to her house with it.

The order taker replied, "Oui, delivery. Nous pouvons le faire."

Edit: - I should point out that the French word for delivery is livraison; but like most languages, day-to-day Quebecois French is porous enough to borrow words from other languages where expedience warrants. Hence le week-end (not le fin-de-semaine), frencher (to French kiss), etc.

As a further digression, I should point out that it seems less common (i.e. less acceptable) to drop anglicisms into informal Quebec French than in Europe, where native French speakers do not feel threatened by a dominant continental Anglo culture. I was amused on a recent trip to France to learn that the French word for wifi is "wifi" (pronounced wee-fee). Since wifi is short for "wireless fidelity", a more canonical French term would be something like fidélité sans fil.

Or at-least I think that is what it means.

As a beginning-programming instructor, my students have little difficulty understanding language syntax and operation - much like the "language lawyers" mentioned. Their recurring problem is not correct syntax, it's internalizing the process of expressing a solution to a problem using that syntax. They have few unto no examples of what a program - a real, functioning, well written program - looks like.

Indeed, programming is writing: it's expressing the solution to a problem using a formalized language. Understanding how the program works is one thing (and yes, all too often this is a problem); a good program also expresses why.

A 3 year old writing a novel won't succeed because, despite the ability to speak, he does not comprehend the process of concocting and presenting the story; all he knows is the minimum needed to just read one. He's not going to write good novels until he reads lots of good novels, and groks the literary structure and process of having and expressing an idea. Ditto programming: students may know the syntax, but they don't grasp the notion of "writing" because they haven't seen any decent examples.

Rosettacode.org may be a good starting place.

Thanks for the article, I may finally have identified the gap in my teaching. Now to find concise examples to fill it with, as the curriculum does not allocate copious time for reading lots of coding examples. Anyone have links to good examples for beginners regarding fundamental concepts? I don't mean syntax (I teach that well enough), I mean elegant uses akin to poetry or short stories. IOCCC (a moment of reverent silence for greatness ended) has wonderful examples of cool things in minimal code, but commands obfuscation. Anything akin to IOCCC for good readable nifty code?

(the original seems to be down)

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-9.html#...

Essentially, "computer science" is a myopic name for what is really "process studies." It just so happens that defining processes to run on computers is forwarding the field more than any other. But in the distant future we will all understand the field to be about abstractly defining processes i.e. a series of repeatable steps to accomplish a task. Which would be independent of the mechanism used to execute the process.

Therefore programming is the act of defining a process. And programming languages are what we use to define them.

It is covered fairly intuitively in the first few minutes of the SICP video lectures as well:

http://video.google.com/videoplay?docid=5546836985338782440

Actually the name isn't myopic at all. Computers are basically entities that follow instructions. There was a time when the definition for the word computer was a person who did computation processes.

http://www.amazon.com/Information-History-Theory-Flood/dp/03...

That's how CS started. Long before we had anything recognizable as computers, we had the likes of Turing providing formal mathematical formulations of abstractions that would be realized later.

It is easy to find differences between good writing and good code: Uniformity in code is good, while uniformity in prose is bad. In writing, a large vocabulary is an advantage, it's difficult to see if that is the case in language. In programming, proper abstractions are essential while I can't really see the equivalent of that in writing.

As far as analogies go, I can't see how this one is much better than others.

    socket.close(); window.close(); file.close()

It's one way the may be distinguished from analogies.

"He rushed to the exit, leaped down the stairs, and ran for the train."

Better programming is to factor out the action:

    [socket, window, file]*.close()

    [socket, window, file].each{|item| item.close()}

It sort-of exists in Lisp-inspired languages (anything from Arc to Lua to Io) with appropriate boilerplate, for example:

    function apply(tbl, func)
       for key, val in ipairs(tbl) do func(val) end
    end

    apply({socket, window, file}, function (item) item.close() end)

$_.close() for $socket, $window, $file;

   [socket,window,file].forEach(function(o){o['close']();});

  [socket, window, file].map(&:close)

    class A{
      def close(){println "closed"}
    }
    def a1= new A()
    def a2= new A()
    [a1, a2]*.close()

If not, you just say "consistency is good" which also applies to architecture, painting and so on.

But, and here is the thing, the hard part is not learning the words and the grammar, nor actually writing in the language using the said words and grammar.

No the hard problem is figuring out WHAT to say and HOW say it to make others (humans or computers, depending if it is a natural or programming language).

In terms if human language it is about formulating a narrative story that presents the problem and the solution to the reader.

In terms of programming language it is about describing the data structures, data transformations and transactions/communications needed to perform the task.

This is the hard part and that is what separates good writers and good programmers from their lousy counterparts.

BTW: I hope this was parseable.

Edit: Would someone have the courtesy to mention why they are downvoting?

Both in programming and writing, the actual writing part is the easiest part. And while bad programmers can make a program work, and bad writers can tell a story, it takes good ones to do it coherently, efficiently and enjoyably.

It's not the exact same thing, which I don't think anyone is saying, but there are some similarities there, especially the aspect of writing readable code.

In contrast, in the past, programs to do Newtons method or compute trig tables were often the full scope of a program. You certainly never had a Halo 3, Windows 7, Google Search, or WordLens application written even 50 years ago.

Good literature isn't about automating increasingly sophisticated processes. Programming is all about that. This leads to increasing complexity of programs, where the goal of software engineering is to abstract/hide as much of the complexity as possible.

The only things they really share in common is that they're both written in text. If programs were written by soldering wires no one would make such odd acquisitions (do EE relate circuit design to writing literature?).

I think we give this slashdot author far too much credit.

I think this aspect of it is what the slashdot author is mostly talking about, suggesting that if you write code as if you were writing to the next programmer, rather than to just the computer, your code will be better for it.

Clearly, programming and writing isn't the same thing. Nobody is claiming that and, guaranteed, nobody here thinks that. It's a metaphor and like any other metaphor it breaks if you bend it enough.

But the important part of my post was that programming is about automation. It's not about weaving a story, even for the next programmer. It's about building abstractions for automation. And yes, its important for other programmers to build on top or service it, but given a choice between the right user experience and dev experience, user experience should usually win (although there will be some exceptions).

IMHO, any dolt can produce code that only works. All too often I have to sift through horrible code that works, and I think the author is right in that if the programmer who wrote that (sometimes that's me, sometimes it's someone else) had had the next programmer in mind when he/she wrote it, it'd be much less of a pain.

If good code were written only for people there'd be no quicksort. No fast implementations of FFT. Probably no fast versions of memcpy. The reason is that coding is not primarily about writing for other people. Look at Donald Knuth's code. Extremely well-written, yet certainly doesn't stand on its own. And there are certainly design decisions that optimize for both asymptotic complexity and small constant factors.

My point is that analogizing this to books does no one any favors at all. We're having a conversation on the merits, w/o having to allude to neither haikus nor novels, nor gerands, nor foreshadowing.

Programming is difficult, even for code that "only works" (you'd be a billionaire if you could find a way to quickly produce code that "only works"). It has little more in common with writing than tarot cards -- which also are made to be read by humans.

That's what the author wrote.

Lets take another (stupid) quote from the author: Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel.

There's no absolute nature regarding the state of ability for any given task. There is no way to map fluency in English to fluency in any other domain. It just doesn't make sense.

This is just all around lazy thinking. It's buying into a metaphor because you either don't have the ability or desire to actual think about the real issues. edw earlier in this thread actually took a little time to think about the issue. This slashdotter made no effort, had no substance, no data, just a cheap metaphor that fell apart upon first glance.

or mistaking the rest of us for complete morons

How's this for lazy thinking -- I use duck typing.

It's like adding gravy to mashed potatoes. Sure it may make the potatoes taste better, but now you can't put the gravy back in the gravy bowl, can you?

You might better compare the films of 100 years ago to the films of today to see an increase in complexity similar to the march of programming progress.

When you're writing a novel, you do.

In programming, do you have to worry about phonology, slang, or number agreement?

The guy's deeper point is that programming is a language acquisition task and we would do well to take the rich set of lessons from ESL and foreign language learning and apply them to CS learning. Will all of it stick? No. But there is fertile green field to plow here.

Sounds like you're in the wrong field. Just because you find the thing a drudge doesn't mean others feel the same way, and personally I find the cynical 'well real-world programming is ultimately crap' specious and poisonous - to you it is, to me it is not. Why are you still doing it? And why are you stating it like it's some immutable fact we are all avoiding somehow?

Personally, I find programming a wonderful, amazing thing even when working on the most incredibly dreary software, and of course considerably more so when working on the more interesting stuff.

This kind of stuff is unfortunately common and applicable any + all professions + activities out there. If everybody listened to the nay-sayers, nobody would have tried doing anything.

tl; dr: haters gonna hate.

I'm also not acting under any illusions here - there are times when it's miserable, the key is whether the overall thing itself outweighs those moments.

Also be cautious as to whether burn out is involved... that shit is pernicious.

:-)

If that's what you really think then maybe you should go become an ESL teacher in Japan, or at least try a new position that may fit you better. I find good programming roles to be highly enjoyable, challenging, and rewarding jobs. Sounds like you might need a change - shake things up a bit, re-examine assumptions and that sort of thing. It's very bad in the long run to hate your job.

They are nothing alike, and I would be honestly surprised if we even used the same part of our brain for processing the grammars of human languages as we do for the rigid, formal computer ones.

If this were true, how come not all great programmers are great writers? Why don't more great programmers become fluent in other spoken languages?

Why doesn't Mark Twain have any novels written in French? Why would you hold computer programmers to a greater standard than any of the great authors?

I imagine most programmers are great writers from a structural point of view. The rest is emotion. Programmers know how to appeal to machines, but often are not able to connect with people in the same way; something that extends beyond writing, if stereotypes are any indication.

There are those adept in theory that can't practice well, but that's because to practice the art means dealing with a plethora of hacks, exceptions and miscellaneous trivia completely unrelated to the core problem at hand.

Personally, I don't think the answer is becoming 'fluent' in handling the exceptions and idiosyncrasies of the chosen language, framework and platform. Rather we need to work on building a notation that provides better abstraction mechanisms.

Your last sentence could be rewritten "It is better to express things in as few ways as possible", or "Having fewer ways to express something is better". English, however, allows you to omit the main verb for the causation in a parallel construction, you were able to write it shorter, and with a 3-syllable climax after a pause at the end for effect.

Shouldn't programming languages also provide many different ways to express things?

Without looking at an example of working code, how is it possible to say that one particular phrasing is so obviously better than any other that it and it alone should be allowed to exist?

I appreciate in Perl very much the postfix conditional expression syntax because it exploits the end weight linguistic property and allows me to emphasize the most important part of the statement when the situation warrants. I believe that makes my code clearer because it looks different from the Algol-standard conditional syntax.

Yes. The ordering of elements in a sentence is its "thematic" structure, just as important in communicating as the "transitive" structure of sentences, i.e the relationship between nouns, verbs, etc. Most programming languages copy the transitive structure of natural languages, but not many allow the programmer to freely choose the thematic structure.

Perhaps there'll only be a small number of languages that people learn, so people will have a "native" programming language in the way people have a native natural language.

    die unless $file;

    if (!$file){
      die;
    }

Is simple.wikipedia.org really better than wikipedia.org for the average English speaker? If your only argument is that simpler language lets more people understand, why bother saying words like "unknowable"? Why not say "not knowable"? Isn't it superfluous to have these words in your vocabulary?

Being able to accurately express an idea quickly has it's value.

I work with about a dozen Perl developers and there are only a couple of us that know a significant portion of the language. Problems occur when someone uses a less common piece of syntax and no one else knows what it does. Everyone has their favorite ways to do things and people tend to have very strong preferences. This makes for code that is much more difficult to understand.

English is a far more complex topic. I am not sure where to even begin. I do think that it helps for a group of people to share a common set of language prescriptions.

Was this incorrect? Was explaining your point of view inefficient or causing problems in understanding? I think you inadvertently showed how expressive language has enormous benefits, even if people can never understand it 100%.

You don't have to know all of those to be a good Perl developer. You have to know how to read the documentation.

Everyone has their favorite ways to do things and people tend to have very strong preferences.

None of that sounds like a programming language problem.

Having more ways a statement can be interpreted does not make it easier to identify the correct interpretation, so I don't think this is really a reason people have a harder time understanding code or mathematical notation than they do their native language.

And mathematical notation offers plenty of ways to express a given statement (transform with De Morgan's law, contraposition, shuffling and negating quantifiers, etc.).

The old 'write down how to tie shoes' or 'write down how to make a peanut butter and jelly sandwich' projects show just how hard it can be to pin down exactly what needs to be done to do seemingly simple tasks.

The writing is merely how to you transmit the logic.

  The writing is merely how to you transmit the logic.

Take the following:

  @post.comments

  $this->post->findDependentRowset('Comment');

The funny this is that the same is also true for mathematics.

Mathematicians writing proofs and theorems are communicating with other people, not (usually) with machines.

Mathematical notation is s means of human-to-human communication. Yet anything but the most trivial math soon becomes inscrutable to the untrained. As far as I can tell, mathematicians are mostly happy with this. The language used allows for precise, compact expression of complex (i.e structured) ideas. That understanding requires training and rigor is not considered inherently bad.

For whatever reasons the same terseness and concision is derided by many programmers who seem to believe that ease of understanding by the moderately skilled is highly important.

And I agree with that. The best way to get better at something is to do it. Other things can help you along and accelerate your improvement, but they don't work on their own. You have to do it.

Writing requires "logicking out" the likely responses of the reader - and the pseudologic of parsing by the human brain (see Dan Ariely's "Predictably Irrational: The Hidden Forces that Shape Our Decisions").

You can have a program which is beautifully structured, and factored in an extremely clean way. But what happens when you have to modify it in response to a change in requirements? And what if you have external code that depends on the existing interfaces? At that point, the skills needed to be a good programmer are quite different from that of a writer.

But novelists only have to deal with that for maybe a year or so; programmers have to deal with this problem for potentially decades, and at that point it's a completely different problem just because the scale is different.

Programming definitely requires writing skills (expressiveness and concision most importantly)

However it's about structurally combining that writing into maintainable code, using idioms of the past to build upon to gain error free use. It's about mentally modeling what parts of the machine are doing, and correctly understanding those interactions. It's about risk assessment, experimentation, knowing when to call something quits. It's about going back over old world to do it a better way. It's about decomposing a complex process into many simpler steps. It's about reading, reading lots in fact, usually reading to find out details of the bits of your mental models.

Programming really isn't anything other than programming. It's not any field like it or near to it that knowing a nearby field plays well into it (electrical engineers can make horrible programmers but brilliant electronics guys same goes for web designers), but lots of other skills parlay well into getting you partway into the panoply of skills that get you past the finish line.

People make bad programs code when they only have part of those skills (or when they do not put out the effort to use the skills they have, due to time or willpower restraints).

Another reason some programs suck: they picked the wrong problem to code.

As a programmer coming from a linguistics background, this sentiment has always resonated with me. As much as math is a part of my job, recognizing the transferrable skills from human language use has probably been the primary reason that I've been able to land programming jobs and write fairly successful code.

"Programs are written for humans to read, not for machines to execute"

The post reminded me of an Ira Glass interview where he comments on having good "taste" (5 min) http://www.youtube.com/watch?v=BI23U7U2aUY which in turn reminds me of PGs essay "Great Hackers" http://www.paulgraham.com/gh.html Good stuff!!

Sadly (and tellingly) it's not necessarily the most successful code (success comes from meeting user needs, not from good code), but how else can you judge it, apart from reading it. This is made worse because it's hard to tell if code is necessarily complex without understanding the problem it solves, which may be complex. Further, if you don't yet know what good code is, how can you recognize it? Of course, if you are intelligent and reflective and try ideas out, you can learn from both code and bad - it's all raw material, grist for the mill.

IMHO the hard part of programming is understanding the problem to be solved. The solving is easy.

Schools have suggested reading lists. Do they have the same for code reading?

Fortunately, on the Internet, we have experienced people to help us: http://www.hnsearch.com/search#request/all&q=%22good+cod...

"Why did the author do this?"

"What effect do you get when reading this block?"

That's a good idea, but I haven't heard of one. I think the best thing is just to read a lot of code, good and bad.

BTW did you check the result of that search?

Haha, just skimmed through it, sorry. I remember threads on this topic, but it seems like HN search for this request failed to find them.

When you look at software, what you see is not a language, it is a machine. A machine that is presented in humanly understandable and communicable form, but nonetheless, something with a particular kind of underlying determinate structure.

Yes, the main part of the conclusion is the same: you have to learn by doing. But because software is design -- rational manipulation of objective 'material' -- knowledge about how it works is also an intrinsic part of doing it well.

Design means creating something through clear knowledge: we go with particular design ideas because we can predict their outcome and effect. This is the knowledge about that the article underestimates. We choose quicksort not simply because we have immersed ourselves in social norms, but significantly because it has been proven asymptotically fastest.

That kind of determinate knowledge that programming by nature can have is important. It is missing something to lump it in as just being like spoken language learning.

Communication is about translating something conceptual inside your own head to become understandable by something (usually a person) outside of it. The way we do this is by language. A programming language is merely the way we communicate with a computer. To do it right, you need to understand the parts of the computer that you want to change.

It's not a mistake that we used to call impressive coding "wizardry" or "deep magic". It was about casting spells... except that if you actually step to the side and look at what "spell" means, it's simply a story.

A good program tells a good story. You might not appreciate the characters or the plot, but the computer sure does.

Programming is not about knowing lots of words or grammar. It is about getting the thoughts clearly structured and understanding quickly what a problem is really about.

THIS is quite the same problem as writing text. But, IMHO, the author approached this as someone who does not know how to write text, too. Its not about ingenuous choice of words and correct application of grammar. It is about clarity of understanding the problem and then find a solution how to get to the point clearly and quickly.

If a solution is in the mind, 70% of the way is gone. Then it is important not to give up unless this idea is on paper in the same shape as it was in the head before. So I think the analogy is a good one, but the op has not necessarily found the reasons why.

All good communication comes first from good thinking. Whether or not we can communicate in a certain medium (speaking a language, writing, painting, music, programming) depends entirely on how fluently we can translate our thoughts into that medium.

So good thinking + good understanding of programming concepts = good code.

I'm wary of tickling my ego, but I recall not entirely seldom forgetting a formula, and so simply starting with other stuff and deriving it in the margin or on scratch paper. I think many of the instructors liked that, as well, as it showed a more conceptual grasp.

Anyone thinking along those lines needs to read Dijkstra: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW... (and maybe tack this on too: http://www.hxa.name/notes/note-hxa7241-20101218T2158Z.html ).

Having learned Python as a first programming language I always try to gain an idiomatic understanding of the language which allows myself to think in Python.

Does anyone have suggestions of some good code to read?

^ bingo.

this is an old idea.

I don't think writing code works that way.

I want to believe in what I've just wrote cause that guarantee that I will not have a lot of competitors and I'll always have a job when I want

For more, let's start with source code. Suppose we have source code line

     a = b*c

But, we conclude that

     a = b*c

Of course if we saw

     F = m*a

Okay, we are beginning to see:

A line of code such as

     a = b*c

We could write

     F = m*a

So, we have to ask,

     F = m*a

     F = m*a

Net, math, and science with math, are written in complete sentences in a natural language. The variables are all clearly defined, discussed, explained, etc. At no time is an algebraic expression of such variables regarded as a substitute for the natural language. Take a physics book, throwout the English and leave just the equations, and will have nothing.

Physics and math understand; so far computing does not.

So computing tries to write

     force = mass*acceleration

The matter of using mnemonic variable names as parts of speech in English is a grand mistake but common in writing in computer science. Bummer.

Bluntly computing has not figured out that there is so far just one way to communicate meaning: Use complete sentences in a natural language. Period. That's all we've got. But computing has fooled itself into believing that algebraic expressions with mnemonic variable names form a 'new language' that, in computer source code, can provide the needed meaning without a natural language. Wrong.

For

     F = m*a

So, writing these complete sentences to communicate meaning effectively is 'writing'.

Done!