Beginner Tutorials

[Rick Johnson]

On Friday, January 18, 2013 10:36:09 PM UTC-6, Evan Driscoll wrote:
> I have only skimmed this thread and so am unsure exactly what is being
> protected against casual copy/paste, but at least on its face I would
> *vehemently* disagree with your statement.

Well if you skim just a wee bit more you will see how i took a view from both sides of the argument :)

> There are at least two significant problems with it. First you ignore
> short-term pressures. 

I think we can all understand short term pressures (especially those among us who actually work for a living) however, cheating not only harms the cheater, but also degrades the value of the education that the fellow students worked honestly to achieve -- that's my real beef.

> But the bigger problem is that -- while you are right that programming
> is problem solving -- doing problem solving is probably not why most
> people got into it. At least personally, I got into it because I liked
> making stuff. 

Is not "making stuff" a form of problem solving? You may not enjoy writing code because it solves a real world tangible problem (like a calculator for solving math equations or a spreadsheet for organizing data, or flight control software... wait, don't use python for the last one!) but the "act" of creating anything involves solving problems, yes? 

 * What am i making?
 * What language provides the tools i need?
 * How will it interface with the world?
 * What will it do? (Even if only to not throw an exception) :)
 * Will it be automated or require input control?
 * GUI or command line?
 * What dependencies will it require?
 * etc...
 
And that's just the initial draft design phase. These handful of problems have deeply nested sub-problems hidden below.

But maybe you are referring to the satisfaction you get when witnessing your "creation" in action. Ah, yes. This is a great feeling! Especially when you've worked for hours tracking some subtle bug because of a bad language feature or poor interface and you almost threw in the towel twenty times, but /something/ kept you coming back. What was it? Was it the fact that you would not allow yourself to be defeated? Was it the addiction to the satisfaction you get from creating a program that runs without error and actually does something useful? These are the monkeys on the back of every good programmer. 

> If someone is attracted to the field because they go "oh
> hey I can program the next video game!" that doesn't automatically mean
> that they won't be good at it, but it may be that the problem-solving
> aspect of it is an acquired taste.

Like these people you mention, my initial interest was very specific. I needed to create a few tools for myself, and i thought that would be the extent of my programming. But after writing a few apps i was hooked! And as i progressed writing more and more code, i became more and more addicted. Coding actually transformed the way i interpret the world. I am constantly looking for consistency, logic, intuitiveness in every interface around me. That could be my car, my toaster, whatever. But most importantly, programming has honed my problem solving skills to razor perfection! Especially OOP. Which can be transformed into many problem domains.

I think a lot of energetic and naive people get attracted to writing code from games, however, once they start up the steep learning curve without an ability to problem-solve (or a good starter language like python), they get frustrated and quit. These people cannot problem-solve themselves out of a wet paper bag! 

And i think a good programmer, along with being a great problem solver, is a bit of a risk taker. I mean, how else are you going to learn without taking risks. An infinite recursion here, a segfault there... accidentally used rmdir on your porn folder, oops! It's all part of cutting teeth.

Another trait of the programmer, an innate sense of curiosity. A good litmus test is to offer a complicated software application to a group of people of which none have used before and all are unfamiliar with. 

Then, see who becomes proficient with the interface. That's the subgroup who will make great programmers! While the dummies start out reading the manual, the natural problem solvers will jump head first into the interface and attempt to intuit every command. 

When, after exhausting all there comprehensive abilities, they don't understand a certain feature, then and *only* then do they consult the docs. And sometimes, the doc are just insufficient anyways. 

But the point is, the true problem solver discovers his own weaknesses, takes mental note of them, and then methodically *DESTROYS* them. Divide and conquer. 

This is the method by which intelligent beings solve problems.

> As an analogy, I've been rock climbing for several years. There are
> several types of climbing; two of them are top roping, which is roped
> climbing and what you see most people in a climbing gym doing, and
> bouldering, which is climbing routes low to the ground (usually under 3
> meters or so) without a rope. When I started, I basically exclusively
> did top roping. Bouldering seemed... dumb to me, like it was missing the
> point: "the reason you go climbing is to *climb*, and bouldering gives
> you very little of that." :-) But after I was going for a while, getting
> high above the ground became less of why I did it and the challenge of
> figuring out the right movements and such to complete the route started
> being my primary motivation for liking it. And those are things that
> bouldering has in fine measures; in some respects, it does that *better*
> than roped climbing*.
> 
> (* Arguing about roped climbing vs bouldering might be that community's
> version of "Emacs is better than Vi". :-))

That was a great analogy!

> In other words, why I started climbing is very different from why I
> continued it. And I feel that the same could be said of programming.
> Just because you don't enjoy parts of programming when you're starting
> out doesn't mean that you're a lost cause by ANY means.

I agree completely. However, my condemnation was mainly against cheating.