Journal tags: codebar

Looking back on ten years of codebar Brighton, I’m remembering how much I got out of being a coach.

Something that I realised very quickly is that there is no one-size-fits-all approach to coaching. Every student is different so every session should adapt to that.

Broadly speaking I saw two kinds of students: those that wanted to get results on screen as soon as possible without worrying about the specifics, and those who wanted to know why something was happening and how it worked. In the first instance, you get to a result as quickly as possible and then try to work backwards to figure out what’s going on. In the second instance, you build up the groundwork of knowledge and then apply it to get results.

Both are equally valid approaches. The only “wrong” approach as a coach is to try to apply one method to someone who’d rather learn the other way.

Personally, I always enjoyed the groundwork-laying of the second approach. But it comes with challenges. Because the results aren’t yet visible, you have to do extra work to convey why the theory matters. As a coach, you need to express infectious enthusiasm.

Think about the best teachers you had in school. I’m betting they displayed infectious enthusiasm for the subject matter.

The other evergreen piece of advice is to show, don’t tell. Or at the very least, intersperse your telling with plenty of showing.

Bret Viktor demonstrates this when he demonstrates scientific communication as sequential art:

This page presents a scientific paper that has been redesigned as a sequence of illustrations with captions. This comic-like format, with tightly-coupled pictures and prose, allows the author to depict and describe simultaneously — show and tell.

It works remarkably well. I remember how well it worked when Google first launched their Chrome web browser. They released a 40 page comic book illustrated by Scott McCloud. There is no way I would’ve read a document that long about how browser engines work, but I read that comic cover to cover.

This visual introduction to machine learning is another great example of simultaneous showing and telling.

So showing augments telling. But interactivity can augment showing.

Here are some great examples of interactive explainers:

• Cameras and Lenses by Bartosz Ciechanowski,
• An Interactive Guide to CSS Grid by Josh W Comeau,
• CSS :has() Interactive Guide by Ahmad Shadeed,
• Pizza Exchange Rate by Nathan Yau, and
• just about everything by Nicky Case.

Lea describes what can happen when too much theory comes before practice:

Observing my daughter’s second ever piano lesson today made me realize how this principle extends to education and most other kinds of knowledge transfer (writing, presentations, etc.). Her (generally wonderful) teacher spent 40 minutes teaching her notation, longer and shorter notes, practicing drawing clefs, etc. Despite his playful demeanor and her general interest in the subject, she was clearly distracted by the end of it.

It’s easy to dismiss this as a 5 year old’s short attention span, but I could tell what was going on: she did not understand why these were useful, nor how they connect to her end goal, which is to play music.

The codebar website has some excellent advice for coaches, like:

• Do not take over the keyboard! This can be off-putting and scary.
• Encourage the students to type and not copy paste.
• Explain that there are no bad questions.
• Explain to students that it’s OK to make mistakes.
• Assume that anyone you’re teaching has no knowledge but infinite intelligence.

Notice how so much of the advice focuses on getting the students to do things, rather than have them passively sit and absorb what the coach has to say.

Lea also gives some great advice:

1. Always explain why something is useful. Yes, even when it’s obvious to you.
2. Minimize the amount of knowledge you convey before the next opportunity to practice it. For non-interactive forms of knowledge transfer (e.g. a book), this may mean showing an example, whereas for interactive ones it could mean giving the student a small exercise or task.
3. Prefer explaining in context rather than explaining upfront.

It’s interesting that Lea highlights the advantage of interactive media like websites over inert media like books. The canonical fictional example of an interactive explainer is the Young Lady’s Illustrated Primer in Neal Stephenson’s novel The Diamond Age. Andy Matuschak describes its appeal:

When it wants to introduce a conceptual topic, it begins with concrete hands-on projects: Turing machines, microeconomics, and mitosis are presented through binary-coding iron chains, the cipher’s market, and Nell’s carrot garden. Then the Primer introduces extra explanation just-in-time, as necessary.

That’s not how learning usually works in these domains. Abstract topics often demand that we start with some necessary theoretical background; only then can we deeply engage with examples and applications. With the Primer, though, Nell consistently begins each concept by exploring concrete instances with real meaning to her. Then, once she’s built a personal connection and some intuition, she moves into abstraction, developing a fuller theoretical grasp through the Primer’s embedded books.

