Why People Initially Suck at Programming
talkbinary.com
Why People Initially Suck at Programming
1–10 of 41 posts
Re: Why People Initially Suck at Programming
#2One 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.
Re: Why People Initially Suck at Programming
#3> "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.
Re: Why People Initially Suck at Programming
#4I'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.
Re: Why People Initially Suck at Programming
#5One 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 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.
Re: Why People Initially Suck at Programming
#6One 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.
Indeed. Making good software requires systems analysis in addition to programming, but it is often taught poorly or not at all.
Re: Why People Initially Suck at Programming
#7I 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.
Re: Why People Initially Suck at Programming
#8One 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…
I prefer to write it out with pen and paper. After all, most of what you do when you code is come up with a solution to a problem and then implement it. It's a lot easier to play with your solution when you're still forming it than after you've already typed it up.
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.
Re: Why People Initially Suck at Programming
#9I 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.
Re: Why People Initially Suck at Programming
#10One 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. 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.