At Twitter’s office in London we’ve been running courses for CodeFirstGirls, which brings together women to learn how to code. We also recently brought in teenagers from three different faith schools, via Faiths-Forum-for-London, with an aim of building their first websites.
Through helping to teach these courses I’ve observed the successes and difficulties that students are having, and I’d like to share some of these observations below. These are mostly limited to the teaching of the web platform — that is: HTML, CSS and JavaScript, which are the core pieces that we cover when someone has no prior coding experience.
Teaching HTML, CSS and JavaScript, in that order, makes a tonne of sense. Ordering a curriculum according to layers of abstraction is a very obvious idea, but it’s worth stating it outright as such. It’s easy to forget the necessity of foundational knowledge, and the usefulness of not only understanding how a new thing works, but where it is situated in the universe of related paradigms. Knowing CSS and HTML isn’t the same as knowing how to piece them together in useful ways.
Libraries and frameworks are double edged swords when learning. Bootstrap and jQuery have been really useful to us in getting quick prototypes working, and making the web platform more palatable to beginners, but the band-aid has to be ripped off at some point, because after a while the abstractions start to break down. Learning via first principles, instead, would perhaps make people more resistant to the pain of these leaky abstractions and the ideologies and illusions created by them.
Relatedly, it’s impossible to teach the right thing. In this ever-changing world of web things it’s very hard to know what paradigm(s) to teach. For example, the once sacred virtue of ‘Separation of Concerns’ for HTML/CSS/JS is becoming less relevant as we find more interesting and optimal ways to create DOM and style it (See React). The blasphemy of inline styles, and inline UI logic, is fast becoming defunct. The ebbs and flows of our trends and paradigms are hard to predict. All we can do is teach what is current, with a bias towards foundational knowledge. (I.e. don’t start off by teaching React or Angular…)
Syntax is not intuitively delineated. As you pick up new programming languages, mentally parsing different types of syntax becomes second nature (an awesome feat of the human mind). Your brain can build a hierarchical model of the instructions you’re seeing. The CSS value is part of the CSS rule which is part of the CSS ruleset (etc). But I’ve found that these models aren’t always intuitive. It’s not obvious from the get-go that an HTML element should be closed with a </blah> instead of a <blah/> or a /<blah>. And just because it’s easy to look at a piece of syntax and understand its meaning doesn’t mean its easy to intuitively come up with the correct syntax when you know what you want to do (“I want to close this HTML element — how do I do that again? Something related to a forward-slash I think…”). Just think about all the different types of symbols we use… is it always absolutely obvious which of them function as delimiters, versus operators, versus arbitrary values? It’s absolutely ~!:@${/?[{]};:~ not.
Ordering of instructions is not an obvious concern. The idea that you have to write your HTML or CSS or JavaScript in a specific order is not obvious to someone who hasn’t coded before. It has to be specifically explained. Markup and other declarative languages especially often conflate complex concepts with ordering (it’s not just a case of procedural execution). In CSS we worry about the cascade and specificity. In HTML we worry about semantics and how elements will be visually ordered. There’s a lot of complexity in deciding what goes before or after something else.
The web platform makes it easy to win AND fail. You can build amazing things very quickly with these basic tools, but HTML and CSS don’t tell you when you fail. They silently try to do their best, and are very flexible when it comes to some syntactic variations, but strict when it comes to others. Usually no errors will be thrown in the console either. So when your page isn’t displaying correctly you have to pour over every piece of the code to discover what might be causing the problem. A simple “CSS: Unexpected colon on line 17” would be a huge help to those learning. This to me seems like a reason to work harder on educational platforms for the web, with linters and other aids built in, perhaps. Right now the state of the Web Inspector as a learning aid is not too wonderful. It’s a powerful tool, but also a necessarily complex tool tailored to professionals.
Thanks for reading! Please share your thoughts with me on Twitter. Have a great day!