(Andy goes on to warn of the dangers of copying the Primer too closely. Its tricks verge on gamification, and its ultimate purpose isn’t purely to educate. There’s a cautionary tale there about the power dynamics in any teacher/student relationship.)

There’s kind of a priority of constituencies when it comes to teaching:

Consider interactivity over showing over telling.

Thinking back on all the talks I’ve given, I start to wonder if I’ve been doing too much telling and showing, but not nearly enough interacting.

Then again, I think that talks aren’t quite the same as hands-on workshops. I think of giving a talk as being more like a documentarian. You need to craft a compelling narrative, and illustrate what you’re saying as much as possible, but it’s not necessarily the right arena for interactivity.

That’s partly a matter of scale. It’s hard to be interactive with every person in a large audience. Marcin managed to do it but that’s very much the exception.

Workshops are a different matter though. When I’m recruiting hosts for UX London workshops I always encourage them to be as hands-on as possible. A workshop should not be an extended talk. There should be more exercises than talking. And wherever possible those exercises should be tactile, ideally not sitting in front of a computer.

My own approach to workshops has changed over the years. I used to prepare a book’s worth of material to have on hand, either as one giant slide deck or multiple decks. But I began to realise that the best workshops are the ones where the attendees guide the flow, not me.

So now I show up to a full-day workshop with no slides. But I’m not unprepared. I’ve got decades of experience (and links) to apply during the course of the day. It’s just that instead of trying to anticipate which bits of knowledge I’m going to need to convey, I apply them in a just-in-time manner as and when they’re needed. It’s kind of scary, but as long as there’s a whiteboard to hand, or some other way to illustrate what I’m telling, it works out great.

I went to codebar Brighton yesterday evening. I hadn’t been in quite a while, but this was a special occasion: a celebration of codebar Brighton’s tenth anniversary!

The Brighton chapter of codebar was the second one ever, founded six months after the initial London chapter. There are now 33 chapters all around the world.

Clearleft played host to that first ever codebar in Brighton. We had already been hosting local meetups like Async in our downstairs event space, so we were up for it when Rosa, Dot, and Ryan asked about having codebar happen there.

In fact, the first three Brighton codebars were all at 68 Middle Street. Then other places agreed to play host and it moved to a rota system, with the Clearleft HQ as just one of the many Brighton venues.

With ten years of perspective, it’s quite amazing to see how many people went from learning to code in the evenings, to getting jobs in web development, and becoming codebar coaches themselves. It’s a really wonderful community.

Over the years the baton of organising codebar has been passed on to a succession of fantastic people. These people are my heroes.

It worked out well for Clearleft too. Thanks to codebar, we hired Charlotte. Later we hired Cassie. And it was thanks to codebar that I first met Amber.

Codebar Brighton has been very, very good to me. Here’s to the next ten years!

It’s been a few weeks now since Patterns Day and I’m still buzzing from it. I might be biased, but I think it was a great success all ‘round—for attendees, for speakers, and for us at Clearleft organising the event.

I first had the idea for Patterns Day quite a while back. To turn the idea into reality meant running some numbers. Patterns Day wouldn’t have been possible without Alis. She did all the logistical work—the hard stuff—which freed me up to concentrate on the line-up. I started to think about who I could invite to speak, and at the same time, started looking for a venue.

I knew from the start that I wanted it to be one-day single-track conference in Brighton, much like Responsive Day Out. I knew I wouldn’t be able to use the Corn Exchange again—there’s extensive rebuilding going on there this year. I put together a shortlist of Brighton venues and Alis investigated their capacities and costs, but to be honest, I knew that I wanted to have it in the Duke Of York’s. I love that place, and I knew from attending FFconf that it makes for an excellent conference venue.

The seating capacity of the Duke Of York’s is quite a bit less than the Corn Exchange, so I knew the ticket price would have to be higher than that of Responsive Day Out. The Duke Of York’s isn’t cheap to rent for the day either (but worth every penny).

To calculate the ticket price, I had to figure out the overall costs:

• Venue hire,
• A/V hire,
• Printing costs (for name badges, or in this case, stickers),
• Payment provider commission—we use Stripe through the excellent Ti.to,
• Speaker’s travel,
• Speaker’s accommodation,
• Speaker’s dinner the evening before the event,
• Speaker’s payment.

