Would you pair program with Stan Lee?

Ever wonder what it would be like if Stan Lee joined your engineering team? Well, I do.

Back in 1978, Stan Lee and John Buscema (both comic legends) wrote a book about "How to Draw Comics the Marvel Way" where they emphasize simpler is better. Sound familiar?

So what is simpler? What is better? Stan Lee says, "A work of art must have a magical ingredient of correct composition." He continues, artists must "compose something that is both pleasing to the eye and gets the message across clearly and interestingly." We've all seen and can identify code that is unpleasing to the eye. And I'm sure most of us can also identify code that clearly states it's intent. So far Stan Lee is preaching to the choir.

How does the man, the myth, the legend suggest we accomplish composing something that is both pleasing and gets it's message across? He says there is one main rule, "the simpler, the better." I agree, simpler is better. But how do we know it's simple?

In the book, Stan and John describe how important elements are grouped together to form prime shapes. These prime shapes should give viewers the best possible shot of the action. They also group together important elements and make it easy for the viewer to understand what is happening. Artists should also never squeeze elements into a prime shape and should remove important areas that fall outside of the prime area. Sounds to me like Stan and John are suggesting good object composition.

Stan Lee states that artists "sense" good composition and sketch in prime shapes before drawing the detail. Much like an engineer would use BDD to specify the outermost behavior and then work their way in. Good panel composition as well as good object composition leads the reader's eye and conveys an interesting message.

And sometimes after shapes are identified and the picture is drawn, too many important elements fall outside the basic shaded area and  the panel needs to be redrawn. I believe us engineers call that refactoring :)






But what if my objects don't have a simpler form or fit into nice prime shapes? Then change the camera angle!  For example, here we have Jonah Jameson yelling at Peter Parker on the phone.

Sure it shows what is happening, but look at how much better the second drawing delivers the message. It's extremely clear what is happening and all that changed was the camera angle.

But there are no cameras in code you say. You are correct, but there are different ways to look at solving a problem. Sometimes it requires deleting code, walking away, and revisiting the problem, but there is always another way. It takes practice, creativity, and a good pair always helps. Even explaining the problem to somebody else can help you see and understand a new way of approaching the problem.


To emphasize the point further, which figure more clearly demonstrates what is happening? A or B?

While A does show the viewer our hero is blasting a foe with a laser blast from his eyes, B does the same thing much more clearly and interestingly. Everything in B demonstrates intense action. There are elements in A that suggest that maybe certain components aren't needed. A also makes our hero look weak and somewhat unsure. When it comes to stating intent clearly I tend to refer back to three things, Avdi Grimm's Confident Ruby, Object Thinking by David West, and Tell Don't Ask. Each of them reinforce the importance of your objects communicating clearly what they do, just like B demonstrates that our hero's entire body is involved in emanating a laser blast from his eyes with confidence!

While Stan Lee may not have experience writing code, he sure has a firm grasp on telling a good story in a way that is clear and interesting to the reader. So yes, I'd love to sit down and craft amazing adventures in code with Stan Lee! As software craftsman, isn't that what we do everyday? We craft code. Code that tells a story. And while the story arc may vary, they are all still stories. Let's all put a little more amazing into our stories the MARVEL way!

Coach taught, player learned

Earlier today there was an email exchange amongst the Enginerds at Usertesting about pairing on deploys. Part of the exchange reminded of an article I had recently read by John Kessel. John Kessel is the Director of Beach Volleyball, Education and Grassroots Programs as well as one of the most sought after lecturers by coaches world wide. He is also somebody who has a direct positive impact on my own coaching philosophy. (For those who aren't aware, I coach High School and 12U Boys Volleyball and have found it highly relevant to what I do day to day on a software engineering team as a Team Lead)

So this article, "Coach taught, or player learned" (link below), highlights 5 things John has learned about learning:

1. Athletes learn when they are SELF-motivated; intrinsic learning and guided discovery are vastly superior for retention/learning.
2. The reward of athletes is achieving the goal, so take advantage of that in your teaching process.
3. Deliberate practice, aka focused on what THEY are interested in, maximizes the learning process.
4. Coopetition, cooperation and competition, makes for the best learning by athletes. We learn best, and the most, when we collaborate with others.
5. That which you teach, you learn. The more athletes have to explain something to others, the better they get it.

It was thing #5 that I related to the earlier email exchange, "That which you teach, you learn. The more athletes have to explain something to others, the better they get it." I think the "explain something to others" is and should be an important part of our teams culture. It's why when Suan Yeo suggests pairing with somebody familiar with code to pair on deploys, I think "Maybe not. Maybe they should pair with somebody who doesn't know the code on deploys".

Sometimes as developers we make assumptions  (we are only human :) ) . And often times those assumptions are incorrect. It's through explaining something to somebody else that we realize fallacies in our reasoning. And through that explanation we learn and grow as a team.

With that said, I would encourage everyone to take the time to explain the Why, the How, the What to somebody else unfamiliar to not only learn yourself, but to also teach others.

I highly recommend reading this article when you have 10-15 minutes and are looking to further your understanding of learning: http://www.teamusa.org/USA-Volleyball/Features/2015/January/23/Coach-Taught-or-Player-Learned

Special thanks to Paul Hepworth for asking me to explain my understanding to him, thus ironing out assumptions I had made about our environments and leading to further learning.