SPOILER FREE: A Lesson We Should Take From Captain America: Civil War

As of writing this post, I have not seen the upcoming Marvel Studios movie, Captain America: Civil War. I will, however, be seeing it very soon.

I love what Marvel has done with the MCU (Marvel Cinematic Universe). This continuing storyline of movies over the past 8 years or so has been quite a fantastic ride and it is also a ride that doesn’t seem to be coming to an end any time soon. It has been very exciting seeing the characters grow, and I am super excited about Spider-Man joining the fray.

My excitement for the upcoming movie got me thinking about, as a leader in an organization, what lessons should I take from Captain America: Civil War based on what I know about the movie today?  The short synopsis for the movie is that the superheroes are divided against each other on whether to accept government regulation or should they continue to act as vigilantes. In a movie twist, Team Captain America is against government regulation and Team Iron Man is in favor of regulation. This is kind of the opposite of how the characters have acted up until now in the MCU. Iron Man/Tony Stark has been a symbol for flipping the bird against the government and acting however he pleases. In Iron Man 2 he claims to have privatised world peace and in The Avengers: Age of Ultron he creates the robot Ultron using alien technology, who ends up terrorizing the world. Captain America is a product of the military and has always put his nation above his own relationships, desires and existence and would never seem to be someone who would stand in the way of a governmental regulation.  However, maybe this isn’t that farfetched as Cap has seen government organizations corrupt all around him in his dealings with both S.H.I.E.L.D. and Hydra.

In some ways, being a leader in an organization is akin to Team Iron Man and accepting regulation. This could come in the form of a boss’s directives, company rules, government regulations, board decisions, stockholder decisions, or your peers thoughts. Rules and regulations protect us in many ways. I guess you could say, in some ways being a good leader is being a good follower. The first thing that comes to mind is information security. We can’t be reckless with information security. It’s not the right thing to do. Our corporations and their partners and clients depend on us to make sure we have things under lock and key and are following industry standards to make sure of it. This is a prime example where paving your way just doesn’t make sense. Another way might be with spending. When operating under a budget, it is our responsibility to make that budget work because the rest of the organization is counting on us to do so. Sometimes we need to check our ego at the door and realize that everything we do is not always going to be about coming in with guns a blazing.

As fun as being a follower is, being a leader is also a lot like Team Cap and continuing to be a vigilante, and fighting for truth, justice and the American way, right? Part of being a leader is most definitely being a pioneer, and paving new roads. Innovation is a huge part of being a technology leader. We need to think and rethink what it means to do whatever it is we do, and constantly reinvent ourselves from a technological standpoint. Technology is moving at such a rapid pace, if we become content with a certain pattern, practice, or technology, we already are behind our competition.

I have always related my role as a leader as someone who walks a tightrope between the sides of chaos and order. Perhaps, this tightrope is not only where I belong as a technology leader, but ultimately where we find both Team Cap and Team Iron Man at the end of their movie? Those of us heading out to the theaters this week will find out soon enough, but until then, can we agree that both Team Captain America and Team Iron Man are quite possibly both correct? There is a time and a place for everything. Sometimes it is best to follow in line and follow your marching orders to a tee, and other times it’s best to stand on your own even if that means there might be consequences. After all, you can’t make an omelette without breaking a couple of eggs, right?

Just for the record, going into the movie, I’m #TeamIronMan

*********** UPDATE – 5/6/2016 ***********

I saw the movie last night, and I think my take on the movie before watching it was a good one, but there are so many more lessons to take from the movie. I’ll have to write about more of these in the future, but I’m keeping it spoiler free for now. Go out and see the movie!  It’s a really good movie with really good character usage and I enjoyed the villain and his master plan. All of the new characters are great! I’m a huge Spider-Man fan, and the new one is excellent. I am so excited to see Spider-Man Homecoming next year!

Keep it Simple