Some conference organisers think they can skimp on that last part. Those conference organisers are wrong. A conference is nothing without its speakers. They are literally the reason why people buy tickets.

Because the speakers make or break a conference, there’s a real temptation to play it safe and only book people who are veterans. But then you’re missing out on a chance to boost someone when they’re just starting out with public speaking. I remember taking a chance on Alla a few years back for Responsive Day Out 3—she had never given a conference talk before. She, of course, gave a superb talk. Now she’s speaking at events all over the world, and I have to admit, it gives me a warm glow inside. When it came time for Patterns Day, Alla had migrated into the “safe bet” category—I knew she’d deliver the perfect closing keynote.

I understand why conference organisers feel like they need to play it safe. From their perspective, they’re already taking on a lot of risk in putting on a conference in the first place. It’s easy to think of yourself as being in a position of vulnerability—”If I don’t sell enough tickets, I’m screwed!” But I think it’s important to realise that you’re also in a position of power, whether you like it or not. If you’re in charge of putting together the line-up of a conference, that’s a big responsibility, not just to the attendees on the day, but to the community as a whole. It’s like that quote by Eliel Saarinen:

Always design a thing by considering it in its next larger context. A chair in a room, a room in a house, a house in an environment, an environment in a city plan.

Part of that responsibility to the wider community is representation. That’s why I fundamentally disagree with ppk when he says:

The other view would be that there should be 50% woman speakers. Although that sounds great I personally never believed in this argument. It’s based on the general population instead of the population of web developers, and if we’d extend that argument to its logical conclusion then 99.9% of the web development conference speakers should know nothing about web development, since that’s the rough ratio in the general population.

That makes it sound like a conference’s job is to represent the status quo. By that logic, the line-up should include plenty of bad speakers—after all, the majority of web developers aren’t necessarily good speakers. But of course that’s not how conferences work. They don’t represent typical ideas—quite the opposite. What’s the point of having an event that simply reinforces the general consensus? This isn’t Harrison Bergeron. You want a line-up that’s exceptional.

I don’t think conference organisers can shirk this issue and say “It’s out of my hands; I’m just reflecting the way things are.” The whole point of having a conference in the first place is to trigger some kind of change. If you’re not happy with the current make-up of the web community (and I most definitely am not), then a conference is the perfect opportunity to try to demonstrate an alternative. We do it with the subject matter of the talks—”Our code/process/tooling doesn’t have to be this way!”—and I think we should also apply that to the wider context: “Our culture doesn’t have to be this way!”

Passing up that chance isn’t just a missed opportunity, I think it’s also an abdication of responsibility. Believe me, I know that organising a conference is a lot of work, but that’s not a reason to cop out. On the contrary, it’s all the more reason to step up to the plate and try your damnedest to make a difference. Otherwise, why even have a conference?

Whenever the issue of diversity at conferences comes up, there is inevitably someone who says “All I care about is having the best speakers.” But if that were true, shouldn’t your conference (and every other conference) have exactly the same line-up every year?

The truth is that there are all sorts of factors that play into the choice of speakers. I think representation should be a factor, but that’s all it is—one factor of many. Is the subject matter relevant? That’s a factor. Do we already have someone on the line-up covering similar subject matter? That’s a factor. How much will it cost to get this speaker? That’s a factor. Is the speaker travelling from very far away? That’s a factor.

In the case of Patterns Day, I had to factor in the range of topics. I wanted a mixture of big-picture talks as well as hands-on nitty-gritty case studies. I also didn’t want it to be too developer-focused or too design-focused. I was aiming for a good mix of both.

In the end, I must admit that I am guilty of doing exactly what I’ve been railing against. I played it safe. I put together a line-up of speakers that I wanted to see, and that I knew with absolute certainty would deliver great presentations. There were plenty of potential issues for me to get stressed about in the run-up to the event, but the quality of the talks wasn’t one of them. On the one hand, I wish I had taken more chances with the line-up, but honestly, if I could do it over again, I wouldn’t change a thing.

Because I was trying to keep the ticket price as low as possible—and the venue hire was already a significant cost—I set myself the constraint of only having speakers from within the UK (Jina was the exception—she was going to come anyway as an attendee, so of course I asked her to speak). Knowing that the speaker’s travel costs would be low, I could plug the numbers into an algebraic formula for figuring out the ticket price:

