Some people look for experience and hands-on expertise and HR people look for words in a search list. I don't think I have ever been hired easily by going through HR filters but begged to work for companies who know what my resume actually means. Techs know other techs. And, frankly, I am equally skeptical of people who go out chasing every certification they can until their resume looks like a NASCAR racer.
Actually, my wide range of experience leads people to ask me the same question(s) asked of people
A bit off topic, but you triggered something I've been thinking about for a couple of years. That "spark" is fluency.
I swtiched jobs from being a computer programmer to being an ESL teacher in Japan. Japan is somewhat famous for churning out students who know a lot *about* English, but can't order a drink at Mac Donald's. We used to have a name for those kinds of people with regard to programming languages: language laywers. They can answer any question you put to them *about* a programming language, but couldn't program to save their life. These people often make it past job interviews easily, but then turn out to be huge disappointments when they actually get down to work. I've read a lot about this problem, but the more I look at it, the more I realise that these disabled programmers are just like my students. They have a vocabulary of 5000 words, know every grammar rule in the book but just can't speak.
My current theory is that programming is quite literally writing. The vast majority of programming is not conceptually difficult (contrary to what a lot of people would have you believe). We only make it difficult because we suck at writing. The vast majority of programmers aren't fluent, and don't even have a desire to be fluent. They don't read other people's code. They don't recognise or use idioms. They don't think *in the programming language*. Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel. And so our programs are needlessly complex.
Those programmers with a "spark" are programmers who have an innate talent for the language. Or they are people who have read and read and read code. Or both. We teach programming wrong. We teach it the way Japanese teachers have been teaching English. We teach about programming and expect that students will spontaneously learn to write from this collection of facts.
In language acquisition there is a hypothesis called the "Input Hypothesis". It states that *all* language acquisition comes from "comprehensible input". That is, if you hear or read language that you can understand based on what you already know and from context, you will acquire it. Explanation does not help you acquire language. I believe the same is true of programming. We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation.
Interesting. You might actually be on to something.
I was reading some justifications for code comments the other day, and I'm thinking to myself that when working on other people's code, I always go straight to the code and completely ignore comments, even when they are present and done well. Of the languages I am familiar with, unless someone tried really hard to go out of their way to obfuscate the code, reading and comprehending is as easily as doing the same with any english prose. It amazes me that peo
Parent has it. You don't write comments to state what each line of code is doing, the code says that. You write comments as to the motivation of blocks of code. They give the reason why a particular implementation was chosen and enough information for the next developer to determine if the reason is still valid or the code should be refactored.
Again, what value does the comment add when the code says it all?
I do agree with you if you do have to write some obfuscated mess as a performance optimization or other justifiable reason. But there is no reason to do that for the vast majority of your code in almost all situations. In those cases, comments are just noise.
Explanation as to why a certain sort type is preferred here, why linked lists were used instead of arrays, higher level pictures that explain how all the pieces go together (though proper uses of function calls likely make the last less necessary...).
When does that information become useful? If the code works, it simply doesn't matter what the author was thinking when he wrote it. If the code doesn't work, you have to find a better way to do it. Again, it doesn't matter what the author was thinking.
Sorry for all the questions, I'm just trying to improve my craft. Refactoring and improving other people's code is something I love to do, so I read quite a bit of code written by others. I have never once wished there were comments and often wish there were
You can get information about the system that the specific lines of code doesn't cover. Is this code meant for an embedded system with low memory but high processor usage but you need the code for a netbook with a slow processor but fairly good memory (ok, those specific devices may not be ideal for the example but...).
Yes a good developer can figure out why something was implemented the way it was but with comments the intent can be clarified and anyone working from the code can focus on real issues rat
There are many edge cases and situations that are not obvious from the code alone, even good code. In addition, there are always tradeoffs between speed, accuracy, memory usage, etc, which differ based on the situation. A comment that says "we used a sparse array here instead of a map because we decided it was more important to have faster lookups than memory usage" is important when you look a piece of code that may initially seem to not be the best way to do something.
If the code doesn't work, you have to find a better way to do it.
This is actually something I'm thinking about from a language design perspective. Computer languages are great and explaining what you want to do, but are not expressive enough to explain why you want to do that. Tests often help a great deal. You can write a comment that says, "This is -1 here because my array starts from zero". But you can also write a test that shows that the array begins at zero and the indexing is correct. For me the second is preferred for a number of reasons. The first is that
Exactly!
Comments are to explain motivations, overviews, summaries, and generally the thinking behind the code.
Also notes about why code was changed and when, bugs found and not-yet found, things remaining to be done, and so on.
I once ported the old 3Dfx 3D drivers (Glide) from a PC platform to a MIPS processor embedded platform. The Glide source code we received was a CD full. Hundreds of files, a ghastly complicated build tree, huge dependency mash...
There wasn't one single line of comment anywhere in
Except that reading code is like having to read a play and act out all the parts in your head. It is much easier to have someone write some stage directions in there for you. It is nice to have a narrator.
Unfortunately, your code example does not say anything. You have omitted the function name, which would give the purpose of the function. Your variables do not describe what they hold. You have magic numbers. In english, we call that gibberish. It doesn't mean we should comment our gibberish, it means we should write more succinctly.
It unnecessarily runs the first three lines of code before checking a condition it could just as well check right at the start. You're right that it is clear that it is modelling a state machine, but it is doing it in a way that is concerned with the fact that is a state machine, rather than a representation of something which happens to be a state machine.
If I'd written that piece of code, I wouldn't love to bring it up at all. I'd blow up the source control server and deny all knowledge.
It is hard to test for that when hiring. Example code will be hand picked and doesn't tell you much about the process the candidate went through to write it. Did they just churn it out or was it based on something else? You can set them tests in the interview but some people are just not good at that sort of thing. I can produce some pretty good code IMHO, but I need to be "in the zone" with my head in the project and a context to work in, so tend to suck at test questions.
Understanding a language is much easier than expressing things in it. Perhaps those coders spend more time thinking about code than actually coding.
There's also the tendency for language students to cluster together and avoid contact with actual native users of the language. Perhaps programmers in that stage of comprehension without expression also tend to avoid truly skilled users of the language and their code.
I've found that with language students the ones who do not progress to fluency are the ones wh
In language acquisition there is a hypothesis called the "Input Hypothesis". It states that *all* language acquisition comes from "comprehensible input". That is, if you hear or read language that you can understand based on what you already know and from context, you will acquire it. Explanation does not help you acquire language. I believe the same is true of programming. We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation.
(Bolding is mine)
Oh goodness gracious no! I've worked with such (usually self-) taught programmers (and been one myself before I got a degree). The difference between Computer Science and "speaking a language" is that one has the goal of being merely mutually comprehensible, and one has the goal of efficiently and meaningfully dealing with large amounts of data.
To give a more concrete idea: Being long winded or speaking only in one-syllable words can be annoying, and is simply corrected by example and furth
Don't get me wrong! There is more to writing code than the ability to program fluently! I've waded through enough ad hoc parsers and file formats that were based on context free grammars to know that. Algorithmic complexity, automata and grammars, normal forms and a few other things are really important. I used to work for a company that had a hard on for mechanical engineers. Smart guys, but never once took a CS course in their life. It took them a while for them to learn what they needed.
Thinking about it as a language at all is where the mistake begins. (Mostly.) Language is rife with hidden meanings, implications, tone, and a sort of game theory "what word can I put here that will get my meaning across?" Instead, it should be thought of precisely AS code. You are telling a machine what to do, not playing a trial and error RPG.
Telling the computer what to do is only half of what I am doing (and the easy half at that). Telling other programmers what is going on is the other half. If we were only interested in whether the computer understood what I was saying then "good code" would equate to "does it run". Nothing else would matter. But future productivity is dependent upon the ability of programmers to understand and modify the code without breaking it. I've worked on systems where the code was so bad that the average program
It does seem very similar, doesn't it? Thanks for the link. The "input Hypothesis" is a little different in that it discusses only language acquisition and doesn't propose a model for how that acquisition happens. It makes a distinction between "learning" and "acquiring", where someone can "learn" something but not be able to use it fluently. "Acquisition" means being able to use it fluently.
The "input Theory" merely states that no matter what techniques you use to teach language, acquisition only happe
I agree with your thoughts about people learning what a programming language is but not how to use it. So many people who come out of college knowing C/Java but their eyes would glaze over if you asked them to learn Ruby or Ada. Since I've left college I've learned C,C++,C#,Java (ok those are all similar), some Basic variants, DOORS DXL, Torque scripting language, Ada, Perl and touched a few other languages and found programming is the same in all of them.
I agree. Fortunately when I went through my CS degree program I took the Cooperative (work-study) program. The school gave me the theory and practice to learn the programming language and then the work part allowed me to read and modify code in different languages.
Because I believe in getting fluent in a programming language the process is always a painful process of 'immersion' . This is where you essentially bring in every book you have on the language and lock yourself into a room 18 hours a day for
Some good stuff there. Some crap. Overall I give myself a C+. As you are an anonymous coward, I don't suppose you'll ever see this. I'm not even sure why I'm responding to such a ridiculous comment. But I've always been happy to have people read and critique my code. Feel free.
Just want to say that is a fantastic explanation. It probably explains to some degree what being "in the zone" means for programmers. It's like when you're really immersed in a good book, so to speak. You're engaging your creativity and thinking only about the world in front of you.
Maybe it's just me, but I find it harder to concentrate on coding when there is talking around me, or even words in music (except music I've very familiar with, so my brain isn't trying to interpret the words anew). I've always t
Totally agree, I'm excellent at the conceptual stuff but only a decent programmer.
Fortunately I have a second degree and arrived as an IT consultant.
There definitely needs to be an improvement in how code is taught or designed. It should start from the most common program and have you edit it to taste rather than starting as a blank slate.
Most programming is essentially well researched equations sandwiched inside a Viso sheet, once you realize that all data is equivalent it's conceptually pretty simp
My current theory is that programming is quite literally writing.
I agree to a very large extent.
A corollary of your insight is that programming languages should be designed more like natural languages and less like mathematical or logical formalisms. Programming languages are primarily for people to communicate with people, since machines don't care if we communicate with them in Java, brainf*ck, Haskel, or machine code. It is an argument for programming languages that allow the easy construction of domain
And a sufficiently complex railroad network is a turing complete programming system, but you can't ride a turing machine tape to work...
Just because we can show that programming languages have equivalences to mathematical formalisms (such as the lambda calculus, or a turing machine) does not mean these things are the same
To repeat "mathematically equivalent"/= "the same."
Programming is writing because programming languages exist for the purpose of communicating with other people not for the purpose of comm
This thread has been an enlightening read. I previously thought under-commented code (and comment-free code more so) was purely down to laziness.
But seeing people describing why they don't write comments on code, now I know better. It isn't always laziness, it's sometimes an egotistical and delusional belief in their own godlike programming abilities, coupled with a fundamental misunderstanding of the nature and purpose of programming.
Programming isn't 'just to make the machine do something'. The purpose is
wrook -- see my uid? I've been around a while. (you too, I see.)
My enjoyment of slashdot diminished years ago -- it's long since fallen off my rss feeds and daily visits. I found your comment via a link on hacker news and you sir -- you have given me a new hope for slashdot.
I'd like to offer some counterpoint. There is some truth to what you say, certainly. Fluency/competence is important in both arenas. However, quite a number of years ago (1990) [washington.edu], I made the observation (in the context of a discussion about intellectual property and whether copyright should apply) that literature is essentially a "divergent" activity and that programming, being an engineering activity, is "convergent". That is, if assigned an English paper to write, there's a very high chance that you will
Depends on who is hiring (Score:4, Informative)
Some people look for experience and hands-on expertise and HR people look for words in a search list. I don't think I have ever been hired easily by going through HR filters but begged to work for companies who know what my resume actually means. Techs know other techs. And, frankly, I am equally skeptical of people who go out chasing every certification they can until their resume looks like a NASCAR racer.
Actually, my wide range of experience leads people to ask me the same question(s) asked of people
Re:Depends on who is hiring (Score:5, Insightful)
A bit off topic, but you triggered something I've been thinking about for a couple of years. That "spark" is fluency.
I swtiched jobs from being a computer programmer to being an ESL teacher in Japan. Japan is somewhat famous for churning out students who know a lot *about* English, but can't order a drink at Mac Donald's. We used to have a name for those kinds of people with regard to programming languages: language laywers. They can answer any question you put to them *about* a programming language, but couldn't program to save their life. These people often make it past job interviews easily, but then turn out to be huge disappointments when they actually get down to work. I've read a lot about this problem, but the more I look at it, the more I realise that these disabled programmers are just like my students. They have a vocabulary of 5000 words, know every grammar rule in the book but just can't speak.
My current theory is that programming is quite literally writing. The vast majority of programming is not conceptually difficult (contrary to what a lot of people would have you believe). We only make it difficult because we suck at writing. The vast majority of programmers aren't fluent, and don't even have a desire to be fluent. They don't read other people's code. They don't recognise or use idioms. They don't think *in the programming language*. Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel. And so our programs are needlessly complex.
Those programmers with a "spark" are programmers who have an innate talent for the language. Or they are people who have read and read and read code. Or both. We teach programming wrong. We teach it the way Japanese teachers have been teaching English. We teach about programming and expect that students will spontaneously learn to write from this collection of facts.
In language acquisition there is a hypothesis called the "Input Hypothesis". It states that *all* language acquisition comes from "comprehensible input". That is, if you hear or read language that you can understand based on what you already know and from context, you will acquire it. Explanation does not help you acquire language. I believe the same is true of programming. We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation.
Re: (Score:2)
Interesting. You might actually be on to something.
I was reading some justifications for code comments the other day, and I'm thinking to myself that when working on other people's code, I always go straight to the code and completely ignore comments, even when they are present and done well. Of the languages I am familiar with, unless someone tried really hard to go out of their way to obfuscate the code, reading and comprehending is as easily as doing the same with any english prose. It amazes me that peo
Re: (Score:2)
Re: (Score:2)
Again, what value does the comment add when the code says it all?
I do agree with you if you do have to write some obfuscated mess as a performance optimization or other justifiable reason. But there is no reason to do that for the vast majority of your code in almost all situations. In those cases, comments are just noise.
Re: (Score:2)
Re: (Score:2)
When does that information become useful? If the code works, it simply doesn't matter what the author was thinking when he wrote it. If the code doesn't work, you have to find a better way to do it. Again, it doesn't matter what the author was thinking.
Sorry for all the questions, I'm just trying to improve my craft. Refactoring and improving other people's code is something I love to do, so I read quite a bit of code written by others. I have never once wished there were comments and often wish there were
Re: (Score:2)
Yes a good developer can figure out why something was implemented the way it was but with comments the intent can be clarified and anyone working from the code can focus on real issues rat
Re: (Score:2)
Re: (Score:2)
There are many edge cases and situations that are not obvious from the code alone, even good code. In addition, there are always tradeoffs between speed, accuracy, memory usage, etc, which differ based on the situation. A comment that says "we used a sparse array here instead of a map because we decided it was more important to have faster lookups than memory usage" is important when you look a piece of code that may initially seem to not be the best way to do something.
If the code doesn't work, you have to find a better way to do it.
It's not always obvious that the code
Re: (Score:2)
This is actually something I'm thinking about from a language design perspective. Computer languages are great and explaining what you want to do, but are not expressive enough to explain why you want to do that. Tests often help a great deal. You can write a comment that says, "This is -1 here because my array starts from zero". But you can also write a test that shows that the array begins at zero and the indexing is correct. For me the second is preferred for a number of reasons. The first is that
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
I often run into this mentality, and I really don't understand it. What's this code do?
int oldState = (oldAcSplit ? 1 : 0) + (oldBdSplit ? 2 : 0);
int newState = ( acSplit ? 1 : 0) + ( bdSplit ? 2 : 0);
if (oldState == newState) return;
if (acSplit != oldAcSplit && bdSplit != oldBdSplit) return;
int tab = getSelectedTab();
int diff = newState - oldState;
int offset = Math.abs(diff) + ((newState + oldState == 4 && tab == 2) ? 1 : 0);
I love to bring
Re: (Score:2)
Unfortunately, your code example does not say anything. You have omitted the function name, which would give the purpose of the function. Your variables do not describe what they hold. You have magic numbers. In english, we call that gibberish. It doesn't mean we should comment our gibberish, it means we should write more succinctly.
Re:What does this code do? (Score:1)
Re: (Score:2)
It is hard to test for that when hiring. Example code will be hand picked and doesn't tell you much about the process the candidate went through to write it. Did they just churn it out or was it based on something else? You can set them tests in the interview but some people are just not good at that sort of thing. I can produce some pretty good code IMHO, but I need to be "in the zone" with my head in the project and a context to work in, so tend to suck at test questions.
I actually just landed myself a ne
Re: (Score:2)
Understanding a language is much easier than expressing things in it. Perhaps those coders spend more time thinking about code than actually coding.
There's also the tendency for language students to cluster together and avoid contact with actual native users of the language. Perhaps programmers in that stage of comprehension without expression also tend to avoid truly skilled users of the language and their code.
I've found that with language students the ones who do not progress to fluency are the ones wh
Re: (Score:2)
In language acquisition there is a hypothesis called the "Input Hypothesis". It states that *all* language acquisition comes from "comprehensible input". That is, if you hear or read language that you can understand based on what you already know and from context, you will acquire it. Explanation does not help you acquire language. I believe the same is true of programming. We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation.
(Bolding is mine)
Oh goodness gracious no! I've worked with such (usually self-) taught programmers (and been one myself before I got a degree). The difference between Computer Science and "speaking a language" is that one has the goal of being merely mutually comprehensible, and one has the goal of efficiently and meaningfully dealing with large amounts of data.
To give a more concrete idea: Being long winded or speaking only in one-syllable words can be annoying, and is simply corrected by example and furth
Re: (Score:2)
Don't get me wrong! There is more to writing code than the ability to program fluently! I've waded through enough ad hoc parsers and file formats that were based on context free grammars to know that. Algorithmic complexity, automata and grammars, normal forms and a few other things are really important. I used to work for a company that had a hard on for mechanical engineers. Smart guys, but never once took a CS course in their life. It took them a while for them to learn what they needed.
But serious
Re: (Score:1)
Re: (Score:2)
Telling the computer what to do is only half of what I am doing (and the easy half at that). Telling other programmers what is going on is the other half. If we were only interested in whether the computer understood what I was saying then "good code" would equate to "does it run". Nothing else would matter. But future productivity is dependent upon the ability of programmers to understand and modify the code without breaking it. I've worked on systems where the code was so bad that the average program
Re: (Score:2)
It does seem very similar, doesn't it? Thanks for the link. The "input Hypothesis" is a little different in that it discusses only language acquisition and doesn't propose a model for how that acquisition happens. It makes a distinction between "learning" and "acquiring", where someone can "learn" something but not be able to use it fluently. "Acquisition" means being able to use it fluently.
The "input Theory" merely states that no matter what techniques you use to teach language, acquisition only happe
Re: (Score:3)
It may never happen but I'd like to get into tea
Re: (Score:1)
Because I believe in getting fluent in a programming language the process is always a painful process of 'immersion' . This is where you essentially bring in every book you have on the language and lock yourself into a room 18 hours a day for
Re: (Score:2)
http://jldrill.rubyforge.org/ [rubyforge.org]
Some good stuff there. Some crap. Overall I give myself a C+. As you are an anonymous coward, I don't suppose you'll ever see this. I'm not even sure why I'm responding to such a ridiculous comment. But I've always been happy to have people read and critique my code. Feel free.
Re: (Score:1)
Just want to say that is a fantastic explanation. It probably explains to some degree what being "in the zone" means for programmers. It's like when you're really immersed in a good book, so to speak. You're engaging your creativity and thinking only about the world in front of you.
Maybe it's just me, but I find it harder to concentrate on coding when there is talking around me, or even words in music (except music I've very familiar with, so my brain isn't trying to interpret the words anew). I've always t
Re: (Score:2)
Fortunately I have a second degree and arrived as an IT consultant.
There definitely needs to be an improvement in how code is taught or designed. It should start from the most common program and have you edit it to taste rather than starting as a blank slate.
Most programming is essentially well researched equations sandwiched inside a Viso sheet, once you realize that all data is equivalent it's conceptually pretty simp
Re: (Score:2)
My current theory is that programming is quite literally writing.
I agree to a very large extent.
A corollary of your insight is that programming languages should be designed more like natural languages and less like mathematical or logical formalisms. Programming languages are primarily for people to communicate with people, since machines don't care if we communicate with them in Java, brainf*ck, Haskel, or machine code. It is an argument for programming languages that allow the easy construction of domain
Re: (Score:2)
And a sufficiently complex railroad network is a turing complete programming system, but you can't ride a turing machine tape to work...
Just because we can show that programming languages have equivalences to mathematical formalisms (such as the lambda calculus, or a turing machine) does not mean these things are the same
To repeat "mathematically equivalent" /= "the same."
Programming is writing because programming languages exist for the purpose of communicating with other people not for the purpose of comm
Re: (Score:1)
This thread has been an enlightening read. I previously thought under-commented code (and comment-free code more so) was purely down to laziness.
But seeing people describing why they don't write comments on code, now I know better. It isn't always laziness, it's sometimes an egotistical and delusional belief in their own godlike programming abilities, coupled with a fundamental misunderstanding of the nature and purpose of programming.
Programming isn't 'just to make the machine do something'. The purpose is
faith bolstered (Score:2)
wrook -- see my uid? I've been around a while. (you too, I see.)
My enjoyment of slashdot diminished years ago -- it's long since fallen off my rss feeds and daily visits. I found your comment via a link on hacker news and you sir -- you have given me a new hope for slashdot.
kudos on an insightful post.
J.J.
Counterpoint (Score:2)
I'd like to offer some counterpoint. There is some truth to what you say, certainly. Fluency/competence is important in both arenas. However, quite a number of years ago (1990) [washington.edu], I made the observation (in the context of a discussion about intellectual property and whether copyright should apply) that literature is essentially a "divergent" activity and that programming, being an engineering activity, is "convergent". That is, if assigned an English paper to write, there's a very high chance that you will