May 27th, 2015

Candor and fairness

In the interview I recently published on this site, production designer John Lavin talked about separating yourself as a person from things that you work on:

I used to teach drawing, and just the exercise of taking somebody who is not really used to that and saying “Here’s the drawing you made, go hang it on the wall and we’ll discuss it”, putting things up for criticism is something that I got pretty used to. And even though I’m sensitive to the criticism as a person, I’ve got a lot of practice with the idea that this painting, or movie, or thing that I work on isn’t me. It’s a thing I made, but it’s not me. It’s separating my identity from my product.

In Creativity, Inc. Ed Catmull writes this in the chapter “Honesty and Candor”:

[…] the only way to get a grip on the facts, issues, and nuances we need to solve problems and collaborate effectively is by communicating fully and openly, by not withholding or misleading. There is no doubt that our decision-making is better is we are able to draw on the collective knowledge and unvarnished opinions of the group.

And in the last post I talked about how important it is to focus on criticizing the code and not the person behind it:

Stay focused on criticizing code. If you feel strongly about something, be direct and concise. But never ever ever get personal. See the arguments for what they are and for what they should be. You are not your code. A critique of your code is not a critique of you as a person. Sometimes it’s hard to tell the difference especially if you’ve been working on something for a long time.

You can call it honesty. You can call it candor. You can call it sincerity. You can call it frankness. Some of these words come with heavy baggage attached to them, and that baggage can vary based on the cultural and societal aspects that you have absorbed in your life.

Clarity is the most important part I strive to achieve in the code I write. Clarity also plays a critical part in the code review phase, no matter which side of the process you fall on. In fact, let me strike that. In the code review phase it should not matter who wrote the code and who is reviewing it. You should work together as a team to crystallize the best solution possible to implement a specific feature or to fix a specific bug.

Communication within a team of people is already complicated. We all bring our own baggage, our own upbringing and our own cultural environment to it. Communication is by definition a two-way channel. Removing the complexity from this channel is the responsibility of both sides of the channel. Bringing clarity and candor to this channel is the responsibility of both sides of the channel.

As the person being requested to do code review, you should free yourself from the notion of how “senior” or “junior” the code author is. Bad code is bad code. Complex code is complex code. Criticize the code, fairly and constructively. The down side of not being as “senior” on the team is that you might not be aware of all the legacy aspects and decisions that were made when you were not on the team yet. It’s the responsibility of the code author to point you to the relevant decisions when you ask about them. The up side of not being as “senior” on the team is that you bring a fresh look. A fresh set of ideas. A fresh pair of eyes that should look at the code critically and see where, when and how it can be improved instead of being left to slowly stagnate.

As the person writing code and submitting it to review, you should detach yourself as a person from the product you are making. Free yourself from being defined by the code you write. Do not judge review comments based on how “senior” or “junior” that reviewer is. Free yourself from looking at those comments as something that originated from a person and treat them as a thing of its own. Some things that might be very clear to you would be too dense and opaque for a person who is not familiar with that part of the code base. Does it need more documentation? Does it need splitting up the logic into smaller, more manageable pieces? Or perhaps you unwittingly have fallen prey to the complexity beast?

The up side of being a “senior” on the team is that you are more aware of all the legacy aspects and decisions that were made since you’ve joined the team. It’s your responsibility as the code author to point the reviewers to the relevant decisions when you are asked about them. The down side of being a “senior” on the team is that it’s so easy to fall into the trap of been-there-done-that. It’s when the code base is slowly crumbling around you under its own weight, but you don’t even realize that it’s happening. That’s when you need somebody that brings a fresh look. A fresh set of ideas. A fresh pair of eyes that would look at the code critically and see where, when and how it can be improved instead of being left to slowly stagnate.

And if all the members on the team are candid and fair in code reviews, you might all just have a chance of enjoying working on that code base. At least most of the time.

May 21st, 2015

Code reviews

One of the most enjoyable, and at times scary, things about working on my team is doing code reviews. They are mandatory no matter how “senior” you think you are or how long you’ve been on the team. I sometimes catch myself thinking “better not add Mr. SoAndSo because he’s going to point out all the ugly things in this pile of hacks I’ve been constructing here”. It’s those times where I just go back and try to make things less hacky. And then add that guy who would have the most objectively critical eye to look at the code change.