costs ÷ seats = price

Add up all the costs and divide that total by the number of available seats to get the minimum ticket price.

In practice, you probably don’t want to have to sell absolutely every single ticket just to break even, so you set the price for a sales figure lower than 100%—maybe 80%, or 50% if you’re out to make a tidy profit (although if you’re out to make a tidy profit, I don’t think conferences are the right business to be in—ask any conference organiser).

Some conferences factor in money for sponsorship to make the event happen. I prefer to have sponsors literally sponsoring additions to the conference. In the case of Patterns Day, the coffee and pastries were sponsored by Deliveroo, and the videos were sponsored by Amazon. But sponsorship didn’t affect the pricing formula.

The Duke Of York’s has around 280 seats. I factored in about 30 seats for speakers, Clearlefties, and other staff. That left 250 seats available for attendees. But that’s not the number I plugged into the pricing formula. Instead, I chose to put 210 tickets on sale and figured out the ticket price accordingly.

What happened to the remaining 40 seats? The majority of them went to Codebar students and organisers. So if you bought a ticket for Patterns Day, you directly subsidised the opportunity for people under-represented in technology to attend. Thank you.

Speaking personally, I found that having the Codebar crew in attendance really made my day. They’re my heroes, and it meant the world to me that they were able to be there.

I really enjoyed teaching in Porto last week. It was like having a week-long series of CodeBar sessions.

Whenever I’m teaching at CodeBar, I like to be paired up with people who are just starting out. There’s something about explaining the web and HTML from first principles that I really like. And people often have lots and lots of questions that I enjoy answering (if I can). At CodeBar—and at The New Digital School—I found myself saying “Great question!” multiple times. The really great questions are the ones that I respond to with “I don’t know …let’s find out!”

CodeBar is always a very rewarding experience for me. It has given me the opportunity to try teaching. And having tried it, I can now safely say that I like it. It’s also a great chance to meet people from all walks of life. It gets me out of my bubble.

I can’t remember when I was first paired up with Amber at CodeBar. It must have been sometime last year. I do remember that she had lots of great questions—at some point I found myself explaining how hexadecimal colours work.

I was impressed with Amber’s eagerness to learn. I also liked that she was making her own website. I told her about Homebrew Website Club and she started coming along to that (along with other CodeBar people like Cassie and Alice).

I’ve mentioned to multiple CodeBar students that there’s pretty much an open-door policy at Clearleft when it comes to shadowing: feel free to come along and sit with a front-end developer while they’re working on client projects. A few people have taken up the offer and enjoyed observing myself or Charlotte at work. Amber was one of those people. Again, I was very impressed with her drive. She’s got a full-time job (with sometimes-crazy hours) but she’s so determined to get into the world of web design and development that she’s willing to spend her free time visiting Clearleft to soak up the atmosphere of a design studio.

We’ve decided to turn this into something more structured. Amber and I will get together for a couple of hours once a week. She’s given me a list of some of the areas she wants to explore, and I think it’s a fine-looking list:

• I want to gather base, structural knowledge about the web and all related aspects. Things seem to float around in a big cloud at the moment.
• I want to adhere to best practices.
• I want to learn more about what direction I want to go in, find a niche.
• I’d love to opportunity to chat with the brilliant people who work at Clearleft and gain a broad range of knowledge from them.

My plan right now is to take a two-track approach: one track about the theory, and another track about the practicalities. The practicalities will be HTML, CSS, JavaScript, and related technologies. The theory will be about understanding the history of the web and its strengths and weaknesses as a medium. And I want to make sure there’s plenty of UX, research, information architecture and content strategy covered too.

Seeing as we’ll only have a couple of hours every week, this won’t be quite like the masterclass I just finished up in Porto. Instead I imagine I’ll be laying some groundwork and then pointing to topics to research. I guess it’s a kind of homework. For example, after we talked today, I set Amber this little bit of research for the next time we meet: “What is the difference between the internet and the World Wide Web?”

I’m excited to see where this will lead. I find Amber’s drive and enthusiasm very inspiring. I also feel a certain weight of responsibility—I don’t want to enter into this lightly.

