April 22nd, 2015

One step at a time

In the epilogue of “The Mythical Man Month” Frederick Phillips Brooks says that there are only a few people who have the privilege to provide for their families doing what they would gladly be pursuing free, for passion. I am quite lucky to consider myself to be among those people. In a hypothetical situation where I buy a lottery ticket and win the 8-digit prize, I’d most probably find myself not necessarily continuing programming each day, every day. Having said that, it’s quite nice to be employed doing what you love to do. But, as with all things in life, you can’t expect a steady level of “enjoyment”.

Years and years ago (I’m talking last century) when I was studying computer science at a university, one of the mandatory courses included a homework exercise doing a stopwatch in assembly. You had to write a program that gets user input in mm:ss format, and when the user hits Enter, starts counting down to zero. I think there was also the part where you had to track keyboard input and stop the timer, but my memory fails me at the precise details.

I hated that exercise. I absolutely abhorred the very notion of dropping so low to the metal. You know, pixels are my people. So I waited. And waited. And waited. Until the very last evening before the morning when the homework was due. And then I schlepped to the computer lab, plopped into the chair and considered the bleak night in front of me.

As a parent I tell my kids to not postpone the exercises and chores they don’t like until the very end. I tell them that if they start with things they enjoy, they end up with a clump of boring, tedious and dull things at the very end. Of course back then I didn’t want to be quite as reasonable. So as I forced myself to start with something, anything, anything at all, I picked up the less mind-numbing parts of the exercise.

I started with processing the user input. Something like look at the character that was just typed and beep if it’s not a digit. Then proceed to mirror the character on the screen and advance the cursor. Then, at least after one digit, also accept the colon. Then tweak the input validation to only accept digits from 0 to 5 in the next slot. Then tweak the input validation to only accept Enter after exactly two digits after the colon have been provided.

And then I stalled for a bit more time, tweaking the input processing routine to accept additional Enter strokes to treat them as decrementing one second from the timer. Which brought me to writing another routine that would update the currently displayed value, handling the transition from :00 to :59 state.

I distinctly remember the depression I felt at the very thought of tracking and syncing with the system time facilities. I tried to postpone it as much as I could. It was the farthest away from the pixels, and I left it until the very end. And then a wonderful thing happened.

As I kept peeling off those onion layers, I kept on getting a continuous stream of visual progress confirmation. My routine for accepting the initial timer value was working. My routine for rejecting invalid inputs was working. My routine for decrementing the current timer value was working. And as I kept peeling off those onion layers, and as I got the the very last piece, I found out that it was actually quite manageable. There was only this last thing to cross off the list. I did it and I didn’t even notice how smoothly it all went.

Fast forward to early March 2015 and the code base I’m working on. It’s been around for a while. I’ve been on it for a while, almost five and a half years. It’s seen some major redesigns. In fact, I can’t think of a single module or class in it that hasn’t been gradually (and completely) rewritten at least once. And it has a lot of baggage.

I’ve briefly mentioned this the last time Chet and Tor hosted me on their podcast. As we started down the path of bringing our app into the Material world, we had two choices. We could graft the various aspects of Material (keyline grid, in-screen animations, cross-screen transitions) on top of the code base that was, frankly, simply not built to be that flexible. Or we could rebuild the foundation (ahem, yet again) with an eye towards that flexibility and then bring those elements in.

Rebuilding the foundation is at most times a long, dull and unexciting process. You know that at some point in the hazy future when it’s all done, it will enable all these wonderful things (and you hope that by the time you get to that hazy future, the design hasn’t changed in any major way). But for now, and perhaps for a while, the things you’re doing are not resulting in any kind of user-facing improvements. If anything, the deeper you dig, the worse it gets for the overall instability of your code base (aka Things You Should Never Do – except when you really have to). And so you dig, and you dig, and you dig. And you get closer to that hazy future. One step at a time.

And then at some point you look at what you’ve built, and you see that it’s ready. And you make a 150-line code change and suddenly you have the hero image extending all the way into the status bar on the details page. And the next day you make a 40-line code change that builds on top of that and you have the same functionality on the profile page – because they share the same skeleton structure that you and that other guy on your team has just spent the last four months rebuilding from scratch. Oh, and there were these ten people scattered all across these other teams that built the components that enabled to rebuild that skeleton structure in only four months. But I digress.

And then the next day you have a 50-line code change that brings the same functionality to a more complex context that looks exactly like those other two you already did, but instead of a simple RecyclerView it’s a RecyclerView in a ViewPager that has a single tab which hides the tab strip where you don’t even know if you’ll need to display the hero image until after the second data loading phase that happens when you’ve already configured the initial contents of that ViewPager. But you didn’t start straight away from this complex case. You started from a simpler case, hammering out the details of how to even get into the status bar. And when you got to the ViewPager context, you were able to concentrate on only that one remaining case.

And so you go. Across the landscape of your code base. Sometimes it just flows and you don’t even notice how yet another week flew by. And sometimes you look at this craggy cliff and you just want to turn and run away. But instead, you work at it. One step at a time. And before you know it, the cliff is behind you. And then you take the next step. Because the next cliff is waiting.

