This page looks best with JavaScript enabled

Give people early successes

 ·  ☕ 8 min read

I spend a lot of time teaching self-described non-programmers1 how to program.2 MediaWiki markup is a Turing-complete language (low bar, I know) with first-class support for functions (templates) and parser functions for if/else, variable definition, and (unfortunately) loops.3 Indeed, programming in MediaWiki is in many ways a lot harder than programming in a normal language, because the syntax is very convoluted: imagine writing 100% of your Python code in escaped Jinja blocks, and the only symbols supported in your interpreter are start/end of another template, start/end of variable name, and |.4

And yet, despite the absolute insanity of this programming languages, I’ve mentored many non-developers to becoming proficient with:

  • Branching logic
  • Split-map-concat behavior
  • Loops (even if I recommend against it because the implementation in MediaWiki (sans Lua) is too confusing for me)
  • Basic SQL schema design and querying
  • Data types (in SQL, MediaWiki doesn’t understand about data types)
  • Basic CSS
  • In some cases, even some basic JS and/or Python

In other words, they’ve become developers.

I see a lot of attempts online5 to create resources for “non-developers” to learn coding and I think 99% of them are super misguided. No one is needing easier explanations or clearer text. No one is needing more documentation or more examples. Instead, what people need is:

  1. Early and easy successes
  2. Room for interactive play
  3. Elimination of anything that blocks point 1 until a baseline level of confidence has been established

For the record, I think FreeCodeCamp does all of these things, and it’s one of the only external resources I recommend to people who are wanting to learn to expand their coding ability in MediaWiki.

The remainder of this article will expand on what I consider important (and not important) for people to learn to code.

Early and easy successes

A common first programming lesson is to write hello world in the language you are learning. You do this for several reasons:

  • To establish your environment functions
  • To learn a lifelong method for establishing whether your environment is functioning
  • To have an early and easy success

Note that even if you did not make your own environment, writing a hello world program still serves two valuable functions. So why add the difficulty of configuring your own environment first, just to get that small extra benefit out of your first ever lesson? You should be writing hello world in an interactive sandbox online that does not require you to do ANY local config.

Indeed, the skills required to do config/IDE installation/correctly structuring a project have almost zero intersection with the skills required to program. And for many people, the config is A LOT HARDER than writing functioning code. When they are first starting out, they might have a 10% chance to get the install correct, but a 90% chance to get print('hello world') right - and the latter comes with helpful error messages if they get it wrong.

Don’t force opaque and local instructions to be followed before letting someone feel good about themselves for learning something new and seeing the result.

Room for interactive play

Programming is all about play. You learn how the world works by trying things, and there are no rules on what you can or can’t try. Generally speaking, reading from a textbook provides less opportunity for trying “anything you want” than doing a series of guided exercises with a sandbox where you can change anything you want after each small section. (This is exactly the format of FreeCodeCamp’s lessons.)

Reduction of opportunities for human error

The #1 best way to reduce human error in a step of a process is to eliminate the need for that step altogether. For example, if a deployment requires you to copy paste 5 values from one file to another, you would absolutely not want a person doing that, and would instead want a deployment script to handle it. It’s the same principle as having access controls to prevent accidental mistakes; if an intern has write access to prod and deletes your database it’s your fault, not theirs.

This applies equally when teaching someone to code. The possibility of human error during complex file installations, or copying a lot of boilerplate code, or setting up a project directory by hand, is large. You don’t even do that yourselves when you make a new project, you use CRA or Vite or some other scaffolding.6 Again, there is NO REASON that someone needs to know about __init__.py files before learning hello world. Yes, they’ll learn that eventually. No, it’s not a prerequisite skill.

Why new developers using MediaWiki are so successful

This is not an advertisement for anything, tbh I don’t really recommend MediaWiki if your goal is to learn to code. But most people who really want to use MediaWiki are able to learn to code for a combination of the above factors:

  • MediaWiki lets you write a word on a page and then save it. (Assuming someone else is managing the installation) that’s it, you’ve made an edit and you have success! There’s nothing else you need to do. From there you can feel confident that you succeeded and even if something fails you know how to write a word and save it, and you can go back to doing that in the future. (Note, this is also an important negative control test. I can’t tell you how many times I’ve done site.client.pages['User:RheingoldRiver/test'].save('am i logged in') to make sure my login is working.)
  • Additionally, you are allowed to add new concepts in very incremental steps. If the only control flow you ever learn is #if, that’s fine! If you learn #if and #or, that’s fine! If you struggle with both of these but know how to write [[Battle of the Linguist Mages|the best book ever]] that’s also fantastic! You can learn as little or as much as you want, and either way you’re still positively contributing to a wiki!
  • It’s possible to get errors in MediaWiki if you are working with some extensions or with Scribunto, but it’s pretty rare for beginners. Mostly, if you mess up you’ll see a long wall of text. While this can make debugging difficult, it’s a great way to play - you are pretty much guaranteed to get SOMETHING to print no matter what you try. This makes for a great playground!
  • And (again assuming you are editing a managed installation) it will “just work.” You press edit, and then you press save. You don’t have to learn anything beyond that to get started.

Negative control

I still see a lot of struggles with Lua though, and I think it’s because Lua does NOT provide many of the above with MediaWiki. You can’t just write return 'hello world' somewhere and have it work. There’s some scaffolding. But the people I’ve seen do the best with learning Lua are the ones who are editing existing code from a previous admin. Even if that’s a much more complex piece of code to start with than return 'hello world', they still have an existing starting point that’s completely scaffolded, and that matters. A lot.

Conclusion

If you are teaching someone to code, don’t make them learn whatever you consider the fundamentals to be. Give them an environment. Give them the scaffolding. Give them a large, clear, inviting button that says “Run code.” Let them play one step at a time.

Set people up for success because you have confidence in them to pick up the rest later.


  1. Please note, I am using the term “non-programmer” or “non-developer” in a general sense to say that they have little to no programming experience. In my opinion, if someone understands how to use markup formatting, that makes them a developer, end of story. But a lot of people still label themselves as “non-developers” and so I will use the term here. ↩︎

  2. And keep in mind, I am talking primarily about teaching methods for people who don’t self-describe as a programmer. If you read this and say “oh but that’s not what I do” but you also consider yourself a developer, then you are not the target learning audience of this article (but maybe you are the target reading audience if you ever want to teach a self-described non-programmer to program) ↩︎

  3. Better than loops are #arraymap and #arraymaptemplate, which are split-map-concat as one single function. If you actually need loops, Lua is a much better choice. Writing out nested #if statements up to 30 possible parameters is also an acceptable strategy if that’s what you’re comfortable with. I would generally prefer that over using the loops extension honestly, because it’ll be easier for future maintainers to use even if some people might roll their eyes a bit. ↩︎

  4. This is not an exaggeration. There are basically 5 reserved strings in MediaWiki: {{ and }} for start/end of template (function); {{{ and }}} for start/end of template (function) parameter; and | for a separator between plaintext. In certain scopes, plaintext can be looked up as a function name either on the wiki (as a template) or in PHP (as either a built-in or an extension). Then the plaintext args (yes, there are no data types) can be used in that context. ↩︎

  5. In other words, this article exists because I think HN is wrong ↩︎

  6. This is a bit tongue-in-cheek, but also not ↩︎

Share on

river
WRITTEN BY
River
River is a developer most at home in MediaWiki and known for building Leaguepedia. She likes cats.

What's on this Page