I’m not really sure what to call this though. Is it mentorship? Or is it coaching? Or training? All of the above?

Whatever it is, I’m looking forward to documenting the journey. Amber will be writing about it too. She is already demonstrating a way with words.

I had a really enjoyable time at Codebar Brighton last week, not least because Morty came along.

I particularly enjoy teaching people who have zero previous experience of making a web page. There’s something about explaining HTML and CSS from first principles that appeals to me. I especially love it when people ask lots of questions. “What does this element do?”, “Why do some elements have closing tags and others don’t?”, “Why is it textarea and not input type="textarea"?” The answer usually involves me going down a rabbit-hole of web archeology, so I’m in my happy place.

But there’s only so much time at Codebar each week, so it’s nice to be able to point people to other resources that they can peruse at their leisure. It turns out that’s it’s actually kind of tricky to find resources at that level. There are lots of great articles and tutorials out there for professional web developers—Smashing Magazine, A List Apart, CSS Tricks, etc.—but no so much for complete beginners.

Here are some of the resources I’ve found:

• MarkSheet by Jeremy Thomas is a free HTML and CSS tutorial. It starts with an explanation of the internet, then the World Wide Web, and then web browsers, before diving into HTML syntax. Jeremy is the same guy who recently made CSS Reference.
• Learn to Code HTML & CSS by Shay Howe is another free online book. You can buy a paper copy too. It’s filled with good, clear explanations.
• Zero to Hero Coding by Vera Deák is an ongoing series. She’s starting out on her career as a front-end developer, so her perspective is particularly valuable.

If I find any more handy resources, I’ll link to them and tag them with “learning”.

Last week, I had two really enjoyable experiences discussing completely opposite ends of the web technology stack.

Tuesday is Codebar day here in Brighton. Clearleft hosted it at 68 Middle Street last week. I really, really enjoy coaching at Codebar. I particularly like teaching the absolute basics of HTML and CSS. There’s something so rewarding about seeing the “a-ha!” moments when concepts click with people. I also love answering the inevitable questions that arise, like “why is it like that?”, or “how do I do this?”

Thursday was devoted to the opposite end of the spectrum. I ran a workshop at Clearleft with some developers from one of our clients. The whole day was dedicated to exploring and evaluating up-and-coming web technologies. Basically, it was a chance to geek out about all the stuff I’ve been linking to or writing about. During the workshop I ended up making a lot of use of my tagging system here on adactio.com:

• My thoughts on web components,
• Links to resources on web components,
• My posts on implementing service workers,
• Lots and lots of links to handy service worker resources,
• Links relating to performance,
• A whole bunch of accessibility links, and
• Everything I’ve linked to regarding progressive web apps.

Web components and service workers ended up at the top of the list of technologies to tackle, which was fortuitous, given my recent thoughts on comparing the two:

First of all, ask the question “who benefits from this technology?” In the case of service workers, it’s the end users. They get faster websites that handle network failure better. In the case of web components, there are no direct end-user benefits. Web components exist to make developers lives easier. That’s absolutely fine, but any developer convenience gained by the use of web components can’t come at the expense of the user—that price is too high.

The next question we usually ask when we’re evaluating a technology is “how well does it work?” Personally, I think it’s just as important to ask “how well does it fail?”

Those two questions turned out to be a good framework for the whole workshop. The question of how to evaluate technologies is something I’ve been thinking about a lot lately. I’m pretty sure it will be what my next conference talk is going to be all about.

You can read more about the structure of the workshop over on the Clearleft site. I’m looking forward to running it again sometime. But I’m equally looking forward to getting back to the basics at the next Codebar.

Today is October 13th. It is Ada Lovelace Day:

Ada Lovelace Day is an international celebration of the achievements of women in science, technology, engineering and maths (STEM).

Today is also a Tuesday. That means that Codebar is happening this evening in Brighton:

Codebar is a non-profit initiative that facilitates the growth of a diverse tech community by running regular programming workshops.

The Brighton branch of Codebar is run by Rosa, Dot, and Ryan.

Rosa and Dot are Ruby programmers. They’ve poured an incredible amount of energy into making the Brighton chapter of Codebar such a successful project. They’ve built up a wonderful, welcoming event where everyone is welcome. Whenever I’ve participated as a coach, I’ve always found it be an immensely rewarding experience. For that, and for everything else they’ve accomplished, I thank them.

