Forgot your password?
typodupeerror
Programming Education

Learning To Code: Are We Having Fun Yet? 226

Posted by timothy
from the 10-sin-20-go-to-hell dept.
theodp writes "Nate West has a nice essay on the importance of whimsy in learning to program. "It wasn't until I was writing Ruby that I found learning to program to be fun," recalls West. "What's funny is it really doesn't take much effort to be more enjoyable than the C++ examples from earlier...just getting to write gets.chomp and puts over cout > made all the difference. Ruby examples kept me engaged just long enough that I could find Why's Poignant Guide to Ruby." So, does the future of introductory computer programming books and MOOCs lie in professional, business-like presentations, or does a less-polished production with some genuine goofy enthusiasm help the programming medicine go down?"
This discussion has been archived. No new comments can be posted.

Learning To Code: Are We Having Fun Yet?

Comments Filter:
  • by YttriumOxide (837412) <yttriumox@gma i l .com> on Monday September 23, 2013 @08:09AM (#44922795) Homepage Journal

    The important thing about learning to code is keeping interest/motivation to do so.

    I agree with the general approach that the essay espouses - whimsy is a great way to keep interest; but it's certainly not the only way. Different things work for different people. My daughter is two and a half years old, and so far has totally rejected learning that involves traditional 'reward' such as the way gCompris shows 'happy' images on completing tasks vs 'sad' images when failing. However, what seems to do it for her is being able to 'show off'. When she can make her grandmother surprised by being able to point out letters of the alphabet on things, she is much more motivated to learn and get it right.

    I'm sure my daughter's learning style will develop and change as she grows; I just wanted to use an example that demonstrates not everyone is motivated to learn in the same way. I don't think coding is any different.

  • The classic (Score:3, Insightful)

    by Anonymous Coward on Monday September 23, 2013 @08:10AM (#44922799)

    I like to learn this way better than that way therefore this way is better.
    Yes, for you. That way may better for others perhaps even most.

  • by YttriumOxide (837412) <yttriumox@gma i l .com> on Monday September 23, 2013 @08:30AM (#44922885) Homepage Journal

    You had better get involved and start steering her in the right direction, pronto.

    People who grow up depending on recognition end up miserable. She's going to give it up when she's 13 to get approval from some boy she likes if you don't nip this in the bud.

    To an extent, it's perfectly natural to depend on recognition. If she totally relies on it for value of herself, then yeh, that's bad. I'm not going to start worrying just yet though.

    Regardless, I don't want her to be like me - socially retarded and awkward right until my early to mid twenties. A lot of 'geeks' like me think it's a prerequisite to be socially awkward if you're smart. It's not. You can be smart, geeky AND popular.

    Sure, if she does end up being that way, I'll support her (I'll support her no matter how she ends up) but I'll do my best to steer her in the way that I feel is going to help her achieve the greatest amount of happiness in her life.

  • by rcs1000 (462363) <rcs1000@gm[ ].com ['ail' in gap]> on Monday September 23, 2013 @08:42AM (#44922943)
    If you want people to enjoy learning to code, you need to give them a combination of:

    1. A toolset they can use to build useful projects
    2. A language they can grasp easily
    3. And a genuinely useful project they can achieve

    Everyone's best coding experiences have come from a desire to do something, combined with the right tools to achieve it. In the early days of 8-bit computing and BASIC, this was about making a game where the computer said "I've thought of a number between 1 and 1,000", and then you guessed and it told you you were too high or too low.

    When you got that going, that was an extraordinary sense of achievement. "Look ma! I've made a simple game, you can enjoy!"

    And then came Windows and complex APIs, and languages like Visual Basic that abstracted too much from the users, such that much that happened was 'magic'. Who - given a computer these days - begins to think "how do I *make* something amazing?"

    Fortunately, things are getting better. The right languages are now available - most notably Python, Lua and Ruby - all of which are proper programming languages, but which are also easy to learn.

    And the Raspberry Pi [raspberrypi.org] project comes from the right place. The issue it has, perhaps, is that people don't want to produce Raspberry Pi apps - and that desktop apps for Linux, whether written in Ruby, Python or anything else, are hardly childs play.

    A better option for deploying a *real* app, people want to use, a modern equivalent of the guess the numbers game, must be either an app for a smart phone, or it must be a web app which can be deployed (for free) in the cloud. In which case, I think there are two or three options. (There used to be more, but Heroku Garden is no more). For smartphone development, Corona SDK [coronalabs.com] is fairly mature and works with both Android and iOS. For a web app, there are a few more options, of which PythonAnywhere [pythonanywhere.com] is probably the best of the bunch.

    I suspect a decade from now, the self-taught developers will have mostly learned their craft in one of these languages, building useful apps for smartphones or the web.

  • by K. S. Kyosuke (729550) on Monday September 23, 2013 @08:46AM (#44922991)

    Everything just fucking works, even when some parameters are wrong and you're mixing variable types all over the place. /duck

    That's probably because you're a "duck"-typing programmer.

  • Translation (Score:4, Insightful)

    by Anonymous Coward on Monday September 23, 2013 @09:00AM (#44923059)

    When I hire a programmer, my first goal is to find out how much fun they have coding. Without that, I don't hire them.

    Translation: I want someone to work his ass of to the bone for shitty pay because he loves it.

    I USED to love to code. Then after about 4 -5 years of the 55 -60 hour work weeks to meet the deadlines set by sales and having to keep up with technology at home (more coding), I just got to the point of disliking it. Burnt out.

    BUT - I get the specs: I get the job done - on time. And then go home to the family and my tennis game. I work to live: NOT live to work. I have balance in my life and I'm MUCH happier.

    Having someone "Love" it is like dating in high school - they're out of love at the end of the Summer.

    I talked to career councilors, they told me to stay in development/computers; so it's not me, it's the screwed up industry and its idiotic notions of what makes a "good" programmer and employee.

    Perhaps if folks promoted folks who actually have grown up and gotten beyond the adolescent idea of "you are what you do" and "you must have passion" that maybe there would be changes in the working conditions.

  • by shellster_dude (1261444) on Monday September 23, 2013 @09:00AM (#44923063)
    A good programming language is not one that is full of fucking "whimsy". A good programming language has a clear, concise set of commands which are self documenting. It should be difficult to write the same, simple function in multiple ways. Ruby fails on all accounts. The wording is inconsistent, there are about 45million different ways to write any given function which also means it is hardly self documenting.

    I've rarely met a Ruby developer who was employable in another field because they simply don't know what constitutes good, clean, concise code.

    I've got karma to burn...
  • by ggraham412 (1492023) on Monday September 23, 2013 @09:18AM (#44923181)

    Perhaps the most soul crushing phrase you will ever hear as a programmer is: "Don't re-invent the wheel."

    Go ahead, re-invent that wheel every now and then. That's why you got into programming in the first place. You can do a better job.

  • by Anonymous Coward on Monday September 23, 2013 @09:51AM (#44923475)

    Amazing how many experienced coders are venting here about their favourite toys, my favourite colour is blue, I'd never use anything but an estwing hammer, snap on tools rock! Who gives a toss what language you love and which one you hate, the story was focussed on people learning to code, not the jaded ramblings of people who blame the technical implementations of others.
    The best thing you can do is not learn to code at all if you end up sounding like a dick.

  • Re:Translation (Score:4, Insightful)

    by Greyfox (87712) on Monday September 23, 2013 @09:54AM (#44923493) Homepage Journal
    That's funny. 25 years later, I still have a blast coding. I've never taken a job I though would be boring, though I have run across some companies that one should avoid like the plague. Oddly, I've found IBM to be among the most fun companies to work for. Also oddly, when I was contracting there, Sun was not a very fun company to work for -- I'm pretty sure the job of the guy one cube over from me was to talk on the cell phone all day about how he was a process blackbelt. They had a 12 page form you had to fill in to get them to unlock version control for changes. Despite this and code reviews for each change, code quality was some of the lowest I've ever seen. The programmers there told me that a few years earlier the place was much more fun to work for, but it seems to me the additional perks the company brought in at the height of the boom were not oriented to making the programming more fun. Then when the bottom line started to slip, they not only got rid of those but also added ISO to the mix, sucking all the fun out of the actual job. I was there for a few months just before Oracle took them over.

    Echostar was the least-fun place I've ever worked. Despite the fact that they had fairly interesting problems to solve and interesting hardware to work on, their corporate culture leads me to believe that they despise having to have employees, and the quality of their work reflects that. So it is actually possible to make fun problems to solve not-fun. Next job after that was back at IBM working with an AWESOME team with room to improve code quality as time went on. We generally only put 40 hours a week in there, got all our stuff out on time and could have kept our pace up indefinitely. Amazing how much of a difference corporate culture makes.

    If you're not having fun programming on your job, maybe you're working for the wrong company. If you're the kind of programmer who actually enjoys programming, it's not that hard to find a position with a company that's more fun to work for. All you really have to do is look.

  • by YttriumOxide (837412) <yttriumox@gma i l .com> on Monday September 23, 2013 @09:57AM (#44923515) Homepage Journal

    The important thing about learning to code is keeping interest/motivation to do so.

    You spoiled-rotten 21st century golden billion... Having to learn a trade has nothing to do with it, has it?

    Honestly, no. The vast majority of things that someone learns in this modern day and age have nothing to do with their 'job'.

    I'm a software developer (and will be trying to transition to full-time author once I get a few more books out (especially with more mainstream subjects than my current one)). Nevertheless, most of my daily 'learning' is focused on chemistry, physics, linguistics, pharmacology, medicine, and writing. Sure, I still learn a lot for my day job - if you're a software developer and you don't, you won't last long - but it doesn't make up even 20% of what I learn each day.

    I know a lot of coders. Most of them do it as a day job as well, but not all. Even amongst those who do, it's the passion for it that keeps them doing it rather than just putting food on the table. Sure, that's extremely important and a definite bonus, but they'd probably still code at home if they had jobs as accountants, lawyers, doctors, or McDonalds counter staff.

  • by tuffy (10202) on Monday September 23, 2013 @10:08AM (#44923615) Homepage Journal

    Even if you don't wind up doing a better job, reinventing the wheel is a good way to understand how wheels work. So the effort isn't wasted if one learns something at the end of it.

  • Fun Joy Beauty (Score:5, Insightful)

    by John Allsup (987) <.s.chalisque. .at. .gmail.com.> on Monday September 23, 2013 @10:09AM (#44923619) Homepage Journal
    These three are the key to motivation in many activities.  Without fun it's hard to get started, without joy it's hard to keep going, and only later do you see the beauty, first hand, that you can achieve through really mastering a discipline.
  • by Murdoch5 (1563847) on Monday September 23, 2013 @10:19AM (#44923691)
    Well just buying something simple and well supported like the Arduino, then you can literally learn by examples and trial and error. I would recommend not touching OO languages until you're well versed in C because OO languages don't offer a good interface with memory and architecture, which I personally feel are essential for good programming. When I learned to program I started at the machine level with ASM and then moved up to C. I've done a ton of C++, PHP, C#, Java and etc.. but they just don't compare to C for both understanding and ease of use.
  • Perl epiphanies (Score:5, Insightful)

    by goombah99 (560566) on Monday September 23, 2013 @10:27AM (#44923761)

    I had much the same reaction to perl. I love perl for many reasons. One is that even though the native language without any imports is more powerful than almost any other languange (without imports) the O'reily nut shell guide is the thinest one on my shelf. It really says something about incomprehensibility when even the C++ nutshell guide is thicker than perl. It means that even though perl might seem very ad hoc, in fact it's so self consistent that you can write it all up in a tiny guide.

    What really sold me on perl was writing object oriented perl. I had been doing object oriented programming for some time in multiple languages including java and Objective C, but what really made me understand it was perl. In perl you actually see the underside magic of what an object actually is. It's remarkable that the language of perl could go from not having any objects to having objects just by adding one additional command ("bless"). Nothing else in the language had to be re-written. Internally one is storing all the instance variables in a single hash. What's interesting is that you don't have to choose that mode of data organization. you can instead bless a scalar. then you can have the class rather than the instance manage the instance variables. Effectively a hash is a row oriented data base and a scalar is a column oriented data base. When I realized this I was sort of staggered how many high concept ideas were rolled up into the perl method of objects.

    I went back and implemented a hash in fortran 77. After that I could write Object oriented fortran 77. yep that's right fortran can also be an object oriented language just doing the same trick perl does. All you then are missing is dynamic memory allocation for it to be complete.

    While may people curse perls prefix sigils I actually find them conceptually compact. In most languages the notion of a type, and the construction of a primitives data, get conflated. Really these are different things. Perl makes this explicit. A primitive in perl can have a data organization (list, hash, scalar, reference, dereference, glob) signified by a pand it can separately have a package inheritance (@ISA) that is analogous to a type. In languages like C++ or most everything those two concepts are not distinguised heavily. As a result I find it easier to read a perl program because of all the explicit data structure prefixes.

    What kills perl in the end for complex programs is not these sigils looking like cursing on the page, but rather that everyones programming style is different, so it gets pretty crazy to read because it's so compact. It's perhaps a compliment how compact it is. It's interesting that the less compact and less versatile a languages native syntax is the easier it is to read.

    But it's true. Try reading APL, the most dense language ever devised. then try reading Lua or (early) python. Both of those are a breeze to read other people's code.

    When I read ruby what I see mainly is an extended perl syntax that can avoid using these despised prefix sigils. It gives the objects syntacic sugar, like python does, to hide the object mechanics from you. So it's a very clean looking upgrade to perl.

The flow chart is a most thoroughly oversold piece of program documentation. -- Frederick Brooks, "The Mythical Man Month"

Working...