4 ms·
The whole article feels loose and disconnected - probably as a result of the way you sourced the ideas. If you got them emailed in by different people, it's no
by swombat 16y ago
The whole article feels loose and disconnected - probably as a result of the way you sourced the ideas. If you got them emailed in by different people, it's no surprise that it feels like a collection of unrelated points rather than like a cohesive article.
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.
- 10ren 16y agoI think English is not the author's first language; it shows up in the article and in his posts here. We tend to be understanding of poor grammar here, but the instinctive reaction to flawed English is that the message is also flawed. While it is possible to work out what the author meant, it takes some consideration - that consideration is better spent on the ideas. 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.