DEV Community: Digital Theatre+

We didn't start the fire(break)

Georgia — Thu, 16 Sep 2021 15:33:31 +0000

The team at Digital Theatre+ have just completed our first firebreak, and so it felt like a good time to scribble down a few reflections, discuss how successful it was for our team and whether it's something we'll be repeating in the future.

So, what's a firebreak?

A firebreak is an opportunity for a development team to take some time out of business as usual and flex their creative coding muscles. By the time we took our firebreak, the tech team at Digital Theatre+, had been working on the rebuild of our product for the past year and a bit, so for us a firebreak was a chance to take some wacky, outlandish product ideas that had been floating around in our heads and actually throw some time and resources into bringing them to life. Firebreak was an opportunity, to get creative, be innovative and have some fun without worrying about the pressures of delivering features and addressing bugs or tech debt.

You may or may not know that the title of this article is inspired by a song (We Didn't Start The Fire) in which singer Billy Joel provides his listeners with everything they need to know about history and popular culture from the twentieth century (I owe that A* in History GCSE to you, Bill). But, as the title also suggests, the idea of a firebreak didn't start with us. It's something teams have been practicing for many years, in many different forms. During my time at Founders & Coders our weekly project sprints were structured really similarly to how our team at Digital Theatre+ organised this firebreak.

If you want a more eloquent, descriptive summary of what a firebreak is, visit this link for an article ghost written by DT+ dev James Calmus.

What was the structure like?

It's well accepted that without a set of clear rules, fun just gets out of control. So, we started the week by outlining two key guidelines for our firebreak. First, whatever the team decides to work on must be linked to the general scope and vision of the Digital Theatre+ product. Secondly, all work must be completed within the allotted firebreak time - no crazy late evenings or weekend work allowed!

We decided to give ourselves a week for the firebreak, beginning on a Monday morning with idea generation at our usual stand up time. James, our dev facilitator, had prepared a Miro board where we could throw ideas onto a shared screen. Once we'd gathered enough project suggestions, we talked through them briefly and went on to vote on our top three. Votes collated, we had a really informal chat in between the four of us developers about what we'd each like to work on, and what style of work we'd like to do - mobbing, pairing or working solo.

We settled on working in two separate pairs. One pair worked on a synchronised video experience that allows users to play, pause and scrub videos in unison, which would be complimented by a chat room where users could discuss the videos they watch. The other (and my pair) decided to build a 'rich guide'. This was an opportunity to take the PDFs we have on our website and turn their content into rich text, which we could pop into HTML on a web page - similar to long reads that you find in most of the major news and journalism outlets.

Our other ideas are too good to share so we're keeping them under wraps - come back in six months or so and see if they made it into firebreak number two!

The rest of the week we kept meetings to a minimum. We started each day with a quick stand up to talk through the yesterday's achievements and today's plans, and then got back to work on our projects. We ended the week with a demo to the wider company and a firebreak retro, but more on that later.

What did we produce?

Our first pair built a video and chat room feature, with the idea of giving users control over videos in real time, while also being able to discuss content as you watch. Not only did they manage to allow users to play, pause and scrub video for themselves and everyone else watching, but they also were able to create what we called a 'teacher/student' relationship, where an admin user can control the video, but other users don't have permission to perform any actions on the video they're watching. This would be perfect for teachers assigning videos to students who are learning remotely, creating a allowing Oh, and they even had time to add a Giphy bot to the chat room, too.

The second pair took existing Digital Theatre+ content from PDFs and reframed them as rich text on a simple, HTML page. We had a hero image at the top of the article, with parallax scrolling of the overlaid title. Underneath that, we included a table of contents with sticky scroll, that also jumped smoothly to each heading within the piece of content. We included social media icons to allow teachers and students to share content easily. Within the body of the content, we added drop caps, indented our images with a negative margin so that they sat slightly outside of the text and also embedded video resources.

What was the feedback like?

We ended our firebreak week with two events. The first was a demo to the rest of our company - we hold a fortnightly demo during business as usual times anyway, so we used this recurring slot to show off our firebreak work. As most people on the call are non technical, we started with an explanation of what a firebreak is, its benefits, and also a huge disclaimer that none of the work they were about to see would be making its way into production anytime soon. We showed off the video and chat feature, and the rich guides, and both were a roaring success and received fantastic feedback from excited colleagues. The firebreak work got the wider company thinking about new ways to engage with and present our content, which is exactly what we'd hoped would happen. Our colleagues hit us with really insightful questions, ranging from child protection issues surrounding chat rooms to how teachers might use the rich guides for in-classroom discussions. It was great to see them so excited about our work, and we'll definitely be looking for ways to involve the rest of the company in future firebreaks.

Our second wrap up event was a closing ceremony retrospective just for the tech team, a chance to reflect on how the week had gone, and what we would do again or do differently next time we held a firebreak. We also used this time to discuss some of the more technical parts of each pair's projects, things we'd left out of the high level presentation we did to the wider company in our demo. It was really valuable to have this time to ask each other questions about the work, and take a closer look at the code, gawk at the lack of testing, etc.

Would we do it again?

Hell, yes! All four members of the DT+ dev team agreed that firebreak was a great chance to play around with our codebase and most importantly, a fun, relaxing way to spend a week after 14 months of focusing on the delivery of our rebuild MVP. Removing the pressures of business as usual and letting some creativity flow refreshed us as we prepared to enter a new stage in our team journey - post MVP feature development! A week was a good amount of time to spend on firebreak, and if (when) we repeat it in the future, I believe we'd want to stick with a week long event. As mentioned above, we'd love to get other members of the company involved in the future, especially as the ideas generation and design stage.

Big thanks to my colleague Kalle for loving my original title for this article (Relight my firebreak) and for also coming up with the even better one that I eventually used.

Inclusive Components by Heydon Pickering: a chapter by chapter review

Georgia — Tue, 16 Mar 2021 23:06:13 +0000

This post is the first in a series of posts in which I discuss and reflect upon what I've learnt from reading Inclusive Components. The book, written by Heydon Pickering, explores how web developers can create accessible components with semantic HTML, and how we can avoid using JavaScript unnecessarily by leveraging CSS to add both functionality and styling to our web pages.

Each chapter focusses on a different component. Amongst others, Pickering talks us through toggles buttons and menu buttons, collapsible section and check boxes - components we interact with on the web as users everyday. But as Pickering points out in his introduction, such components are often badly designed and executed, and therefore the web interfaces they form part of become all the more difficult to use.

Accessibility isn't going anywhere, and we're already (rightfully) at a point where accessible websites a necessity rather than a nice to have. It's very much a case of when, not if, features need to be reworked and updated to meet the increasingly rigorous guidelines around accessible design.

Through this series of posts, I hope to create a conversation between Pickering's views on creating inclusive components and my own experiences of developing accessible (and sometimes less than accessible) interfaces. I'll begin, unsurprisingly, with chapter one - toggle buttons.

Why we champion in person code reviews

Georgia — Wed, 17 Feb 2021 18:17:46 +0000

The team at Digital Theatre have been working on the rebuild of our educational platform since the beginning of April 2020. Identifying processes that help a new team collaborate effectively always has its challenges, and it's even more difficult to establish new ways of working when you're communicating with your new colleagues via a screen, rather than sat around the same table. There have been times over the last few months when we've got our processes wrong, though we've always been quick to reflect, remedy and improve. There are also methods we've introduced that have greatly improved our workflow. This article focuses on the benefits of one of these methods; the in person code review.

Here's a quick explanation of what I mean by in person. Most readers will be aware that it's standard practice, both in the workplace and in open source projects, for a developer to complete a piece of work, submit a pull request to a repository and have their code reviewed by other developers. This review normally comes in the form of written comments left alongside lines or blocks of code. An in person code review, however, is one where a piece of work is reviewed face to face - in our case, over video calls - and suggestions are delivered verbally and immediately to the author.

Below I discuss five ways in which the in person code review has helped our team to develop fast, flexible and clean code.

It speeds up our development process

It's true that it doesn't always feel like our in person code reviews are helping us develop faster. At Digital Theatre, we will regularly spend half an hour reviewing code, with this sometimes stretching to 60-90mins. As we do most of our work in pairs, this means that if there's two pairs involved in the review (a pair of authors and a pair of reviewers) we're likely to be spending anywhere between 2 and 6 hours of developer time going over a pull request. This seems like a lot of time to be spending on one piece of work, and it really is - we realise it, and we agree!

So, why do it? You may think that spending 90 minutes reviewing someone else's code is too demanding, and is just eating into time you could be spending on your own work. But code reviews that only happen over comments left on Gitlab or Github end up taking longer to be approved, as there's often a lot of back and forth about changes and suggestions. Consequently, it takes more time for code to get into production, increasing the chance of merge conflicts and complicated rebases and therefore slowing down the whole flow of the team.

Getting everyone onto one call also means that more members of the team understand the code that has been implemented. It broadens everyone's understanding of the codebase, and makes moving on to new tickets and parts of the product less of a jump. In person code reviews can make code you've not worked on directly feel that little bit more familiar.

So yes, these reviews might feel slow and demanding at the time, but overall, we're able to develop quicker because we're ensuring all members of the team have as wide an understanding of the code as possible.

Gives our team some... what do you call it... human contact!

Working from home can be really lonely, especially when we're also socialising less and hiding away from the cold, wet English weather. Our team works in a way that encourages lots of human contact, through daily stand ups and pair programming. In person code reviews are an important part of this workflow and another way of creating opportunities for team members to talk to one another. Everyone in the team is expected to get involved in code reviews, even - and especially - if it's a part of the codebase you don't work in frequently. So, while you might work closely with a few people on a daily basis, you can use code review as an opportunity to get some time with team members you see less often.

Improves team communication

Leaving comments on Github, Gitlab or whatever you use for your code reviews is a super useful way of recording your questions and comments for someone else's work. The team at Digital Theatre make loads of annotations on code reviews, either by going through a pull request just before jumping on a call to review the work, or leaving comments while on the call to help the pair go back through and make changes after the review.

However, when code reviews consist only of comments left on the git repository, there's way more scope for misunderstanding between team mates. Tone of voice can more easily be misinterpreted in written messages, leading to frictions between colleagues that would have instantly been cleared up over a video call. Therefore, by making in person code reviews such a integral part of our development process, we're ensuring that effective team communication is always a priority.

Allows you to ask the 'stupid' question

We've all been there - you're reading through someone else's code and there's an operator you've never seen, a convention you've not come across before or a decision you simply just don't understand. Sometimes, typing out a question and leaving it as a comment on someone else's code just seems too formal - it can become a 'big deal', when really, it's just meant to be a quick, minor question. A written message on a code review can be seen by the whole team, meaning that developers, especially more junior ones, may be less likely to leave a question they think is 'silly' - something they think they should already know.

Having an in person chat about code normally creates a more informal environment, one that provides developers with more opportunities to ask those spontaneous, niggling 'silly' questions. It downplays the need to find the correct wording and coherence required to write a question down. And perhaps those 'silly' questions are also answered with more kindness than a written comment left on a line of code would be.

Encourages you to explain - and defend - your code

Reviewing code on a git repository can put a level of responsibility on the reviewer to point things out and ask questions. An in person code review, however, encourages the developers who worked on a ticket to explain their code to the colleagues who are reviewing it. And while being able to write code is an important part of being a developer, the ability to explain the code you've written is just as important, and arguably a rarer skill amongst software engineers.

Additionally, in person code reviews encourage reviewers to ask difficult questions about why certain techniques have been used, or about the decisions and assumptions that have been made during the coding process. The authors of the pull request will learn how to analyse, explain and defend their choices, and also when to yield to the advice and opinions of their colleagues. It's a great way not only to improve your confidence in discussing how you've coded, but also why you've coded one way and not another.

Thanks so much for reading!

We'd love to hear your thoughts and suggestions for how to create a more productive and engaged team in the comments below.

Top developer tips for successful remote working

Georgia — Mon, 01 Jun 2020 08:35:14 +0000

It doesn’t need to be said, but let’s say it anyway; coronavirus has changed the way many of us work. We’ve gone from sitting next to each other every day - sharing a kitchen, sharing coffee breaks and after work drinks - to lugging our monitors home on the Central line, finding a corner of our homes to call work, and communicating through Zoom, Hangouts or your video conferencing tool of choice.

We’re always hearing that the demand for remote working is on the rise. And yet, many of us still value going into the office: according to the 2019 Stack Overflow Developer Survey, almost two thirds of developers in the UK would rather be working in an office environment than from their homes. The survey lists office environment as a deciding factor when it comes to choosing a new role, especially for women and non binary candidates. So if you’re used to, or enjoy, working from an office, what can you do to make working from home work for you?

Most of our dev team at Digital Theatre have never worked from our Monument office. Over the last month, we’ve had to cope with being interviewed and onboarded remotely, with jumping from video call to video call, and with building relationships over cups of tea that have been made in different kitchens - kitchens that lie just beyond the view you have of your colleague’s home. But we think we’re doing a pretty good job at remote working so far. We’ve put together a list of tools and practices that are helping us remain collaborative, focused and productive right now, and hope to come across others that we can add to our belts in the coming weeks.

Having the same working environment

As part of our onboarding and set up process at Digital Theatre, we encourage all new members to adopt the same IDE (integrated development environment) as the rest of the team. This means using our text editor of choice, VS Code, and installing a comprehensive but equally useful list of extensions. It may sound silly, but pairing with a colleague that has a really different working environment can initially be really difficult. You’ll often find yourself trying to understand the layout and configurations in their environment, which takes your attention away from the coding that’s going on. If you’re switching pairs frequently throughout the working day, this time spent familiarising will quickly add up. Having a consistent environment within your team removes this barrier, making collaboration easier and saving valuable developer time.

VS Code Live Share extension

This text editor extension allows a developer to share their codebase with colleagues and collaborate with others in real time. Set up is super quick, and team members can join a live share and make changes to code without having to configure environments, install dependencies or even clone a repo. You can give your colleagues full access to the codebase, with permissions to write in the terminal and to view front end changes in a shared browser, or you can set permissions to make their interaction read only. When editing, your teammates will benefit from any editor plugins you have installed, such as auto-complete and linting. There are a few negatives - we’ve found that the user experience can be a bit clunky, with code glitches and users seeing different code on the same page. Also, unless you’re the one who started the Live Share session, your view of the codebase will be based on git history, so any folders or files that are git ignored are invisible to you, which can be frustrating. Overall, Live Share has been a valuable tool for our team. It’s a good alternative from screen sharing in a video call as it allows multiple team members to edit the codebase, therefore giving them an active rather than passive role in pair programming. It’s definitely a tool to explore if you’re looking to improve your team’s collaboration.

Using two screens

Working remotely has added video calling to the long list of tabs that developers keep open throughout their working day. Constantly moving between your codebase, Slack and a multitude of browser windows can get tiring very quickly, and it’s easy to feel lost and frustrated amidst the chaotic sea of disorganised tabs and windows. Having an extra screen ameliorates this problem, allowing you to keep two windows open, while others are now just one swipe away.

Slack

We’re of the opinion that Slack is a building block of any tech team, and this is even more true for teams working remotely. It’s a great tool for communicating on a one to one basis, and also as a group. Creating channels means we can share information efficiently - interesting work-related reads and random tweets are kept out of our main channel but are still easy to engage with. Starting threads stops ideas from getting lost in group chatter, and makes conversations about a specific topic simple to follow and to find later. Slack’s integrations remove the need to keep multiple windows open; having access to our calendars, to the pipeline and to the status of our latest merge request all from the same app is super useful. Its built in calling tool means a face to face meeting is just one click away - no need to navigate away to Zoom or Hangouts. If your team has a subscription, you’ll be able to benefit from group calls and screen sharing, too.

That's it!

Thanks for reading our top developer tips for working remotely - if there's a tool here you've not tried out yet, we hope this encourages you to give it a go!