April 15th, 2015

The art and craft of production design – interview with John Lavin

Continuing the ongoing series of interviews with creative artists working on various aspects of movie and TV productions, it gives me great pleasure to welcome John Lavin. In the last few years he worked as the production designer on “Your Sister’s Sister”, “Touchy Feely”, “Lucky Them” and the recently released “Laggies”. In this interview John talks about splitting his time between feature film world, interior design projects and illustration work, the smaller scale of independent movie productions, approaching the script and translating it into environments that live and breath around the cast, the changes we’re seeing in how and where people consume content and the effect it’s having on the world of indie films, and a deeper dive into the particulars of “Your Sister’s Sister” and “Laggies”.


Interior sets of “Laggies”.

Kirill: Please tell us about yourself and your busy professional life doing feature film work, interior design and illustration work.

John: A lot of that is driven by me living in Seattle rather than in, say, Los Angeles. There’s not a lot of feature production happening here, and I have always had the idea that it’s better to be a generalist than a specialist. It works better for me to have a lot of irons in the fire, to work in different directions.

I was in New York, going to graduate school for painting. I was living there, doing jobs as a retail display person. I worked doing the windows at Barneys, and from there moved to art department work, doing photography, video and other projects. It was a combination of retail display, art department and fine arts. I used them all in different ways, and that’s the background that I’m coming from.

When I moved back to Seattle, I did a lot of work as retail designer. My art work translated into illustration work when my second child was born. It was a better economic model for a working parent to get paid upfront for things instead of hoping to sell things later.

And as far as all these fields, it’s really all the same thing. It relates really closely. There’s not that many people that I work with, or that I know, who work in all of these fields, but they’re actually very similar. It’s all about making something look good from a certain point of view. It can be a camera, or a person standing on the street, or walking into a room and having the sense of the space.

Kirill: I’d imagine it also exercises different parts of your brain.

John: Absolutely. The current project that I’m working on involves a lot of set design and a lot of space design. I’m trying to make modular set pieces that can work for different shoots at different times and be reconfigured. It’s about spatial organization and design, more than many other jobs. And other jobs are about visual sensibility or painting sensibility.

Kirill: It sounds like you’re also enjoying the physicality aspect of it.

John: I sure do. I really like painting. I like sculpting. I like making and faking.


On the restaurant set of “Laggies”. Courtesy of John Lavin.

Kirill: If I jump a bit forward in the interview to your feature work, what do you think about productions driven by virtual sets created with digital tools?

John: I came to work on indie films, and I recently heard them being described as “people talking in a room”. I have an affinity for a movie of that scale.

I like to watch a big movie as much as the next guy, but there’s a certain thing that I don’t relate to well and don’t have a lot of interest in. It’s the CGI ‘Battle that Decides the Fate of the World’ that happens in so many large films. You have two massive armies engaged in a huge battle, and the whole thing feels so completely bogus. I don’t have any interest in that.

I like the idea of a smaller scale feel, and that’s the kind of film that I’m more interested in working on – compared to the effects-driven film.

Read the rest of this entry »

April 15th, 2015

Make peace

I’m not going to take credit for the story, nor would I claim a perfect analogy. But here goes.

Imagine you’re in a room with ten screaming babies. As all of them are screaming at the top of their lungs, you start feeding them one by one. You’re done with one, and there are nine screaming babies left. Some time passes and you’re done with another one, and there are eight screaming babies left. Some time passes and you’re done with another one, and there are seven screaming babies left. And it doesn’t feel like you’re making any kind of progress because as long as there is at least one baby screaming, you can’t get any peace.

That’s how it can feel to be a programmer on any reasonably sized project. Where screaming babies are bugs in your incoming queue. They never stop demanding your attention, and they never stop screaming at you. Unless you make peace.

If there’s one axiom of software development that I hold inviolable, it’s that there will always be bugs. You can surround yourself with a bunch of processes, or do extensive code reviews and endless testing rounds. But the bugs will always be there. If anybody tells you that their code doesn’t have bugs, just shrug and walk away. They have no idea what they’re talking about.

Make peace with the simple fact that the code you’re shipping today has bugs.

Some bugs are scary. You need to tackle them. Some bugs, on the other hand, are these little tiny things that simply don’t matter. The problem with most (probably all but I haven’t tried them all) bug trackers is that the scary bugs in your queue look exactly the same as the tiny bugs. Most of the time the only difference is going to be in the single digit in the priority column. Or maybe the scary bugs will have light red background across the entire row. Or maybe the tiny bugs will use lighter text color. But they probably won’t.

And so you stare at your queue and you feel that you just can’t win. No matter how much effort you throw at that queue, as long as you’re not at zero bugs, they are screaming at you. And every time you fix a bug, you touch your code base. That’s another bug that you’ve just added. And every time you fix a bug, you get assigned a couple more.

Make peace that not all bugs are created equal.

