Things I Learned About Software From Things Tina Fey Learned About Producing From Lorne Michaels
Part 1: Creativity Overrated thru It's Showtime
Posted by Charlie Recksieck
on 2021-11-11
As a lifelong Saturday Night Live fan, Tina Fey sharing her observations on show businesses from SNL creator and showrunner Lorne Michaels was not one of the New Yorker articles I would quit after hitting the 5000-word mark. (Yes, this Tina Fey article is itself under 5,000 words.)
I highly encourage you to read it ASAP as a piece of entertainment and funny writing.
Additionally, this New Yorker article has built-in, great advice as managerial instruction. Here’s the numbered list of things Tina Fey learned from Lorne Michaels ...
1) Producing is about discouraging creativity.
2) Figure out if there is something you're asking the actor to do that's making him or her uncomfortable.
3) The show doesn't go on because it's ready; it goes on because it's 11:30.
4) When hiring, mix Harvard Nerds with Chicago Improvisers and stir.
5) Television is a visual medium.
6) Don't make any big decisions right after the season ends.
7) Never cut to a closed door.
8) Don't hire anyone you wouldn't want to run into in the hallway at three in the morning.
9) Never tell a crazy person he's crazy.
This Article
With the piece in question as a foundation, what I'm offering below is for me to take those 9 sentences of advice and describe what they mean in a software design environment. I've been in this field for 25 years now, with hundreds of case studies of computing projects varying from career highlights to a couple unmitigated disasters. So here we go. Hope you like it.
1 - Producing is about discouraging creativity.
The word "producing" in film & tv is probably most analogous in software development as "project management". When you're managing resources on a project, each person is generally 100% responsible for their own little fiefdom of the files/code.
Somebody working on GUIs (forms, the look of an app, etc.) is often the only one working on it. The person coding the password and authentication system is probably alone. Each area is their own little "black box", which kinda means that from the outside we don't see the workings inside. The box is very "modular", meaning it's been planned or agreed to on the project what values go in & what values go out.
Making these black boxes can get boring. Lots of times, programmers love to try to work with new technologies. Almost all of us got into or became good with development because we thought the way some code works was "neat". But the new, novel, more interesting or creative idea for the project is not usually the faster, cheapest or smoothest.
Whenever somebody comes to me with "What if we did ..." then I can probably call time out right there and guess that we are not going with this idea. 4 times out of 5, we don't need to reinvent the wheel. As a manager, the important part things here are to: 1) Hear the idea out, maybe it really would be smart in this case, and 2) If and when you say "No", say it in a way that doesn't discourage future ideas or creativity.
2 - Figure out if there is something you're asking the actor to do that's making him or her uncomfortable
In software development, we aren't asking programmers to do a nude scene. Or at least I really hope your office isn't asking that.
But there is a tendency for management to want to allot only X amount of hours because management thinks that's enough. When the developer disagrees and has a good reason, one of the main reasons that projects run behind schedule and over budget is that the manager is making unreasonable demands on programmers.
3 - The show doesn't go on because it's ready; it goes on because it's 11:30.
At some point, the finished product needs to get out the door. That doesn't mean that you should intentionally release seriously flawed apps purely to hit your deadlines. But ...
You can't make a perfect software product. They really don't exist.
You can't afford to let "great be the enemy of good." There's a balance between making sure you don't cut corners and don't sweat the small stuff. If it's a good idea for code to record a historical log of every event that happens in a database, but if it's too time consuming (or memory-consuming) to actually do so, then let's drop that feature.
As John Guare says in his phenomenal play "Six Degrees Of Separation", sometimes the key to making a brilliant painting is the teacher knowing when to take the paintings away from the student.
Click here to read Part 2
