Hacker News Reader

Comment by mx12 | Hacker News Reader

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.

View on HN

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.

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.

I do too (and wow isn't it a wonderful feeling on the rare time when you write a whole page of code and it compiles and runs right the first time?) but I certainly couldn't do that when I first started, and trying to do so just made me get lost in a morass of logic mistakes and compiler error messages. It seems like lots of beginning programmers naturally want to write a ton of code right out of the gate and they have to be taught to do otherwise.

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.

This is the normal way that I write code. But sometimes I feel really confident and write a couple hundred lines without compiling. Then it's always fun to find out - did everything "just work" or did I omit something?

That's pretty much exactly what I do too- I'll start with maybe 10-15 lines before testing. I don't know why ANYONE would go a day without compiling or running

coding is very different kind of task, requiring a very different sort of approach, to the kinds of tasks most people are familiar with. most other tasks are no way near as exacting, etc. we are creatures of habit, we approach new tasks with the kinds of approaches we are familiar with using, and it simply takes time to learn how to approach programming.

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

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.

But they can't show you if you have logic errors. The more code you write without testing it, the harder it is to test.

I think you one should always map out his or her data structures first. Form follows function.

Indeed. Making good software requires systems analysis in addition to programming, but it is often taught poorly or not at all.

Reply on news.ycombinator.com