Do code reviews. You’ll occasionally butt heads, as there’s rarely a single “best” way to make even the simplest bug fix. But no matter how “senior” or “junior” your reviewers may be, you’ll always be better off at the end. I lost count of the number of times that I said to myself “Huh, I didn’t know that” after seeing a reviewer leaving his comments. Not to mention that you’ll have somebody else having at least some level of familiarity with your code if you ever get too swamped. Don’t count too much on that though, as people weave in and out of projects.

Every once in a while you’ll get out of your comfort zone working on a new feature or fixing a bug. At some point you know your reviewers, their style and their strengths. Don’t be tempted to add reviewers that will be inclined to rubber stamp such code. Seek out people who are deeply familiar and well versed in the specific area. You will be afraid that they’ll pick your code apart like a poorly constructed house of cards it is. Better now than after it ships. Such a reviewer knows how to do this better than you, and the result will be better for both you and your code base. It will just take longer. Don’t let your ego take a hit. It’s just code.

When you’re asked to do a review, do it quickly. Don’t drop everything and do it immediately, but do it the same day. The quicker you provide good and actionable feedback, the fresher it is on the side of the code author. Don’t let your reviewers rot. This also helps preventing unnecessary rebases. Not to mention spreading your strengths around, and learning from the strengths of others.

Don’t do gigantic code drops. If it’s a big feature, map out smaller steps towards the final goal. Mark unfinished places with TODOs so that the reviewer knows this is not the final thing. Build trust in each other to understand that sometimes the road to the final feature takes multiple steps. But always keep an eye on those first couple of steps to make sure that the road is taking the right overall direction.

Stay focused on criticizing code. If you feel strongly about something, be direct and concise. But never ever ever get personal. See the arguments for what they are and for what they should be. You are not your code. A critique of your code is not a critique of you as a person. Sometimes it’s hard to tell the difference especially if you’ve been working on something for a long time. Code reviews are a negotiation. It’s not a zero sum game. In the end, it is all about clarity and complexity.

There’s no better opportunity than doing code reviews to grow and become just that much better. Every single day, if you can. Even after all these years. There simply is no such a thing as those mythical 10,000 hours in our field.

May 18th, 2015

Charging ahead – interview with David Sheldon-Hicks of Territory Studio

What a year has it been for Territory Studio and its founder David Sheldon-Hicks. It’s only been nine months since our interview about the studio’s screen graphics work on “Prometheus” and “Guardians of the Galaxy”, and in the meantime Territory’s work has graced the big screens on three major motion pictures! In this interview David talks about exploring the technical and human aspects of advances in the field of artificial intelligence in “Ex Machina“, the futuristic interfaces of the alien universe of “Jupiter Ascending” and the vast screen graphics canvas of “Avengers: Age of Ultron“. He touches on the collaboration with directors and production designers to distill and refine the visual language of the interfaces, the process of rapid prototyping in the pre-production phase and the tight back-and-forth adjustments of on-set playback sequences, and the technical aspects of projecting interface sequences on translucent glass screens. In the last part of the interview David takes a deep dive into the world of virtual reality interfaces, ranging from enhancing cinematic experiences to better leverage of content in our everyday work and leisure scenarios.

Kirill: Last time we spoke about your studio and its earlier work. And in the meantime you’ve had Jupiter Ascending, Ex Machina and Avengers: Age of Ultron come out, with a lot of work that you’ve contributed to these productions. And on top of that, you’ve started exploring the world of virtual reality.

David: We actually worked on Jupiter Ascending a year prior to that interview. The project took a while to come out (6 Feb 2015) so we haven’t been able to talk about it up until more recently.

Kirill: How does it feel that you have this pile of work that you’re sitting on and can’t tell anybody about?

David: In some ways it’s really frustrating, especially for the people in the studio who have worked on it. But, we’ve all signed NDAs, and don’t want to ruin it for the fans by saying something that might spoil the story.

Yet, it is quite nice to have a bit of time to prepare our portfolio and showcase, to fully do it justice in terms of the story behind all the work. When you’ve just finished a film, you’re so exhausted and still in that space. Sometimes it’s hard to look at the project objectively and fully appreciate all of the thinking and the ideas that went into it. When you have space and time – around six months or so ideally – you get enough distance to join up the dots between the deliberate and intuitive.

This gets really interesting when it comes to our approach to technology in a film like Avengers. By reflecting on how the script and story points influenced our research, we can sometimes see how quickly perceptions and expectations around innovations evolve.

Looking back we can see how public opinion regarded a piece of technology at the moment we were making the film, and how it changed over the 6 or 12 months leading up to it’s release – and hopefully we’re not behind technology!

