Note: There may be mild spoilers ahead. I’ll try to keep it vague and general, but if you’re really worried, go see the movie before reading this post.

“If we can’t protect the codebase, you can be damn sure we’ll avenge it."

I, as many of you, saw The Avengers this weekend. I don’t mean to review it here, but I found myself smiling at many situations thinking, “Well, that’s just like software development and team leadership.” I guess thinking about code while at a blockbuster movie just strengthens the case that I’m not a 501 (not that there’s anything wrong with that!).

Here are some of the things I was able to remember and get down into my notes while the credits rolled. This post will be quickly thrown together. I expect that it will have some flaws and likely come out being quite ridiculous :)

But It Usually Works...

Loki has this really great trick where he will tap your heart with a scepter, and you become his mindless minion. Come to find out that doesn't work so well if you're tapping an ARC reactor.

Test everything. This is nothing new, but something that bears repeating frequently. Works on my machine isn’t enough. Works in my workflow isn’t enough. Works for common, expected values is not enough. Include tests like tap_scepter_on_arc_reactor_results_in_mindless_minion. Preferably, you’ll consider edge cases and add the tests before they’re ever a problem. If not, at least add the test when you’re fixing the bug.

Performance Problems

I'm stretching a little bit here because the context of this quip was quite different than what I'm discussing. I won't spoil the joke here, so let's just talk about code.

Treat performance as a feature. Half-second delays actually matter. Set standards for yourself, and then measure and work toward them from day one. If you notice problems later on, know how to use tools like .NET Memory Profiler and WCAT to accurately measure and analyze the problem.

We do need to be careful not to take this too far. Premature optimization, complicating matters for trivial gain (or sometimes no gain at all), can be just as bad (or worse). That is not an excuse to turn a blind eye to performance.

Work From Points of Truth

Sometimes you dive at your opponent, sure you've got him right where you want him, and he's just not there. You end up diving through thin air into a trap, then falling hopelessly from the sky.

Don’t do that. I’ve been planning a separate post on this point alone, but it hasn’t materialized. Too many times I’ve seen developers chase a problem for hours only to realize they’ve been attacking an illusion. Always remember to ask yourself “why” until you get to a root cause, and prove every assumption you’re making.

Skip the Spinning Rims

When JARVIS tells Tony that the Mark 7 isn't ready for deployment, Tony tells him to skip the spinning rims. Time is up, it's time to roll out!

Oh, if we’d all think this way, what wonders we might see. I’ve known a lot of great ideas die without ever seeing the light of day because they just weren’t perfect enough. “DEPLOY!" says Iron Man. If there’s a need to fill, get something out there. It doesn’t need to have every flashy affordance you can imagine right away. You can enhance, tweak, and iterate later.

Team Cohesion

As Coulson dies, he tells Fury that the Avengers Initiative never would have worked anyway because they had nothing to ... then he dies. I can think of several ways to finish the sentence, but the point is that team cohesion doesn't just happen.

I’ve worked on products I was excited about, and I’ve worked on products that I felt were going down the tubes. I’ve contributed to the core of products from their beginnings, and I’ve worked on products that were decades old before I touched them. I’ve led teams in both situations.

In my experience, teams of happy, excited developers who can be proud of their accomplishments tend to create more compelling results. This isn’t to say that the unhappy, bored developers won’t get their jobs done. I’ve trudged through plenty of uninspiring projects. Just keep in mind that getting the job done is kind of like the bare minimum, and the resulting product probably won’t be wearing much flair.

Also, a sense of ownership goes a long way. It’s hard to get motivated about a product you just don’t care about. On the other hand, if you feel like it’s your baby…well, you take care of it like it’s your baby.

Why Should I Take Orders From You?

When Captain America tells some of the city's finest to evacuate people, create a perimeter, etc., one asks "Why should I take orders from you?" Just then, Captain executes a brilliant defense and counter-attack against an incoming swarm of hostiles. He doesn't need to give any more answer than that - the officer turns and starts delegating the very orders he received.

More competent leaders are more likely to be followed, as are leaders who get down in the trenches and fight beside you. If you’re leading a team of developers, you need to stay on top of new technologies - especially those that your team shows interest in. Buried under paperwork and meetings? At least find time to go through some “Hello World” tutorials and gain a basic vocabulary for discussions.

Good leaders also know how to delegate. As implied above, added responsibilities will start to siphon off your time from taking deep dives into every new technology. You can, however, learn the levels of your team and trust them to properly evaluate new options. You can also use your own power to keep the hostiles off their backs and give them time to do a good job.


As a laundry list of orders gets delivered to each member of the team, it ends with, "and Hulk? ... Smash!"

Good leaders know that each team members will have their own unique strengths and weaknesses. Some have a great eye for detail, some just hack in a blind rage. Know what each member of your team is capable of, and enable them to succeed by tailoring tasks to their strengths.

We can also take from this the lesson to communicate on the audience’s level. I learned this as a tutor and have had to carry it through my career as I mentor, consult, or give presentations. This doesn’t just apply to teaching or presenting - this should be in the back of your mind during any team communication.

Go To Lunch

If you wait until the very end of the credits, you'll see The Avengers sitting around a table grabbing a meal.

Some say it’s awesome to have lunch with your team every day. I don’t go that far, but I do think it’s important to get to know your team away from the code. You may not want to hang out with them every weekend, but at least find out if they prefer sports or sci-fi, Star Wars or Star Trek, etc. You’ll be spending too much time with these people to have it be strictly business, and you’ll enjoy your work a lot more if you can have pleasant conversation during downtime.

Take A Day

Speaking of downtime...

When it’s all over, Stark suggests that they not come in tomorrow, take a day, relax, go get some Shawarma…

Yes! This! When that emergency or crunch does come and your team kills themselves to get it taken care of, reward the effort with some well deserved recovery time! There really isn’t much else to say here. If you agree, I’m preaching to the choir. If you don’t, I doubt anything I’d say in this kind of thrown-together, brief post will change your mind.

TL;DR, Summary

Comic book movies are getting better. Development and team leadership is fun. Sometimes messages overlap.

This post originally appeared on The DevStop.