How a Military Mindset Can Shape a Successful Programming Career
Members of the military have a certain mindset, one that is drilled into them during their service. Soldiers are taught to work in a team, take the initiative, and prepare in a certain way.
Computer programmers have a certain mindset, too. They need to be detail-oriented and focused on their project.
Now, you may have a mental image or stigma when you hear “Soldier” or “computer programmer.” These words may prompt a stereotypical idea of who these people are, and most folks aren’t going to boil down these two images to the point where they see the similarities.
Having been both a Soldier and a computer programmer, I can tell you that these two jobs have more in common than most people think. For my fellow programmers, using a military mindset can help you succeed. Let me tell you how to develop the right military mindset to shape your programming career.
Military Core Beliefs Applied to Computer Programming
What are the first three words or phrases that you associate with a Soldier? Maybe tough, honor, and follows orders?
Now, I’m not going to tell you that you’re completely wrong; these three terms do hold weight. But there is much more to being a Soldier, and many of the principles that are ingrained into members of the military are useful for programmers as well.
As a Soldier, one of the first principles ingrained in us is that “no one is going to win the battle or war single-handedly,” so where you spot one of us, there are bound to be more. Teamwork at every level and echelon is needed for any level of success.
The second principle ground into us is attention to detail. In fact, these two principles are usually taught to us literally seconds apart from one another, and generally accompanied by doing the “front-leaning rest,” or in common terminology: the push-up position.
For the smallest infraction, Soldiers are placed into the front-leaning rest position. The up position is accompanied by the chanting of “TEAMWORK IS KEY!” and “ATTENTION TO DETAIL” when in the down position.
Now, I am not saying that whenever a Soldier makes a mistake in the real world, you’ll see them immediately drop and give 50 while screaming these phrases, but it is a solid way to engrave something into someone’s mindset.
An industry like computer programming requires the same kind of teamwork and attention to detail. And just like in the military, these two qualities often go hand in hand.
Attention to detail as a programmer means that we painstakingly go through every line. This kind of thoroughness pays great dividends, ensuring your lines of code are all in a specific order, “dress-right-dress,” with all lines of code indented along with correct syntax so that everyone on your team is able to interpret the code easily.
Soldiers also get used to doing things over and over, and using lots of self-discipline to master a tool or technique.
In the Army, we are given many different weapon systems in which to become proficient, meaning being able to take them apart and put them back together, clear them, do function checks, perform maintenance, and of course, qualify with each and every one of them. I was not able to do these tasks with just a once-over.
As for computer programming skills, we also have different systems and languages to master, but there’s a simple recipe to be successful. It’s just one word (well, actually three): Repetition, repetition, and repetition! The difficult part is being disciplined; doing something once doesn’t equate to being proficient.
I imagine each programming language or framework as a different type of weapon system. You can learn that language or framework, but it takes discipline.
You are not going to be able to learn a new tool or technique just by doing one module of training or by taking just one class. You have to be able and willing to repeatedly do exercises and side projects in order to master new languages or frameworks. It’s important to continue to learn and practice.
As a programmer, if you learn and use these principles, you will succeed in your work mission.
One policy that helps the U.S. military to outshine that of many other countries is intent-based guidance. That is, every task is expressed as a clear intent that all levels of leadership understand, plus there is a trust and expectation that subordinates will be able to accomplish the task without any additional guidance. This system not only creates effective, decisive Soldiers, but also provides them with skills that transfer into civilian life and careers, including computer programming.
The main thing this system does is teach Soldiers how to take initiative. Programmers should develop this characteristic, too. Taking initiative in your work will make you a better programmer and make your team stronger.
Here is an example: There is a building that needs to be cleared of all hostiles. We know our end goal and what we need to do to make that happen. So we flow our tasks like this: Cordon off and clear the building to destroy enemy elements within and prevent any from escaping.
It may break down to team Alpha securing the building (no one in, no one out), team Bravo clearing the entire first floor, and team Charlie ready to follow Bravo and clear the second floor.
If there are more levels, we need to find a way to complete the task. Would it be easier for team Charlie to continue to the next floor or have Bravo leapfrog? Subordinate leaders understand they have the authority to make these tactical decisions. The leader and their Soldiers can weigh the options and risks, then execute as it makes sense based on how the mission goes and any other variables that arise.
This type of action is initiative—everyone knows what the intent is and what the end state needs to be, SO LET’S MAKE IT HAPPEN!
So, if you were to apply this idea to programming, it would look like this: Team Alpha is in charge of the design and flow, team Bravo is in charge of the back-end, team Charlie is in charge of outliers, and so on. You all know the final goal—to create the program—so you can take the initiative to make decisions about lower-level tasks as they happen. Each team works together to weigh the options and risks, then make the tactical decisions that make sense in the moment.
If you have a military veteran working for you or with you, this point is where you’ll notice they truly shine. We are unafraid to make a decision, either right or wrong. Doing something is usually better than being too afraid to do anything, as long as we know what the end goal is.
Taking initiative is also a unique approach to leadership and teamwork, and is something that all developers should try to take on in order to be successful.
Planning, Preparation, and Performance
Soldiers keep to a saying called the seven Ps: Prior Proper Planning Prevents Piss Poor Performance. This saying can be simplified into three core ideas: Planning, Preparation, and Performance.
Part of planning also comes down to keeping in mind the one-third/two-thirds rule: You should spend only a third of your time planning so that you can devote two-thirds of the time to execution. This timeline may seem strange to most, but it makes no sense to spend two-thirds of the time developing the “perfect plan” just to give yourself or your team only a third of the remaining time to prepare and perform.
While these ideas are extremely important while plan-developing in the military, I believe they are just as important in the programming world. Following the seven Ps and utilizing the one-third/two-thirds rule will make you stand out, succeed, and continually be able to deliver value to your employer/clients or make you stand out during an interview.
Planning in the military is vastly important, but what’s even more crucial is time. So, in order to compound on both planning and our time, we develop several plans, called Courses of Action (COAs).
We divide up our planning teams so that we are able to produce at least two to three different COAs. Each of the COAs are just different ways to accomplish the same mission. Our “planning phase” will be complete once we conduct what we call a Combined Arms Rehearsal (CAR)—another giant walk-through of the plans.
From a programmer’s perspective, this action is the equivalent of getting everyone involved that has a role to play and go phase by phase of your project—who is doing what, at what time or event, so that everyone knows what each other is thinking or doing. This process will build a strong situational awareness of the project.
Situational awareness could look like the following scenario: The front-end developers are developing an input forum, so back-end developers need to have a place for those input forums to be stored, while designers have worked with the client vision and have chosen a specific font and color scheme, so front-end developers know what to present.
A Soldier is also trained to do something called backward planning. By doing so, we also create a timeline with major milestones along the way. For Soldiers, this timeline helps us with knowing what to be prepared for or what to expect for upcoming training and rehearsals. For example, if we are going to conduct a night live-fire exercise, prior to that we need to ensure that our optics are zeroed and adjusted for nighttime operations.
For programmers, backward planning is going to help us prepare the same way. For example, if we are going to make a launch page for a client, prior to that we may want to zero in on what the client’s company history is or what their intentions are, so that while programming the page we have a good idea on what keywords should be in their application programming interface.
In timeline form, this kind of plan might look something like this: Today’s date is November 1 and the due date for release is December 23. If we plan backward, the app is due on December 23, so we should have a complete product on December 15. December 10 should be the beginning of final testing, December 1 should be debugging, November 20 is when the app needs to be produced for initial testing, November 10 should have a final design template, November 5 needs to be pitching ideas of the app, and that brings us back to November 1. We now have a timeline with major milestones.
A mock trial of a really important event is a great way to prepare. It forces us to prove that we know our material through and through.
In the military, I have to prove my worth through what’s called a board to receive a promotion. Imagine me in my dress uniform, with every ribbon, badge, stripe, and nameplate measured with exact precision, while being grilled by a panel of five senior leaders to prove my knowledge and comprehension. Oh, and doing this while also competing against my peers who are up for promotion as well.
Honestly, it is a nerve-wracking experience. Soldiers conduct mock boards over and over again for practice so that we can keep our composure when the real thing happens. We drill every question the panel may throw our way—the good, the bad, and the ugly. We drill this event to the point where it is all just a reflex or a second nature atmosphere when we get to the real thing.
I use this same mindset when trying to learn a new framework or systems. Understanding a framework on this level is something that each of us should aspire to. I want to get to the point where I know my framework through and through, forward and backward, to where if I had a panel of five senior leaders in front of me, I would be able to beat them in stump-the-chump.
You will usually see Soldiers about 15 minutes prior to the interview, because to us “Early is on time, and on time is late.” Being punctual is a great first impression that demonstrates your professionalism and it is also going to allow you to adjust to any last-minute changes.
At all times during the board, we are professional; that means making eye contact with those we are speaking to, and a lot of “yes sirs,” and “ma’ams.” While talking, we keep two acronyms in our head, BLUF, or Bottom Line Up Front (meaning don’t ramble on and get to the point), and KISS, or Keep It Simple, Stupid (meaning the best way to do something is usually the simplest way).
Following these acronyms also helps us avoid any confusion while communicating with the civilian population, since they are unlikely to understand military jargon.
For programmers, BLUF and KISS are important to keep in mind; we may be speaking with a client who does not know all the latest terms and lingo that we use. So speaking in a clear and understandable way will help you perform at the highest level.
Your performance is how you’re going to make yourself or your company develop revenue, so keep these ideas in mind to be a top performer.
To bring all of the seven Ps together, if you’re producing piss poor products, you might want to look back and see how your planning process went. If you had the “Perfect Plan,” you might want to audit your timeline; did you leave yourself with enough time to prepare?
Building a Team of Programming Soldiers
If you’ve got a military person on your team, look at how they work. When they’re starting a new project, they probably spend the first few days determining who their team is, who they report to, how leadership functions, and what their intent is. Once they know that, their goal is to figure how best to support the mission and the team.
You, too, can find this daily “battle rhythm.” Having an understanding of the work patterns will make you feel more comfortable, because knowledge is power.
A Soldier’s maxim is “plan for the best, but prepare for the worst.” And remember that Murphy (as in Murphy’s Law) always gets a say.
Programmers, like Soldiers, can use these characteristics for mission success. Any developer needs to work with a team, practice new skills, and show determination. They also need to use critical thinking and show initiative, plus focus on planning, preparation, and performance.
Practicing a military mindset can help you succeed in your programming career, and achieve mission success on a daily basis. And since we’re all working to achieve success, the right mindset makes all the difference.