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.
Why People Initially Suck at Programming
31–40 of 41 posts
Re: Why People Initially Suck at Programming
#32Earlier quoted context omitted.
@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 wa…
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…
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.
Re: Why People Initially Suck at Programming
#33One 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.
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.…
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. :)
Re: Why People Initially Suck at Programming
#34Earlier quoted context omitted.
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.…
>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. :)
Re: Why People Initially Suck at Programming
#35Earlier quoted context omitted.
@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 wa…
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…
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.
Re: Why People Initially Suck at Programming
#36Earlier quoted context omitted.
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.…
>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. :)
Re: Why People Initially Suck at Programming
#37One 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.
I intentionally program in that style all the time, especially in the absence of a REPL. It's really not much different than writing it out with pen + paper first. 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…
Re: Why People Initially Suck at Programming
#38Earlier quoted context omitted.
@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 wa…
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…
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.
Re: Why People Initially Suck at Programming
#39Earlier quoted context omitted.
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…
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…
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.
Re: Why People Initially Suck at Programming
#40I'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…
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.