Ever wanted to learn about coding standards by examining the botched ending of a TV show? We’ve GOT you covered!
It’s hard to ignore that many fans are disappointed in how the writers of Game of Thrones (GOT) Daniel Brett Weiss and David Benioff (who shall be henceforth known as Dan and Dave) handled the eighth and final season. Remember the infamous petition? If that’s not enough proof, try searching google images for ‘bad writers’ – images of Dan and Dave pop up.
While software and TV shows might seem like totally different things, in the industry, both are created from team members and adhere to certain standards. Let’s examine some of the hits and misses of the writers to understand more about coding standards.
A huge complaint from fans is that Dan and Dave rushed the last season of GOT; they were trying to cram so many events into one episode, that the audience didn’t feel the weight of each event. For example, in the first episode, Jon rode Rhaegal – something that has huge significance, but the viewers are not given time to appreciate this event because it comes halfway through an episode where: Jon reunites with Bran and Arya, Theon rescues Yara, the golden company comes to Westeros, Ned Umber is killed by the white walkers, Jaime Lannister turns up at Winterfell and confronts Bran, and Jon learns that he is actually Aegon Targaryen. Compared to the moment when Daenerys first flew with Drogon, which was the climax of a ten-minute scene, Jon’s first flight falls flat. Created a precedent for themselves because of how the events were paced in the previous seasons.
Not adhering to coding standards can make your code appear low quality. It can be a sign that you rushed the job or didn’t put a lot of effort in either the code itself or in being part of a team. Additionally, it decreases your credibility as writer/producer or software engineer.
One thing that Dan and Dave got right was that they documented some of the creation of the show. After each episode, they release a behind the scenes video, which documents some of the creative decisions they took, as well as the craftsmanship that it took to make the episode. While many fans disagree at least they can try to understand how Dan and Dave are approached this project, at least they started commentary to help keep you engaged.
Documentation is helpful, especially when you or someone else is revisiting your previous work in the future.
Dan and Dave underutilized the tools they were given. Many fans argue that the quality of GOT decreased after Dan and Dave moved farther and farther away from the source material (Season 5). However, they could have consulted the author George R. R. Martin himself for guidance; he even suggested that the show could run 13 seasons with the amount of content he had produced. HBO was also willing to produce 10 episodes for the last season; I’m sure that HBO would have been happy to coordinate help from other writers if necessary. When coding, you should take advantage of the tools you have at your disposal. Since there are so many IDEs and plugins that will not only suggest what to fix in your code but automatically format it for you, there is no excuse to not adhere to a coding standard.
I think one of the biggest things Dan and Dave forgot to consider was the life and longevity of their project. While studios make money from the initial release of a TV show and merchandise, they also make money from residuals. If the popularity of a show persists beyond its release, whenever the show is re-run on TV or when streaming services buy the rights to host it on their platform, the people involved with the project still earn money. What Dan and Dave failed to realize is that they wasted the effort behind not only season 8, but the complete series. People aren’t going to want to invest in watching the entire series if they know the ending does not pay off. All the effort put into the series by the rest of the team members – the actors, production team, editors, musicians, cinematography team, and the rest of the crew – is overshadowed by the bad writing.
When writing code, one of the things you should consider is if your code stands the test of time. A couple of months from now, will you be able to understand the code you wrote? Are other people going to be able to easily read and understand it? Is this something people will be able to build upon or use in the future? Is there effort reflected in the final product?
If anything, take solace in the fact that your code wasn’t bad enough someone created a petition.