

Why People Initially Suck at Programming - superberliner
http://talkbinary.com/articles/10-reasons-why-people-initially-suck-at-programming/

======
swombat
This is a pretty poor article on the whole. These "reasons" aren't supported
by anything other than conjecture. Should be titled "10 reasons why I think it
could be that some people suck at programming, based on my personal biases on
the topic and on no actual data."

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.

~~~
TalkBinary
@swombat

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.

~~~
swombat
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
I 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.

~~~
TalkBinary
Thanks for the comment. I understand as a writer that all I can do is improve
my writing. So sure, I don't really mind people criticizing me for my writing.
On the other hand, I love to hear what others have to say when I can improve
on something.

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.

~~~
10ren
I think swombat was definitely rude in his first comment calling it a "fart"
and "trash". Name-calling is labeling, and is neither accurate nor helpful in
a cognitive sense; and is abusive and disrespectful in a social sense; and it
appears to be based on a strong personal emotion of anger, rather than an
objective appraisal. It has no place in a civil and intellectual forum. But
this is the internet. It's never been a civil and intellectual forum,
including here, despite what many HN users would like. Even associate
professors, when online, do it: <http://news.ycombinator.com/item?id=1611007>

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.)

------
johnfn
> "So if you find yourself lacking some motivation, maybe thats why you aren’t
> that great. Go find it and last time I checked, money pushes so many people
> forward."

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.

~~~
viraptor
Interesting. I'm wondering though, was it really one or the other? Weren't you
able to just continue doing it for fun and exploring new ideas, but sell just
because/when they reached some specific level of quality?

Or did the business side take over just because... well - it's good to get
money for the work?

------
mx12
One of the biggest mistakes I see a lot of beginners make, is that they don't
break the problem up into sub problems that they can easily solve. What I
always tell students is to write some code, and then test it right away. Too
many students try and solve the entire problem without compiling once, and
then they are bewildered when they have 1000 errors because they forgot a
semicolon at the end of each line.

~~~
edanm
After a few years of teaching new recruits how to program, this still amazes
me: so many people will go a _day_ without compiling once!

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.

~~~
loewenskind
>After a few years of teaching new recruits how to program, this still amazes
me: so many people will go a day without compiling once!

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. :)

~~~
edanm
This is without a doubt a _huge_ benefit of IDEs (and compiled languages,
since with interpreted you don't really get the same benefit). I wish more
people realized how great the benefit of this: I suspect most people dismiss
it without ever trying.

------
erikstarck
I'd say programming is deceivingly easy.

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.

------
viraptor
I've got no. 11... "Just deal with it".

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.

~~~
AndyKelley
_Of course we'd all love to have 100% correct, documented libraries, specs
which are unambiguous, properly designed code that will stay at version [4.x]
and with same API forever..._

Qt 4.

------
kgo
Why do people initially suck at brain surgery?

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...

------
FlemishBeeCycle
I would say that people "initially suck at programming" because most people

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.

~~~
loup-vaillant
In other words, programming is the first actually technical subject they ever
studied. <http://yudkowsky.net/rational/technical> (High school math is a
technical subject, but it's rarely studied as such.)

------
pendragon
I've been finding that in order to motivate myself for programming I have to
not think of it in terms of, " _sigh_ , a basic GUI front end for MySQL....".
I have to make myself identify some interesting problem, or new skill which
challenges and interests me. That way I feel motivated to work through the
easy stuff I've done before because then I can work on the interesting
problem.

------
scott_s
Algorithmic thinking is both a skill and a kind of thinking most people have
not done prior to programming.

------
sandipagr
I think problem with lot of bad programmers are that they do not take the top
down approach and often get way too attached into the micro-details when they
are just beginning. From my experience, it invites a lot of trouble. They open
the editor and start coding stuff when they don't even have big picture in
their head. Not only this increases the total time to have it developed by 2-3
folds, but you get stuck at times. It just makes programming so much easier
when you spend couple hours thinking about the problem before you actually
throw yourself into actual coding. This is probably the biggest lesson I have
learnt about programming.

------
bg4
So the question is: why are novices, novices?