When writing software, one of the things I preach to developers is to keep things simple. As engineers and architects we sometimes turn off our common sense in favor of trying to solve all business problems at once. We forget that the first problem we have to solve is the one at hand and not the rest of this project, next project, the bugs from those projects that could arise and the thing that might be cool or catastrophic if we go down some road in three years.

An example might be that a client asks for a modification to an existing form measuring satisfaction. Your client wants to capture a checkbox of whether the person submitting the form wants to be contacted in the future. The checkbox being checked means they do want to be contacted and unchecked means they do not.

This is a simple request and should require a simple solution. However, something as simple as this can and is often overdone. Instead of piggybacking the existing form we could post back the state of the checkbox using AJAX as soon as it changes to have the most accurate state possible. Is the default value checked or unchecked? What if we disabled the checkbox via CSS and JavaScript until we had other fields filled out? What if we only displayed the checkbox once that portion of the screen is visible? What about how this checkbox will work in multiple browsers or devices? What do we do after we capture the state? Should we notify the person submitting the form? Should we notify our client that someone submitted the form? Don’t even bring up unit tests, integration tests and acceptance tests. The questions and scenarios are endless.

In this moment, it’s best to go back to what was originally requested. Add a checkbox to a form. That’s it. Keep it simple. Start with simple.

Our job is challenging. We have to understand the best way to deliver value and yet not under or over deliver. Take the example of the checkbox, what if the client did want more from the checkbox and didn’t know to ask? It is also our job to ask the right questions. Often, our clients know only a narrow view of what they want because they don’t understand what is possible or don’t understand the scenarios that can occur from the development they are requesting. It is our job to keep ourselves in check to keep it simple as well as keep our clients on the path they truly want to go down.

We are not tasked with an easy job, but when we truly focus on keeping it simple and delivering value we will keep projects running smoothly and delivering bang for our client’s buck. Remember to start with simple, ask the right questions, and deliver time and time again.

Congratulations on Your Failure

On my desk I have a placard that says:

Failure is an opportunity to intelligently begin again

This is one of the principles I have built my career on. I’m certain that I have failed and lived tell about it many more times than I have celebrated sweet success.

First, it’s important to recognize that failure is okay as long as you learn something from it. Failing without learning is like paying for dinner at a fine restaurant and sending your plate back to the kitchen without eating. It’s expensive, and you miss out on the good stuff. The truth is that failing at anything can teach you lessons you just can’t get in any other way.

There is a mantra in start up companies to fail fast and fail often. This iterative idea is prevalent in business today. Agile methodology reinforces this concept and it has proven, that when applied correctly, it will get a business not only from point A to point B faster, but often point B is not the original point B envisioned, but an exponentially better one. Gradual iterations provide for more opportunities to fail and therefore more opportunities to learn, solve new problems, confirm or deny assumptions, and improve.

I have always encouraged my employees to try things and see if they work. I teach them to embrace failure and avoid paralysis by analysis.  They should not fear the unknown, but rather be excited to the possibilities that lie ahead. These concepts are not in our nature as human beings. We have primal instincts to survive and we are in conflict with this by embracing failure.

Learning from failure is such a powerful tool for us in IT. We have such a unique landscape of tools and technologies. We build and can rebuild using Agile principles and be more agile and swift than other industries. It is imperative we indeed fail, learn from failure and repeat until we get a desired outcome. I promise, if you focus on this moment in time, this single problem, and actually learn as you go, the end result will be better than you could have ever imagined in the first place.

Computing is Problem Solving

I started out my career as a software developer, but well before that I learned some valuable lessons about what it would take to build a career in computers.

When I was 10 years old my grandmother passed away. She didn’t have a lot of money, but she loved her grandson enough to leave him two gifts. First, she left enough money for me to get to go to Disney World, because all kids should get to experience that place. Second, she left me the money to get a home computer. At that time, in the 1980’s, home computing wasn’t that common, but becoming more and more common every day.

My first computer was an Epson Equity I+ with a 5.25″ floppy disk drive, an EGA monitor, and a Panasonic dot matrix printer.  I am still kicking myself for throwing it out.  I have fond memories of my time learning on that computer.

