Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
In this Discussion
Week 2: Critical and Creative Coding – Calvinball and Coders
Calvinball and Coders
For those who, like me, grew up looking forward to my daily Calvin and Hobbes strip, Calvinball is a pure expression of imagination, creativity, and six-year-old innocent fun. Calvinball is a game that is made up as you play it and the only rule is that you can never play it the same way twice. For the purposes of this CCSWG I’m going to rephrase that rule and possibly ruin some programmers’ childhoods: when playing Calvinball, Don’t Repeat Yourself.
DRY
Depending on which programmer you’re talking to, Don’t Repeat Yourself (DRY) might be a good guideline, a Platonic ideal to be sought after, or a form of viral pedantry that gets in the way of writing software. It’s the idea that, particularly in object-oriented languages, you never want multiple pieces of code that fulfill the same function. As the argument goes, duplicating code introduces more potential for errors that are harder to discover and diagnose, makes a codebase harder to maintain, and generally complicates everything. There are any number of ways to apply this principle in practice (I like the three strikes rule in many contexts) but it is almost exclusively supported by utilitarian/functional arguments in computer science texts and forum discussions.
What’s My Motivation?
When discussing DRY, what I think is often left unsaid is simply that programmers like playing Calvinball. They enjoy creating new mechanisms and structures more than they enjoy repetition; a canonical joke is that a programmer would rather spend an hour writing a script than ten minutes doing a repetitive task by hand. DRY is a principle that wraps creative urges–play, rather than work–in a cloak of functional respectability†. This is not to say that the DRY principle, or the functional arguments behind it, are illegitimate. It is true that DRY can simplify maintenance, among other things. However, when thinking critically about code and examining the motivations of a programmer at the granular level of individual statements, motives of utility and creativity can be hard to tease apart.
For this discussion, I’m going to split the DRY mindset into two concepts based on what drives a programmer to think and work in DRY terms:
- Calvinball-DRY – The creative play motivation
- CS-DRY – The utilitarian motivation
In doing so, though, it’s important to keep in mind that the two can be very difficult to separate in practice. The two motivations may very well produce the same DRY code that leaves no way for a later reader to tell them apart. But in other cases a DRY process–from the programmer’s perspective–may not lead to DRY code. For example, I wrote a piece called Asterisk Painting for an art installation several years ago. The complete Processing code is below:
/**
Asterisk Painting is programmed to create a series of asterisks by repeatedly printing the number of
milliseconds that have passed since the painting started. If left to run by itself it will do so; however,
when started on a real system, delays external to my artwork may make the asterisks look more like
spots and the painting may resemble the work of certain other overly-litigious artists.
**/
//int xDim = 1920;
//int yDim = 1080;
int xDim = 1440;
int yDim = 900;
PFont theFont;
float timer=0;
float speed=100;
float maxSentences = 77;
float sentences = 0;
float[] xPos = {1,2,3,4,5,6,7,8};
float[] yPos = {1,2,3,4,5};
int xCtr = 0;
int yCtr = 0;
int waitTime = 10000;
int itr = 0;
int milliStart = 0;
PImage sig;
void setup(){
background(255);
noCursor();
size(xDim, yDim);
sig = loadImage("signature-small.jpg");
image(sig, xDim-92, yDim-50, 82, 40);
theFont = loadFont("Luvia-48.vlw");
for(int i=0; i<xPos.length; i++) xPos[i] = xPos[i] * (xDim / (xPos.length+1));
for(int i=0; i<yPos.length; i++) yPos[i] = yPos[i] * (yDim / (yPos.length+1));
fill(0);
textAlign(LEFT, CENTER);
text(itr, 10, yDim-30);
fill(random(0,255),random(0,255),random(0,255));
}
void draw(){
int currentMillis = millis() - milliStart;
if(currentMillis > timer){
pushMatrix();
translate(xPos[xCtr], yPos[yCtr]);
rotate(radians((float)(360/8)* (float)(millis()/speed)));
timer = currentMillis + speed;
text(nf(currentMillis, 6), 3, 0);
sentences++;
if(sentences >= maxSentences){
xCtr++;
if(xCtr >= xPos.length) {
xCtr = 0;
yCtr++;
if(yCtr >= yPos.length){
saveFrame();
yCtr = 0;
background(255);
itr++;
popMatrix();
fill(0);
text(itr, 10, yDim-30);
image(sig, xDim-92, yDim-50, 82, 40);
int wait = millis() + waitTime;
while(millis() < wait){}
milliStart = millis();
timer = speed;
pushMatrix();
}
}
sentences = 0;
fill(random(0,255),random(0,255),random(0,255));
}
popMatrix();
}
}
The result looks like this:
If you compare the code to the output then a couple of variable names seem incongruous: sentences and maxSentences. There are, in fact, no sentences in the final output. The sentences variable is actually counting the number of times that the milliseconds counter has been printed to the screen in any given asterisk. When sentences goes above maxSentences, the code moves output to a new asterisk.
The reason for those names has nothing to do with anything in this piece of code. They are there because Asterisk Painting started life as a copy/pasted script from another piece I was working on at the time, Finite Monkeys. That piece searched the Twitter firehose for the word ‘love’ every thirty seconds and compared the results to Shakespeare’s Sonnet 18 (“Shall I compare thee to a summer’s day...”), displaying the most similar tweets on screen. In that code, sentences and maxSentences were used to count target tweets and cap them at a certain number for performance reasons. The two variable names are just the breadcrumbs left behind that provide evidence of duplicated and modified code.
When DRY Isn’t DRY
Copy/paste workflows are generally considered the opposite of DRY–they duplicate code that, under DRY principles, should be maintained in one place and invoked elsewhere. This code isn’t CS-DRY. However, it is Calvinball-DRY. Even though my code repeated itself, I, the programmer, didn’t have to repeat myself. Copy/paste coding separates the creative personal motivations for DRY from the utilitarian public justifications.
This is not to say there is a 1:1 correlation between copy/paste code and creative motivations. However, finding code that’s been copy/pasted does provide insight into the programmer. Zooming out a bit, the prevalence and acceptance of copy/pasted code across the industry also suggests something about programmers as group. Many of us are professional Calvinball players, motivated as much or more by creative exploration as by trying to accomplish a task.
When Creative Isn’t Creative
There’s a caveat to the idea of creativity in both Calvinball and Calvinball-DRY: it’s narrowly scoped. Calvinball only exists inside Calvin’s head. Despite a couple of attempts to get other people to play it with him, nobody really does so consistently (the imaginary Hobbes aside). The idea of other people playing Calvinball introduces a new wrinkle though: what does it mean that “the only rule of Calvinball is that you can’t play it the same way twice” if there are multiple players? If I create a rule in my Calvinball game, does that exclude you from creating that same rule in your separate Calvinball game? Is creativity global or local?
For Calvin, who couldn’t care less about the rest of the world as long as he’s having fun, the answer is probably that creativity is local. I’d suggest the same is true for many programmers: if we suppose that Calvinball-DRY is a desire to scratch a creative itch then it shouldn’t matter whether someone else has already solved a problem in the same way‡. If that other solution isn’t known to the programmer then writing it represents personal novelty and answers a creative urge. Locally creative is good enough, even if an outside observer wouldn’t call a particular bit of code novel or creative.
Finding the Breadcrumbs
I don’t think the idea that programmers are partially driven by a desire for creative play will be particularly controversial among this group of participants. However, my goal in starting this discussion is to look for signs of creative motivations even if the code itself is boring, functional, or straightforward. What code have you seen that suggests a programmer is playing even when the goal of the program is functional? What are the indications that getting into a programmer’s head will lead to a piece of code being more appropriately read through a creative lens than a functional one, and when (if ever) are the two separable? After all:
† Functionality being rather easier to justify to middle management than creativity, of course.
‡ Some coders treat code more as a performative medium; this probably wouldn't apply to them.
Comments
Please what's the name of the programming language and how can compile it? I want to learn? Please can you send me an email of this code this explaination.waliyayohannajoseph@yahoo.fr or @unical.edu.ng. Thanks. It is charming code.
Thanks! That code is in Processing - you can download the environment here: https://processing.org/download/. Note that it was written for Processing 2. I haven't tried it on 3 yet, but I think it will work (it might need a minor change somewhere). Processing is a really nice environment for learning because it's good at giving you immediate visual feedback. The download page has links to some really good tutorials as well.
The complete code is above, but it does require a couple of external assets–the font and image file–to run. Those can be easily replaced if you want to try it though.
Thanks very much @belljo . Can I code an image into the code?
The image file this code references is just my (fake) signature at the bottom-right of the screen. It's loaded on line 31 and displayed on 64. You can use similar calls to display any external image file on the screen.
For example, I want to upload images instead of the asterisks, is there class image in the processing?
Do you have processing YouTube where I can get the recorded video tutorials?
@waliya I have a few older videos, but there are much better ones out there. I'll send you an email with some resources.
I love the argument here. Can I try to paraphrase (refactor it)?
Did I get that right, @belljo?
I might say recycled code is a sign of wanting to spend time being creative rather than actual creativity. But otherwise, sure, sounds good.
Also, I did not endorse pirate hats, but think they're an excellent suggestion.
I do think that there is a certain playfulness in coding. I completely buy the argument that DRY mindset can be an aspect of that creativity, providing an excuse to do something novel.
When I think about this I think about the field of pure math, a code structure that exists almost purely to relate to itself. I've never met a mathematician who didn't seem delighted to play with the logical systems they've created, and something like 90% of the field is finding new proofs for things that have already been proved just for the hell of it.
I remember 'The Mathematician's Lament' by Paul Lockhart which likens math to painting or music as an artistic form of expression. In much the same way, I do believe many coders get the same kind of feeling of artistic expression out of their work.
Very interesting reflection! We can approach code reuse forensically -- what are the traces that indicate its origins and sources, where are the fingerprints that indicate how it was altered?
I also think about the rise of the term "script kiddie," which implied (and expected) a kind of cobbled-together, punk-aesthetic, anarchist's cookbook of hastily refashioned code being reused to different (often nefarious) ends. In the Processing forums when helping (primarily) student first-time programmers, there is also sometimes a moment when a community member might say "this code isn't yours, is it?"
Race, gender, and power is one interesting way to think about this question of tracing origins, and one of the many ways reuse and creativity are related. Creativity is sometimes presented as the ability to claim something as original, as ex nihilo, and in such framings there are still many prior contributions that build up to support a new act at their pinnacle, yet they all disappear in the retelling. I'm thinking of the vanishing of credit (e.g. women and minority computers quietly disappearing from the history of computing) but also of labor in general, and perhaps of auteur theory as it relates to the stories coders may tell themselves and about each other: the coder as a creative genius (who nevertheless stands on the shoulders of millions of lines of APIs, libraries, frameworks, operating system code and network code, et cetera). It is the nature of both corporate systems and globalization that of the expansive layered code (the platforms and layers below in Montfort and Bogost's terms, the Stack in Bratton's) some of the those code contributions are recognized and celebrated, and others are anonymous labor that occurred in some undefined past far from the bright lights of tech startup profiles and venture capital.
This is not to say that open source culture and creative coding culture does not encourage people to recognize, acknowledge, and be grateful for each others accomplishments -- just that DRY may also treat making infrastructure invisible as an efficient best practice. When we import once in the header, the library on which a new project is built may remain -- to an extent -- off-stage or behind the curtain, and indebtedness and interdependence is something that can be forgotten until it becomes a problem. So, for example, Azer Koçulu removing the tiny program
left-padfrom the NPM commons in the 2016 resulted in: "How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript". The community at large seemed generally surprised to remember that they were using Koçulu's work at all - until it was removed.Did anybody know about hologram or lego coding? I am thinking these two can be in poetics of coding? I just want to know.
About automation, there's a relevant XKCD comic (as always):
About copy-pasted code, another joke:
This idea of the solitary creative genius is an inheritance from the Romantics. I'm a medievalist by training, so have studied a period that recognized labor, creativity, and predecessors in a way that seems to me far more applicable to our current conditions. Often, medieval authors (Chaucer included) would preface their literary outputs as little more than a translation of older authorities. From "The Anxiety of Auctoritas":
Add in the networks of labor that produced medieval manuscripts—scribes, illustrators, binders, etc.—and you have a model that I think more closely approximates how contemporary developers work. The reliance on libraries, as @jeremydouglass points out, is absolutely critical for adhering to DRY principles, for efficiency, for avoiding the tedium of recreating solutions to already solved problems (granting the coder room for more creativity, as others have pointed out), and a model that would have seemed very familiar to a medieval. All knowledge was accumulative. New ideas needed to be slotted in to existing frameworks and, to be accepted, often presented as something actually in one of the old masters ("auctoritas"and not something new. Perhaps, then, one way we could recuperate the invisible or underappreciated labor of others is to be to return to a medieval recognition that everyone draws on previous authorities and that labor is distributed across multiple guilds / specialties, even (especially these days) when it comes to code. It also gives us more space to think about code remixing, compilation, copy-pasted code, etc. as creative acts in their own right.
First of all, really thanks for @belljo who posts the processing code and raises such an interesting argument that I also find very difficult to separate the two creative practices in terms of both versions of DRY: CS and Calvinball. I always think that the nature of coding practice is in itself creative, in terms of structuring code, neat writing, thinking ways to implement, and solving specific computer related problems (or perhaps it is even linked with the notion of play because you are addicted and motivated to solve a particular problem. If you have successfully solved it then this gives you a rewarding pleasure which is similar to game play? ) The term ‘creative coding’ is sometimes misleading, but of course, I know the term is more emphasis the creative expression than the utilitarian aspect. However, I do think that the two are hardly separated. I mean functional aspect is always part of the creative expression, and may be vice versa too because structuring code is also a kind of design and expression.
I have downloaded @belljo’s code- the Asterisk Paining, and I just observed what I have done to the code and what I have been thinking. From copy and paste to comments some of the code, changing parameters to actually know what’s going on, as well as thinking why the author writes in this way and if there might be a different way of writing both in processing or if I port this into other languages like p5js. Some of the functions might not available in other languages and so how to find a replacement, etc. Conceptually, I have been thinking about the micro-temporality of code and the granularity of machine processing. How the micro-time might have implications in a wider context that is departed from this smaller art piece? The work, indeed, is a fascinated piece, at least for me.
When talking about repetition, I also think about if this is purely a copy and paste action and what might be the differences? Instead of using the term reuse, perhaps remix is a better way to capture the very essence of copy/write code? Because you never just stay at the copied and pasted version, where for me I will try to hide some codes, change parameters and add something to understand what is it and how people write it, potentially how to use it. May be It is a process of transformation from copy and paste to remix. It is similar to use/import a code library, where ultimately you will incorporate/modify the function into your own piece of code.
If talking about recycling code (which I also do so in my own works), I believe it is also a form of creativity that one needs to adapt and integrate the code snippets in different scenarios. Therefore, I would argue that this is also a form of creativity. Of course, from a utilitarian perspective, you save some time in building something again but you probably spend time on other parts of the entire code.
Thank you for this comparison! I'm not sure I have a lot to say about it at the moment since I don't have that background, but it does plant a seed for me that I'll have to do some research and follow up on later. We seem to spend a lot of time in DH talking about labor and credit extending to a community (particularly the tech part of it) rather than focusing on an individual. The same problem goes the other direction as well, of course, when developers don't want to acknowledge or credit users that define the functionality of the software they write (with bias consequences mentioned in week 1).
The actions of a script kiddie and a programmer are often exactly the same–they grab code someone else wrote and use it for their own purposes. The difference is just that a script kiddie doesn't grok the code while a true Scotsman programmer does. To tie it back to forensics, it would be interesting to compile a list of examples of tells that show when a programmer does or doesn't understand their own code. As you mentioned regarding the Processing forums, it's often pretty easy to see. The most difficult part might be to convince people to interpret such a list as non-pejorative.
This also ties into the comment @jeremydouglass made about race, gender, and power. Because this is a historically older model in the Western trajectory, the idea of the lone genius Romantic author is frequently treated as an advance--and so when African Diaspora creativity relies on community and iteration, or Indigenous intellectual contributions are thought of as stewardship rather than ownership, or women produce crafts in a communal tradition, we have a hard time seeing them as authors.
This then sets up a tension between credit in a way that is legible within a Western-masculinist model and credit in the terms valued by the people doing the contributing. I'm very interested in this idea of forensic examination of reuse--who did what, when, why, in relation to what enabling structures. But it does present some challenges.
One interesting thing about version control in software is that some systems are meant to reccord their own histories -- to a degree, and from certain perspectives. Office documents (such as Microsoft Word or Google Sheets) implement "track changes" features which give a history of revisions and may include the identity of each editor; in coding there are version control systems (such as git, Mercurial, subversion, or CVS) which can trace complex graphs of edits by huge numbers of actors, such that any line of code is attributable to an edit.
On the one hand, this abundance of record-keeping means there may be a lot of available material for forensic methods! On the other hand, the paradigm of these systems is individual credit and accountability, so we need to be aware that there much that may be missing from these records: for example, contexts and infrastructure which contain the edits and make them meaningful, coding folk traditions and reuse from coding commons that would never be named in individually credited edits, and commonplace acts of machine authorship (such as boilerplate code generated by IDEs) whose templates were themselves often created by unnamed coders.
In addition to omissions, whole sections of these histories are periodically forgotten as they are "cleaned up" into simpler and more cohesive narratives. They are pruned, "squashed" and merged, or even automatically culled and thinned as they recede in time (e.g. the cloud-based history of a Google Doc).
Pervading these systems of versioning and change-tracking is the double-edged logic of credit and accountability that comes with an emphasis on the individual. Checking a code change into a Github open source repository is a "contribution"; the method for identifying who last changed a line of code in git is called "blame".
Thank you @belljo for this tethering of DRY to Calvinball! What an excellent mnemonic device for remembering this design methodology, and what a great analogy for guiding contemplation of the (better) utility below its (claim to) utility. :-)
In rules-engineering for American larp, we have what we call design methodologies like "use small math" and "separate core rules from setting." The reasoning for using these methodologies is for UX purposes, insofar as these paradigms aim to guide the rulemaker in developing code that is easy to handle. This is important because in larp, our code is intended to run on humans rather than machines, so you really want to go easy on how much code your players have to memorize before they can cut their teeth on your game.
While reading your post, I started thinking, "Wow, this DRY stuff sounds a lot like Russian larpmakers."
Those crazy Ruskies pride themselves on designing whole new rule systems for every larp they make. Like, literally they will design a rule set be to be used once, for a single weekend-long game, and then they'll just throw it all out when it’s done, and never use those rules again. This really leaves American larpmakers scratching our heads.
Like, here, the way we approach larp design is a lot like the way we build our houses, at least most of our houses. Like, rather than hiring an engineer to build the water and electrical systems of a new house, you've got a bunch of pre-fabricated parts the architect can draw from, and she doesn't need to understand how they work because the engineers have written themselves out of the picture by designing city building codes and interlocking parts that any jerk with a library card can figure out how to use.
Why do engineers do this thing, this building of themselves of out such tasks? I imagine it's a lot like why programmers use DRY, or as you put it "a programmer would rather spend an hour writing a script than ten minutes doing a repetitive task by hand." It is a love of getting to solve new problems, of using this amazing expressive skill of coding/engineering to do things, rather than being trapped as someone whose job it is to hold things in place.
In American codic larpmaking, we build our larp rule sets a lot like how we build our houses: drawing from a pre-fabricated set of parts. Like, a rules engineer, let's say in Boston, comes up with a rule that says "When you say "I heal you" while pressing a glow stick to someone's arm they gain 5 Life Points (LP)." and maybe they write 300 interlocking rules to go with this one, and then they put all those rules in a book or a document online, and then groups all over the US can license that code from its maker. In the US we are very big about this, about licensing. We patent our larp code (and content!) and even sue gamemakers who attempt without a license to use it for their game.
Most American larpmakers it seems haven’t really considered rulemaking as fun engineering problems. At most, the types of rules I see American larpmakers get excited about are the ones dedicated to player safety and abuse prevention (important rules, but ones which lend themselves better to standardization rather than DIY rebuilding for every game). For the rules on how the diegetic reality of a given game is represented, American larpmakers all too often dip into the work of others, rather than throwing themselves into the journey of crafting rules for themselves.
Recently, as I've been interacting with Russian larpmakers and scholars of Russian larp, I've learned that Russian larpmakers approach DIY rulescraft with zeal. Or, as explained by Russian larpmaker Olga Prudkovskaya:
“To copy the rules of another larp entirely is considered bad manners. Not because of copyrights—the Russian larp community pays little attention to them anyway—but because the organizer who has copied the rules evidently does not understand the unique character of their game” (2015).
American larpmakers, admittedly, often don't understand how the rules of a larp can have a huge impact on the quality and content of the game’s diegesis, or "story world,” and also upon the general playbility of the game. Like, when you build a combat system that requires people to rapidly shout numbers between 1-200 at each other while hitting each other will all sorts of foam weapons and projectiles, melees can actually become really confusing, and also, it really reduces the aesthetics of the game when you encounter combat that looks like this. Yet, these kinds of rules choices, which are built into many pre-fab larp systems, are used in a majority of American combat larps.
Perhaps it goes without saying that in American larp, we don’t have any design paradigms intended to make sure the task of making rules stays fun for the rulemaker...
A couple years ago, I helped organize a book talk for a Russian mathematician named Edward Frenkel, and he had a lot to say about how it is easy to teach kids graduate-school-level math through play. He’s been doing it with third graders. They were picking it up, no sweat, solving problems that he usually gives to his grad students.
Mr. Frenkel thinks it's some kind of conspiracy that we only teach American kids ancient Math--and via rote nontheless!--until they get into college. "You want a populace to hate Math, that's the way to do it," he said in so many words. Our ability to understand math is our ability to understand the “markets” through which some people are rendered able to direct the labor of others, so who knows? Perhaps there is some nefarious incentive behind why math is taught so dismally in most American K-12 classrooms.
According to Mr. Frenkel, we ought to turn our whole system of teaching math in this country upside down, and have kids start with the modern maths--the maths grown-ups are actually working on and care about--and only have them touch ancient maths if they’re interested, like as an elective, or not until college. And to math teach through play, rather than punishment. Being a mathematician is about forgiving yourself for mistakes, and holding space within yourself for active unknowing (2013).
From where I stand, DRY looks a whole lot like a magic spell, specially a type of defensive spell that in larp we call a “Ward.” It this case, it looks like you’ve crafted this spell from the sort of authoritarian things used to drive most Americans away from math: "We do it this way because I said so." "Well, according to DRY this is how it's done." What a way to hide your play! But it is play that must be hidden. The ambient level of shame and anger around math is a thing. I think it would terrify most Americans to learn that coding, math, and other engineering things are in essence a form of play, a realm for creative expression. We probably shouldn’t trigger them with this knowledge. Hold safe space for their comfort.
I’m glad for DRY. It’s important to have a quick way to get some middle manager who is trying to squish your mirth for the solving of new problems to fudge off, and likewise, it isn’t about removing yourself from the problem at hand, rather defending your right (or at least it should be a right) to solve it creatively. (I likewise have built my own set of defenses in terms of getting editors to keep their mitts off of my syntax.) Yes, it’s a very good Ward spell, and I like it. Creative Coding must be defended! But man, these mryiad modes American math is made to defend itself. Unreal.
Calvinball Forever! Go Team!
In some ways, @belljo, your code re-use strategy also helps us to think about analogies between encoded objects. Sentences of asterisk drawings, sentences of Twitter, thinking about counting across posts of words and drawing on the screen.
I wonder if we could locate code reuse in this a form of material metaphor -- though analogies is probably more the term for it. Similar to the analogy, this source code and systems analogy, may bring with it, as I think your example suggests, more meaning than even its trace history of production.
(late to this discussion, apologies!) This is making me think about the tension I'm faced with in my programming classes for artists and designers (whether introductory or intermediate). On the one hand, I want them to be able to get to the point of making creative applications fast, usually meaning that I start with a working example and show them the "moving parts" that can be easily modified. This usually leads to a kind of copying calvinball in student work, where they cut-and-paste parts of different code together, often with limited success in getting it to actually work (unless they sit with me for a while in office hours). On the other hand, I want them to be able to engineer software that works reliably, which usually means starting from fundamentals—like making reliably reusable units of code—and building up to the "fun" examples, which takes longer and presents a challenge in keeping student attention and momentum. (This desire is mainly for practical and vocational reasons: some of my students expect to learn the skills they would need to be professional programmers, others may want to be able to be self-sufficient enough to be able to, e.g., fix their own gallery pieces. I always feel a sense of failure when a student makes something cool in my class but then has to hire an "actual" programmer to clean the piece up for exhibition or the app store or for more than one user at a time.)
With a subset of students and a lucky breeze, you can do both of these at once—the fun examples motivate people to learn the fundamentals. But it's difficult, and I often find that I wish as an instructor I had the latitude to take a more fundamental CS-esque approach to building reusable, well-structured, scalable software. I also find that the students I teach only start to have fun when they've learned enough of the fundamentals to understand why things are happening—anecdotally, the more copypasta the program, the more frustrated the student.
(I realize here I keep saying "fundamentals" without defining them or questioning the concept of programming fundamentals, which could be a whole thread in itself!)