Kirill: Does it worry you that the world of consumer technology is evolving so rapidly around us in that regard? Can your work quickly become outdated?

David: As a user, yes, because it’s hard to keep up sometimes. But as far as the work being outdated, in some ways we have to celebrate that. We play on the fact that it’s a film of the moment that reflects the cultural experiences of that point in time. It’s not just about the technology, but also about what the technology says about us as a culture. And I’ve always loved that about unashamedly 80s movies. For example, the idea of hoverboards in “Back to the Future” reflected our cultural expectations that skateboarding, so huge at the time, would exist in the future.

So the idea of a date stamp is not such a bad thing. If a film does date because of its views on technology, it can be quite enjoyable. And there’s an element of nostalgia in that, perhaps ten years into the future. You look back on it with fondness the same way you’ll look back at your current iPhone 5/6 when you’re holding your new iPhone 20 or whatever it might be.

Of course, there are other ways to explore technology and different films date in different ways.

In Ex Machina, Alex Garland [writer and director] was more interested in near-future thinking rather than techno-fantasy. He had done a lot of research around AI for the film to keep the story grounded, and we also undertook a lot of research into UI and UX in terms of where the technology is going. So our work in that film reflects the evolution of user experience towards simplicity, personalisation and ease of access, while it also reflects the narrative layers in the story.

Embedded just underneath the lovely uncluttered UI is access to programming code: we wanted it to feel that Nathan had created this OS for the benefit of the public, yet always kept close to the code, and could easily access and manipulate it.


BlueBook office browser software in Ex Machina. Courtesy of Territory Studio.

So, while the work that we delivered made a loose statement on where UI and UX are going, it was also a technological window into narratives playing out around the film – a narrative device for the characters to monitor the activities around the building, for example.

I’m sure Ex Machina will date in a slightly different way other films of that genre because its focus is not to comment on future technology and it’s not tying itself into the cultural zeitgeist in terms of style. As a film about the thinking around AI and our relationship to technology at this time, it’s less a statement about aesthetics and more of a timeless piece.


Ex Machina screens still. Courtesy of Territory Studio.

Read the rest of this entry »

May 13th, 2015

Complexity

People come and people go. But the code base stays there. It evolves over time, like an amorphous organism. It mutates (or is, rather, being mutated) to meet the changes in its environment. Some of its parts don’t always function as expected, requiring a surgical procedure to try and set those parts on the right path. And if you’re not careful, it can swallow you whole and nobody will hear from you ever again. Analogies. They always break apart at some point.

Last December marked my fifth anniversary on my current project. The codebase has been there before me (perhaps a year or a bit longer), and since then it has seen significant changes. I doubt that there’s any single line of code that has survived untouched in all that time. Some modules have been rewritten completely. Some have been rewritten completely more than once (hello local app history management). Certainly none have remained in their original form or function as we’ve moved through multiple rounds of redesigns that were (almost always, hello all things Material) driven by evolving business requirements.

And beyond all the feature changes, there are always bugs. Sometimes they are in my code. Sometimes they are in this code that this other person wrote, and it just so happens that they are half way across the globe enjoying their vacation just as we’re closing down on this year’s I/O and seriously who does that. OK, that was too specific. And sometimes bugs happen to be in the module that was last touched by this guy who’s no longer on the team and not even any longer at the company.

Clarity and brevity are your only [citation needed] two weapons to help you wade the murky waters of code that is not old enough to be completely replaces but not young enough that you can actually remember either writing or reviewing it. Complexity, on the other hand, is your worst enemy. Back to analogies!

Complexity is an affliction that attaches itself to this one part of your organism. And it’s not going away on its own. Next time you’re in that module, fixing a bug or extending the functionality, that complexity winds itself into the new code, spreading just a little bit farther in. And then it intersects with another affliction that originated in another part of your organism. At the time, both afflictions were pretty local and pretty small. But they were left unchecked, growing just that much bigger every single time somebody touched things around them. And now they are intertwined.

And at some point you have that thing in your organism that everybody’s afraid to touch. Nobody has any idea how to make it better. Nobody has any idea what side effects a specific surgery (aka bug fixing) will have. It might have taken you a couple of hours at the beginning of the next release cycle to go back and treat that original affliction because you just didn’t have enough time to be clear and brief. But ain’t nobody got time for that. That’s not glamorous work. That’s not work that you put up in your promo packet. That is work that can only be appreciated by people who have spent at least a few years on the same code base.

Complexity is by far our worst enemy. Well, that and software patents. But that’s a whole another subject.