Zero Bug Bounce is a fiction that some people invented to make peace for themselves and to create an illusion that they are in control. So at some point in the cycle everybody looks at the pages upon pages of bugs in your project queue, frowns and then mass-migrates a bunch of bugs to the next release. And to the next one. And to the next one. And at some point some bugs have been bumped out so many times that you might as well ask yourself some very simple questions. Do those bugs matter? Do they deserve to be in the queue at all?

Make peace that not all bugs are actually bugs.

Sometimes a feature that you’ve added to your product just doesn’t work out. It doesn’t get the traction you’ve expected. Or it’s not playing well with some other features that you’ve added afterwards. Or you’re not even sure how much traction it’s getting because you forgot to add logging, and there’s nobody on the team who actually cares about this feature after the guy who did it left the team and you’re in the middle of the big redesign of the entire app and why should you even be bothered spending extra time on that feature. Phew, that was a bit too specific.

And of course there will always be somebody who used that feature. And now that you’ve taken that toy away from them, they are screaming at the top of their lungs. And you cave in and bring that feature back. Well, in theory at least. But it’s been redesigned to fit into the new visual language of the platform. And now somebody else is screaming at you because you’ve changed things. All they want is just a teeny tiny switch in the settings that leaves things they way they used to be. Sure, they want new features, as long as they look exactly like the old features. But that’s a topic for another day.

Make peace that your work is never done. That if you want your work to be seen, you have to ship. Make peace that the work you ship will have bugs. Take pride in things that work. Develop a sense to know scary bugs from fluff. And develop a thick skin to ignore the screaming.

 

March 31st, 2015

The art and craft of production design – interview with Steve Saklad

Continuing the ongoing series of interviews with creative artists working on various aspects of movie and TV productions, it gives me great pleasure to welcome Steve Saklad. After doing art direction for films such as “The Game”, “Red Dragon” and “Spider-Man 2” for the first part of his career in Hollywood, in the last decade he did production design on a variety of productions including “Juno”, “Up In The Air”, “The Muppets”, “Labor Day” and, most recently, the pilot episode for the TV show “Empire”. In this interview Steve talks about his theatrical background, the changes that the art department is undergoing in the last decades, his involvement in pre-production and production phases of his films and his work on 250 (and counting) commerials. In addition, he takes a deep dive into the production details of the “Empire” pilot, “Up In The Air” and the beautiful atmosphere of “Labor Day”.


Kirill: Please tell us about yourself and your path so far.

Steve: I’m a theater person deep down. Raised on musical theater since boyhood, I spent all my time in the theater department at my undergraduate college (Brandeis University) and trained in Set Design along with Costumes and Lighting at Yale School of Drama for my graduate degree. I arrived in New York with my sketch and drafting portfolio in the summer of 1981, ready to design my first Broadway show. I designed a few off and off-off Broadway shows during the decade, but primarily was first assistant to the top Broadway set designers on some of the great shows of the 80’s. Little by little, drafting for Broadway seguee’d into drafting for movies. By the 90’s I was a feature Art Director, now living in Los Angeles, and designing commercials on the side. After all that prep time, I was good and ready when my first Production Design opportunities in indie films came along in 2004.

Kirill: What drew you into the world of the art department, and what – if anything – has changed for you since you’ve started working on your productions?

Steve: Like the set design department in theater, the work of the Art department is all about creating a world that didn’t exist before you started. It could be operatic, super-natural or documentarian, it could be the fantasy world of “The Muppets“, or the banal real-world environment of “Up In The Air“. You’re setting the parameters and saying this is what’s important visually to tell the story you want to tell. That’s thrilling.


Sketch drawing for the backstage set of “The Muppets”. Courtesy of Steve Saklad.

Changes since I began in the art department— how much time do you have? When I began, we drafted in pencil on velum paper which was then sent through a diazo machine to make a blue-line print. We carried pagers, sent approvals by fax, and kept quarters in our pockets to make emergency phone calls from pay phones on the corner. The computer revolution has changed the outer tools, but not the process. We still assemble moodboards by hand, still page through books for inspiration, still match fabric swatches with paint chips to arrive at a color pallet. Set models are now often digital versions on a computer screen, although I still prefer the old-fashioned 1/4″ paper models. I still find my way to a design by sketching in ink on buff yellow onion-skin paper and adding markers and whiteout to give it life. But I’m admittedly a relic of another time compared to most designers I know.

Kirill: You’ve spent the first half of your career so far as an art director. What have you carried with you as you transitioned into the role of the production designer, and how does that affect your working collaboration with your art directors?

Steve: It’s a great question. I know the nuts and bolts of running an art department as well as construction, paint and greens departments, I know how budgets are structured and what designs generally cost because I did that job for almost 15 years. I hope that means I’m more compassionate to my art directors, knowing what they’re going through to make our designs come to life. I’ve also been blessed with getting to work with some amazing Art Directors under me, who have taught me far more than I could ever teach them. It’s definitely a two-way street.


Sketch drawing for the final scene in “Up In The Air”. Courtesy of Steve Saklad.


The final still from the movie.

Read the rest of this entry »