Brighton is lucky to have them.

I know I say this every year, but this month—and this week in particular—is a truly wonderful time to be in Brighton. I am, of course, talking about The Brighton Digital Festival.

It’s already underway. Reasons To Be Creative just wrapped up. I managed to make it over to a few talks—Stacey Mulcahey, Jon, Evan Roth. The activities for the Codebar Code and Chips scavenger hunt are also underway. Tuesday evening’s event was a lot of fun; at the end of the night, everyone wanted to keep on coding.

I popped along to the opening of Georgina’s Familiars exhibition. It’s really good. There’s an accompanying event on Saturday evening called Unfamiliar Matter which looks like it’ll be great. That’s the same night as the Miniclick party though.

I guess clashing events are unavoidable. Like tonight. As well as the Guardians Of The Galaxy screening hosted by Chris (that I’ll be going to), there’s an Async special dedicated to building a 3D Lunar Lander.

But of course the big event is dConstruct tomorrow. I’m really excited about it. Partly that’s because I’m not the one organising it—it’s all down to Andy and Kate—but also because the theme and the line-up is right up my alley.

Andy has asked me to compere the event. I feel a little weird about that seeing as it’s his baby, but I’m also honoured. And, you know, after talking to most of the speakers for the podcast—which I enjoyed immensely—I feel like I can give an informed introduction for each talk.

I’m looking forward to this near future event.

See you there.

There are many web-related community events in Brighton. There’s something going on pretty much every evening. One of my favourite events is Codebar. It happens every Tuesday, rotating venues between various agency offices. Tonight it was Clearleft’s turn again.

At the start of the evening, students and teachers get paired up. I was helping some people with HTML and CSS as they worked their way through the tutorials.

It’s a great feeling to watch things “click”; seeing someone making their first web page, style their first element, and write their first hyperlink—the very essence of the World Wide Web.

It was Clearleft’s turn to host Codebar again this evening. As always, it was great. I did my best to introduce some people to HTML and CSS, which was challenging, rewarding, and fun.

In the run-up to the event, I did a little spring cleaning of Clearleft’s bookshelves. I took some books on HTML, CSS, and JavaScript that weren’t being used any more and offered them to Codebar students for the taking.

I was also able to offer some more contemporary books thanks to the generosity of A Book Apart who kindly donated some of their fine volumes to Codebar.

There’s been a whole series of events going on in Brighton this month under the banner of Spring Forward:

Spring Forward is a month-long celebration of the role of women in digital culture and runs throughout March in parallel with Women’s History Month.

Luckily for me, a lot of the events have been happening at 68 Middle Street—home of Clearleft—so I’ve been taking full advantage of as many as I can (also, if I go to an event that means that Tessa doesn’t have to stick around every night of the week to lock up afterwards). Charlotte has been going to even more.

I managed to get to Tech In Ten—run by She Codes Brighton—which was great, but I missed out on Pixels and Prosecco by Press Fire To Win which sounded like it was a lot of fun. And there are more events still to come, like She Says and Ladies That UX.

What’s great about Spring Forward events like She Codes, 300 Seconds, She Says, and Ladies That UX is that they aren’t one-offs; they’re happening all-year round, along with other great regular Brighton events like Async and UX Brighton.

And then there’s Codebar. I had heard about Codebar before, but Spring Forward was the first chance I had to get stuck in—it was being hosted at 68 Middle Street, so I said I’d stick around to lock up afterwards. I’m so glad I did. It was great!

In a nutshell, Codebar offers a chance for people who are under-represented in the world of programming and technology to get some free training by pairing them with tutors who volunteer their time. I offered to help out anyone who was learning HTML and CSS (after tamping down the inevitable inner voice of imposter syndrome that was asking “who are you to be teaching anyone anything?”).

I really, really enjoyed it. It was so nice to meet people from outside the world of web design and development. It was also a terrific reminder that the act of making websites is something that everybody should be able to participate in. This is for everyone.

Codebar Brighton takes place once a week, changing up the venue on rotation. As you can imagine, it takes a lot of work to maintain that momentum. It’s thanks to the tireless efforts of the seemingl indefatigable Ruby programmers Rosa and Dot that it’s such a great success. I am in their debt.