Earlier this year my eldest daughter asked what might be involved in becoming a "Happiness Engineer" at Automattic (the creators of WordPress). I did a little reading and decided the best way forward would be to make sure she had a thorough grounding in web development, and a good working knowledge of WordPress before even thinking about approaching Automattic.

Where to start ?

I should perhaps explain before going any further that I have been a software and web developer for the better part of twenty five years now, so the question wasn't so much "could I help?" - it was more a case of "where best to start?"

Learning WordPress is straightforward - there are wonderful guides and tutorials throughout the internet walking through content creation, theme design, search engine optimisation, and so on. Web development is another story, however - it's a fast-moving, evolving, and expanding morass of skills, knowledge, and experience - and you can't always trust the materials you find online.

I braced myself for the inevitable request for my help.

And then lockdown happened...

Rather fortuitously, this all coincided with the first lock-down of 2020 - while I sat at the dining room table with my work laptop, bullet journal, and a huge cup of coffee, my daughter set up station next to me. I held my hands up and explained that while I'm no teacher, I have taught people in the past - before the world changed, I would regularly get roped into teaching masterclasses on various technology platforms for business users. I guess the huge difference between a business user and a teenager is the business user usually needs to learn the thing you're showing them.

My daughter surprised me - both in terms of her enthusiasm, and tenacity. I suppose knowing her well gifted me the knowledge of how to teach her - a discovery skill teachers have in abundence, and that I would have been sorely lacking.

What follows is a list of the subjects we covered over the following days and weeks. Some of it was planned - some of it not. It's amazing how many rabbit holes you fall down while explaining how something works, or why you might do something a certain way.


The foundation of all web pages. We started in a simple text editor and wrote HTML by hand - rather than look at any legacy dialects, we went straight for HTML 5, learning the basics of pages with headings, paragraphs, lists, tables, and so on. I debated with myself about teaching her what "block-level elements" were at this point, and decided to do so in the end, purely to illustrate some of the problems tables cause.

Integrated Development Environments

After writing the first pages in a text editor, we switched over to Visual Studio Code, and looked at some of the toys an integrated development environment brings to the party - such as syntax highlighting, projects, and extensions to preview HTML while editing it. We both agreed that code completion is both a blessing and a curse.

The File System

By this stage, we had several files and had already begun playing with hyperlinks and images. I tend to think a basic knowledge of the filesystem is essential, in order to explain how you might organise files, and how to reference them from within a portable structure. We looked at building folder structures, saving files within folders, moving files with folders, and perhaps the most important result of doing so - absolute and relative paths. Being able to see the project folder structure in Visual Studio Code while writing relative paths in HTML helped enormously.

Web Browsers

While previewing the HTML we worked on, we looked at different browsers - primarily Google Chrome and Firefox - to see how each browser differed in terms of the debugging experience. I always find it quite entertaining when people realise how much is going on inside a web-browser - that it's almost an operating system in its own right. This was all really about getting used to the "View Source", and "Inspect Element" features before getting involved in either CSS or JavaScript later on.

File Transfer

By chance I have a Raspberry Pi sitting on the network at home, so installed a web server on it - as a precursor to explaining file transfer. We looked at common file transfer protocols, and the popular applications for each - primarily focusing on FileZilla because it's the most obvious application to teach and use. We transferred files from a local working directory, up to the server, and downloaded them back down again.

Remote Access

Again using the Raspberry Pi, we used SSH to connect to and navigate around the files on the webserver via the command prompt in a terminal. My daughter has Elementary OS installed on her laptop (an Ubuntu Linux derivative), so this pretty straightforward. I also showed her how you might use PuTTY on a Windows machine to do the same thing. Just for laughs at one point, I fired up a 20-year-old iMac that usually lives under the desk, and we connected from her laptop to the Raspberry Pi, and then to the Macbook - explaining the tunnel we were creating as we went.


Returning to our HTML files, we started writing CSS - first directly in the HTML files, and then as separate files, in separate folders, referenced by the HTML. After preparing everything and uploading to the webserver, everything started to fall into place - an inter-connected group of files being fetched from the web server by the browser and interpreted into page designs on the screen. We looked at the basics of the "Document Object Model", how to affect common styles, and began looking at techniques to achieve a "responsive" result within the browser.


We didn't cover a lot of ground with JavaScript, because it's almost a bigger subject than HTML, CSS and web servers, but we did look at simple scripting to affect the Document Object Model on the fly - and to react to interaction throughout a page. Again, we worked initially within script tags before moving the script to discrete files, stored in folders, and referenced by the HTML files. I chose to stick to ES6, even though we hardly touched any of its features. This was all about explaining that the browser can execute code on the fly to manipulate the behaviour and appearance of a page. We kept well away from frameworks - I'm something of a believer that people should learn basic JavaScript before throwing a framework the size of an Elephant on top of it to borrow three or four functions.


Having struggled somewhat through the introduction to JavaScript, the mood brightened enormously while playing with graphics files - explaining the various formats and their attributes in terms of design and performance. We looked primarily at GIMP, and how you can reduce the size of a digital photo, crop it, and export to formats preferred by web browsers.

Web Servers and Scripting Languages

This was more a demonstration on my part than a tutorial. I showed my daughter how a text file renamed with the "PHP" file extension could be interpreted by the server, and output programmed HTML back to the browser. This was a lightbulb moment about how the majority of the internet works - that there is a balancing act between processing on the server through languages like PHP and processing within the browser through JavaScript and DHTML.

Content Management Systems

Finally, we arrived at WordPress. I demonstrated installing WordPress on the Raspberry Pi, before hand-holding her through the new user path at wordpress.com - explaining the concept of software as a service along the way. Did we really want to run a web server when we could have as much freedom as we needed in a managed service run by somebody else (and somebody else that would know more about the service that we ever might)?

Version Control

Finally, we took a very brief look at source control - in the shape of Git. We spun up a new repository, and then added and committed the files we had played with so far. To prove the point we deleted some files "by accident", and then pulled them back into existence. Again - version control is a huge subject, but it served to round off the journey - of creating files, deploying files, and storing backups of those files.

So it’s pretty straightforward then ?

Not really. Learning takes time, and when it comes to web development, you never really stop learning, because the world around you continues to evolve.

You need to get stuck.

The lessons outlined above took place over several weeks. I take a pretty dim view of books and online courses that claim expertise in 24 hours, or even 7 days. You need time to experiment, play, build, tear down, destroy and re-build while learning. You need to get stuck. I tend to learn the most about things while stuck.


Hopefully, you found this interesting — if so, you now have a rough lesson plan to take a newcomer from knowing very little to being able to build sites, and at least understand a little of the wider subjects of web development, web design, and the skills involved along the way.