Why People Initially Suck at Programming
talkbinary.com
talkbinary.com
On top of that, the writing is loose, the ideas aren't really thought through. Basically, it's just someone's spontaneous, unrefined brain fart on the topic.
Sorry if the author is reading this, but it's honest feedback. You can do better than this piece of linkbaiting trash.
Incidentally, the comment thread here turned up some great discussion on why programming is so hard for beginners, so gg, HN.
I'm the actual author but thanks for the feedback I'll put it into good use. I'm new into this type of writing so I was expecting my first article to be not that great.
Either way, its helped me a lot since I've learned in ways I could improve further articles.
But why did you mention it to be a piece of linkbaiting trash? Links posted were to support my reasons. Also, I didn't collect any data since this was done through the help of other programmers so its not really a brain fart in the sense.
And poor? Honestly, I don't think its that bad.
Your final remark is the best way to guarantee you never write anything great. You begin by saying you appreciate the feedback but end saying you think it wasn't bad.
The better way to close, instead of getting defensive:
"How could I have done this better?"
I appreciate the constructive criticism. Next time I'll make sure I deliver on what everyone is saying.
And linkbaiting, why lie? I tried it out for a reason but ultimately I only chose ten because I received 10 reasons from other people. They all weren't only "my" ideas. I mentioned it at the end of the post.
That's another problem with these points, too. They're not the result of some reflection to come up with some key reasons why people suck at programming, they're just the first things that popped into the heads of the people who emailed you. Because of this, the article goes only skin-deep in what would otherwise be an interesting topic. Instead of insight, it provides only a superficial list of obvious, unresearched ideas. This kind of content may fly on a general interest site, but on a site like HN, which is filled with programmers who have spent time thinking about why programming is hard, it is just bad.
Let's take one of the "points" apart:
Before I help anyone with their code, I ask to see their algorithm. If they can’t provide it, I tell them to develop one and nearly all the time they’ll figure out why their program didn’t work.
Huh, what? That doesn't even make sense. Most programs don't involve much or any algorithmic design. Are you sure you know what an algorithm is? Or what a program is? What kind of program are you talking about? How do people "show you" their algorithms? What does it even mean to "show the algorithms" for a Ruby-on-Rails app?
An algorithms is the framework, and basis, of a program. Many beginners don’t develop one, and write as it goes. When that happens, they lose track of their direction in solving the problem and it becomes difficult debugging. – Benjamin
Who's Benjamin? Why is his opinion relevant to this topic? Also, what a silly opinion. Most programmers I know, experts many of them, and myself included, do not spend time "developing their algorithm" before writing code. I assume by algorithm you mean pseudo-code of some sort. If you have to write pseudo-code before you can write real code, then you really do suck at programming. As a programmer, this point makes me feel that you don't know what you're talking about.
So next time, save yourself some time and jot your plan of attack on a piece of paper. Start programming until you know how to solve your problem. I do it, and it works amazingly.
Again... most programming problems are trivially easy once you know how to solve them, but in many cases you don't know how to solve them before you do it. And the language you "write your algorithm" in should be the language you're writing your program is. In this paragraph we also see an example of loose writing: "Start programming until you know how to solve your problem"... did you mean "Don't start programming...?" That would make more sense in the context of the article. This kind of mistake makes it hard to take the article seriously, because you're already on a flimsy basis to begin with.
You don’t want your program looking like this poor guy, Asimo falling down stairs, do you? So plan accordingly!
What a poor example! Most programmers with some intelligence would love to be able to write the insanely complex code responsible for allowing Asimo to fall down the stairs. AI code is some of the hardest on Earth, disrespecting that suggest you don't understand this basic point.
Writing should be like a window, that you can see clearly through - not one you have to keep checking to see if it's a mark on the window or what you're supposed to be seeing. Excellent writing disappears.
So, TalkBinary, if you're genuinely interested in writing, improving your English is crucial. It might seem prejudiced to criticize your English, but it is the first thing people see about your writing, and because their time is limited, they will judge it on that basis. swombat has given a lot of his time to you - although it can be harsh to hear negative comments, this is valuable advice you have received. It might also seem that grammar and spelling etc are secondary, and shouldn't matter (I used to feel this), but they really do - if you want to communicate. Hell, even when I read my own writing months later, any spelling errors etc are very distracting, and if I haven't been clear it is hard for even me, the author, to understand.
I'm not sure of the best way for you to improve, but the first thing is for you to want to. The second thing is to get feedback - swombat has given you a start (and I agree with all his writing points). If you can handle it, seek out further feedback and criticism. If you are in school/uni, you can probably find someone there to help also. The third thing is to take action on it - such as rewriting this article with the errors corrected.
Finally, I wanted to fill out one of swombat's points: writing out an algorithm can be crucial. I just spent the last two months getting one clear (I did have a go at coding it directly earlier on, but it wasn't clear enough). Once I was clear, it just took a day (today) to design, code and debug. Now, this is unusual; I'm doing research on relationships between grammars for a startup. Mostly it's not needed, as swombat says. But after two months, I just wanted to speak up for one of those problems that is not in the "most" category (though I'm inclined to think that all problems are trivially easy once you know how to solve them; similar to how mathematician can only do "trivial" proofs.)
I actually think the ideas quoted above are actually good ones, if you're not clear on what you're doing (though annoyingly expressed). Exploratory programming is also helpful. I find it's a mix; it depends how complex the problem is, how many different issues there are - and crucially - how much experience you have with that kind of program. Familiar problems are easy to solve in your head or at the keyboard. I used to always work that way, until I got into grammar stuff.
BTW: if you purely compiled this, so it's not your writing, remember that as editor, it's even more important that you are able to write well, so as to improve - edit - the writing of others. Anyway, good luck, I think the article is hepful overall, good on you for actually doing something and having a go, and I hope you start to take this opportunity, of room for improvement.
I just don't like hearing people assume and start talking about things where I don't think its entirely true.
As you, I also believe writing out an algorithm is crucial. Sure, you can get away with it most of the times but once the problem becomes more abstract, difficult, and interesting then it's essential.
The best we can do is to seek the grain of truth in what someone says, because they often do have a point, disregard the rest, and not fall into name-calling ourselves. It's just about impossible to stop someone from being rude; but we can stop ourselves from taking it personally. And the most effective way to do that is to fully accept any legitimate criticism they have, and totally discard the rest. The rudeness belongs to them, not to you, and you can bet it causes them all sorts of problem. One should therefore feel sympathy for person who has been rude (including oneself.)
That said, let me unpack what (I think) was meant: by "brain fart", he's upset about the writing itself, and that the ideas have not been thought out carefully. He sees it as carelessness, and is offended. Whereas I see it as a lack of ability, with English not being the authors' first language. But I agree that you and the other authors can improve on this - as he said "you can do better than this".
By "link-bait trash", I think he means that you have written this article for the purpose of getting hits, and not primarily out of interest in the content, nor for a wish to communicate it. From the article, and what you've said here, it does come across that way - but I find it very hard to judge, because of the language issue. Poor communication can lead to all sorts of problems!
He could have written these thoughts out objectively, without name-calling; as a result of not doing that, he has offended you. When a person feels attacked and offended, it is distracting for them, and makes it difficult for them to appreciate the actual content of the criticism (it even tends to pressure people to go against the criticism). Name-calling undermines one's purpose.
I hope the above makes it easier for you to accept the content, and disregard the insult.
You can begin by asking yourself what the purposes of the article were - was getting hits the primary purpose? It might not be "entirely true", but is it partly true? If so, admit it to yourself, and then you can move on. Having an objective and factual perspective makes you (largely) immune to insult.
(BTW: I have a more nuanced view of writing out algorithms. It's definitely useful at times, but it's not always the best one (not crucial or essential). A danger is that writing can concretize your conception of the problem (eg an incorrect assumption); whereas beginning to code can give you information. Have you ever gone to a lot of trouble to get clear on a problem, and then when you start to code it, you immediately realize that you misunderstood it, meaning that all that time was wasted? (and if you've become attached to that misunderstanding, you may fight the evidence, or not even see it, because not open to it). Writing algorithms definitely has its place, it's a mix.)
Indeed, but I was consistently surprised at how students with no prior programming experience were bad at even basic algorithmic thinking. Things that to you and me are afterthoughts took fifteen minutes (or more) of patient back-and-forth between me and the student, including diagrams, analogies and examples.
But I still can't agree with you on one point. Many people suffer when they don't have pseudo-code or a basic algorithm for solving a problem. Even something simple like a recursive algorithm, I've seen people can't solve it because they start programming without ever thinking about it.
I know some people are naturally gifted and programming is trivial for them but its not the same for everyone.
Also, I can start writing code without writing an algorithm. These tips were meant to describe why people initially can't program not continue programming. So please don't assume beyond what is written in the article.
But either way, thanks for the criticism. Like I mentioned before, I'll use it to improve my writing and avoid future mistakes. Sure, my English isn't the best since its not my native language and I normally haven't written much aside from technical and research documents.
The problem is that money isn't motivation to actually enjoy programming. When you start coding to get money, you're seeing coding as means to an end, and not an end in and of itself. That sucks all the fun out of coding just for its own sake.
I used to love coding games. Then I realized I could sell them for money. I started making games at a much faster rate in order to make more money, but suddenly the game making part was not as much fun any more. I wasn't pushing my own boundaries any more; instead, I was just rehashing what I already knew and had already made into new layouts to create another game. Once I realized this, I stopped selling games, but enjoying coding just for coding took a while to fully came back. I could argue that it only just now came back, about a year after I stopped selling my games.
Or did the business side take over just because... well - it's good to get money for the work?
It lets me get the idea out of my head and on to the screen where it can be criticized. Tracking down syntax errors, missing includes, compiler flags, etc. is enough of an independent activity that I often want to do it all at once at the end of the first brain dump. At the beginning I want to be shitting out code, not googling for solutions to GCC's vague neuroses. After that first dump is done and validated, I use it as the first commit and iterate from there.
Code is also difficult to read. It's much easier to understand a code flow diagram, or something similar, than it is to comprehend the 100 or so lines that the diagram represents.
I mean, I've been programming professionally for 7 years, and much more before. But whenever I need to do something that I haven't done in the last week or so, I still always start with a tiny function to make sure I still remember how to do even the basic stuff, and build from there. E.g., every time I write some new js code, I start with a function that only prints something to the console; then, does the basic functionality, printing results to console; then and only then, start doing more complex things. It always surprises me that people will spend a day or more working without checking even the most basic check that what they're doing works the way they expect.
I can go a long time without compiling but that's because I use IDE tools that show me instantly if I have compiler errors, etc. :)
I mean, it's easy to write one line of code. It's easy to write a second line of code. It's when you reach hundreds or thousands that it gets tricky.
Good programmers manage complexity.
I haven't seen that attitude before, but recently an idealist graduate joined my team. I can't remember now how many times lately I had to tell "Yes, it has bugs, but writing a new implementation would take a year, so we're just going to patch the library."; "No, it doesn't have a documentation - check if it behaves correctly."; "No, it really doesn't need to be a fully speced system on its own JVM, it doesn't need more than a shell script."; "Yes, requirements change, get used to that."...
Of course we'd all love to have 100% correct, documented libraries, specs which are unambiguous, properly designed code that will stay at version 1.0.0 and with same API forever... Well - it just doesn't work like that, even if it's a good thing to aim for. I can swear every day at some RFCs and the bunch of monkeys who wrote them, but that doesn't mean it's going away. It's already out there - if you have time, build something better. If you don't... take a break, breathe, come back and make it work.
Qt 4.
When I started writing code, I became frustrated and couldn't write code because half the time I couldn't deal with it. I talked with the professor and after a long conversation, he simply told me to deal with it. So I did.
A month later, I had learned so much from the library by just reading snippets of code and testing it. Before I knew it, I was writing code non-stop.
a) think and behave quite illogically in their day to day lives
b) express themselves in generalities and don't think in enough detail (which makes sense when your primary interaction is with other humans, it simply isn't necessary) to communicate their ideas to the degree that programming generally requires.
Why do they initially suck at Super Mario Brothers?
Why do they initially suck at playing piano?
...
Not sure if I should tell the old Carnegie Hall joke or link to that Gladwell book...