When we got the computer unboxed and setup in a spare bedroom at our house, I remember the anticipation of what I would see. My computing experience before this was a TI-99 that my cousins and I got one year in the early 80’s that I promptly disassembled, the Atari 2600 that a friend had and the Nintendo Entertainment System that I schooled everyone on as a kid. Maybe I didn’t really school everyone on the NES, but let me have my moment. Back to my first boot. After hitting the power button, I was expecting some graphics, music, a game perhaps. What did I see?  I saw the screen flip numbers up to say 640K of RAM and then some grinding sounds and a chirp, then finally a blinking cursor at a C:\ prompt.  I didn’t know what that meant, but I knew I had work to do.

Along with my home computing system were three fat books on spiral binders. The first was how to hook up the actual hardware and information about the hardware itself. I threw that to the side, because we fumbled through that already. The second was a book about MS DOS 3.0. I thought to myself, “This might come in handy,” and set it in front of me. Finally, there was a book on programming my new computer with GW BASIC. I thought something to the effect of, “This is it!  I can actually build video games!”

I spent the next four years or so hammering away at that computer. As friends got 286, 386 and 486 computers. I still had fun making things work on my 8088 processor architecture. I built scripts to make home computing easier, and to display boot menus and such. I tinkered with simple game design. I taught the computer to make noises, play sounds and even stumble through some bad computer beep music. I built ASCII character graphics into art and learned a drawing library that taught me how to draw circles, squares, rectangles, lines and more in all 64 colors my EGA monitor could display. I built routines to print amazing HAPPY BIRTHDAY banners in many varieties of fonts, including some homegrown fonts. I acquired a modem and made my computer talk over the telephone line to my cousin’s computer just because the anticipation of waiting on the response to “Hello” was so darn thrilling. I remember getting a mouse and installing the drivers and building my first program that could accept a click.

My first computer taught me the most important lesson in my career. It isn’t the hardware you have or don’t have. It isn’t the computer programming language you choose. It isn’t the skills you possess now or the mountains of practice and research to possess new ones. Computing is simply about a can-do attitude and a relentless desire to solve the problem at hand.

As IT professionals, we are tasked with making the impossible become possible. We are tasked with building something that has never been built before. This is often on a budget and equipment and tools that are lacking in more ways than the blinking C:\ prompt I saw when I booted my first PC.

Arthur C. Clarke created three laws in the essay “Hazards of Prophecy: The Failure of Imagination”:

  • When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
  • The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
  • Any sufficiently advanced technology is indistinguishable from magic.

I agree, especially with the last one. I think the way I describe it is that as an IT professional it is our job and our privilege to turn fantasy into reality, fiction to fact, nothing to something, and solve problems with unbounded enthusiasm and reckless abandon.

Hello World!

Hello World!

I come from a background in IT, so “Hello World!” programs are quite common as the opening act to a career in scripting and software.  I have written those programs in many languages and at many times during my 30+ years of tinkering with computers and 15+ year IT career serving as everything from a Software Developer/Engineer/Architect to Database/Systems/Network Administrator to Data Analyst/Scientist to Chief Technology Officer and currently Chief Innovation Officer.

This is not my first attempt at a blog.  My first and second attempts at blogging were sporadic at best.  The truth is that I typically opted for career development and social life over sharing.  I never had clear focus on what to blog about.  I have so many interests, I felt I wanted to share on all of them.  This was no way to find consistency.

Here, I hope my third time is truly a charm, and I am able to build content that you find appealing as a reader.  If you’ll have me, I want to help you and share with you.  I can use my interests as compliments to the story, rather than the entire story.  I have found over the years that I enjoy teaching and mentoring more than anything.  This is where I truly find reward, and I hope you’ll join me on this journey where I lay it out there to help you be the best you truly can be and maybe I’ll become the best I can truly be in the process as well.

Until next time, copy and paste the code below into notepad.  Save with a .html extension instead of .txt and open the file in your browser of choice.

<script>
alert("Hello World!");
</script>