Keep calm and BOHICA: Military acronyms applied to software development
In my newest role in Vets Who Code, I’ve been tasked with guiding and motivating our applicants with completing their pre-work; small reading and rudimentary coding assignments to give us an indication of how serious the applicant is to complete the program. As we’re an all-volunteer organization, this is important, as it allows us to weed out the non-hackers (a phrase, which in this case means one who ‘just can’t hack it’, and not someone who lacks the capabilities of a ‘L33t H@x0r’), and concentrate our energies on those who can. I begin each of my Facebook posts to the group with “Howdy, FNGs!”, and jokingly refer to myself as the ‘Head FNG Wrangler’; FNG being a term familiar to most veterans, but esoteric to those not in the know. We do love us some acronyms in the military, but they often appear to be a second, secret language to civilians. It was in explaining this term to my project lead at NBC that I got the idea for this article, in which I’ll be trying to correlate certain military acronyms to a context relevant to the software development industry. Fittingly, I’ll be starting with ‘FNG’.
(A warning to those with virgin eyes, ya’ll may want to move on to something else right now… it’s long been my stance that veterans have a right to swear anywhere they choose, and that I’m pretty sure it’s one of our official benefits. These are actual military acronyms, and honestly, dirty words are the last thing most folks in the military worry about, choosing instead to concern themselves with not getting shot or blown up, and ensuring that if it’s entirely necessary that someone does need to be shot or blown up, it happens to someone on the other side. At any rate, as someone who swore an oath to uphold the Constitution of the United States and all the freedoms it guarantees, censorship just gives me the red-ass, so I won’t be censoring myself here. Now that that’s out of the way…)
FNG: Fucking New Guy
Yes, an F-bomb in the very first acronym. I wasn’t kidding with that warning. Often also referred to as a ‘boot’ (one who has just graduated basic training, or ‘boot camp’), the FNG is one who knows just enough to be given basic tasks, and can also be trusted, as often as not, to screw up those basic tasks. Most of the time, they have the knowledge, but no actual experience. In military terms, this is someone who needs to be shown the ropes and guided through nearly everything they’re given to do, and on a development team, there isn’t much difference. An FNG on a dev team is a new-hire, and even if that person has ten years of development experience and has been hired for a senior developer position, chances are they’re going to be pretty lost when first getting started. They’ll need to be on-boarded, a term which here means to be given basic knowledge of the day-to-day activities and expectations, given access to work with various systems, and given an overview of the codebase, its inner workings, and idiosyncrasies. (On-boarding, interestingly enough, also has origins in military, specifically naval, tradition, as its original use was more literally applied to the process of acclimating a new sailor to his duties on the crew of a ship.) While the term is somewhat derisive, as in the military, it’s important to remember that an FNG is someone who, once they have proven to be competent, will be a valuable asset to your team. An FNG will often have fresh ideas to bring to the group, and recently-learned knowledge that you may not have had time to get up-to-speed with, so do your best to guide them through the basics and listen when they have questions or suggestions. When you’re the FNG on a team, listen to the senior team-members and do your best to learn all you can as quickly as possible, but be wary of anyone who tells you to just go ahead and commit a library update to master branch. This can lead to our next acronym…
SNAFU: Situation Normal/Nominal, All Fucked Up
This is one that, due to movies and TV, and even if they don’t know the term is actually an acronym, most civilians will have some degree of familiarity. Originating all the way back in WWII, SNAFU refers to a situation where something has gone horribly, horribly wrong. It’s often used to describe when an operation has gone all FUBAR, a term which in this case means ‘Fucked up beyond all recognition’, and is unrelated, as far as I know, to the ‘foo/bar’ terms used in programming tutorials. In the military, this can describe something catastrophic, like walking into an ambush, or something as mundane as trying to maintain normal operations when all your equipment has degraded to the point of uselessness, and you’re unable to get the tools or supplies to carry on in an efficient manner. Again, there are parallels in software development, such as when an FNG introduces a breaking change into a production build. Another, more common example, is when you’re working on a project that’s been around for a good deal of time, and which has legacy code that, for whatever reason, has a bloated, brittle, antiquated and/or unmaintainable codebase, for which your business product team cannot see the value in serious refactoring. Dealing with a SNAFU requires a level head, and an ability to adapt, improvise, and overcome. The important thing is to concentrate on ways to fix the situation, rather than let it devolve into a blame-flinging contest. In the case of the breaking change, determine the origin point of the change, revert to the point directly preceding, cherry-pick anything you need to get the project back up to the point you need it to be, and calmly discuss it in a retro meeting (for my FNGs, a retro meeting is like an AAR (after-action report) for the week or whatever unit of time your team uses to break up your development sprints). For the aging codebase, the solution is a bit more complicated. It’s to your benefit to do some planning and break it down for your business team in terms of value to them… for instance: the spaghetti code that currently exists in your app is hard for developers to navigate through, costing additional man-hours to resolve relatively minor issues that could better be applied to writing new features; when you relate frustrations you’re experiencing as problems which in the end cost the product team more money, they tend to be more amenable to changes you’re likely to suggest. Speaking of planning:
PPPPPP: Proper Planning Prevents Piss-Poor Performance
Ok, so this one is more of a mnemonic than a proper acronym. Po-tay-toe, po-tah-toe. Sue me, if this article hasn’t already been taken down due to my use of profanity. In the military, proper planning can mean the difference between life and death, whether it be mapping out a transit route that won’t place you in the middle of a kill-box, or simply ensuring that you’ll be bringing the proper tools and supplies to maintain your equipment, supply your guns with ammo, and keep your troops from starving. In other words, proper planning will help to avoid SNAFU. In software development, the benefits of proper planning would appear to be self-evident. However, those benefits are often overlooked, in favor of just pushing the latest features out the door to your consumers. While the situations that arise in development from skimping on the planning are not usually as life-threatening as in the military (and if you’re designing military or air-traffic-control software, that statement may well be false), proper planning should not be ignored. Requirements which have been poorly defined are the bane of any software developer tasked to fulfill them, and even after they are adequately defined, it pays off for you, as a developer, to adequately define how you will fulfill them before even writing one line of code. Sit down with a pad and paper and sketch out those control-flow diagrams. Make lists of software libraries of which you may make use, and do some research into the APIs, even if you’ve used them in the past. Look into which design patterns may fit the features you’re trying to implement, and which code-smells and anti-patterns which may arise, so you can do your best to avoid them. If you’ve done your planning well enough, your planning style may even evolve into SOP…
SOP: Standard Operating Procedure
In the Marines, we kept notebooks known as “desktop turnovers”… these were thick binders filled with information that described our day-to-day duties, step-by-step, to ensure that we not only had a reference to utilize to keep us from leaving out any steps, but to also allow any FNG who stepped in to fill our position to do our jobs, as capably as we could. I worked in an armory as a small-arms repair technician, so my turnover described the procedure for keeping proper access and materiel-checkout logs, instructions for proper behavior when standing guard, gauging and calibrating weapons, and conducting daily inventory surveys. It was also SOP to always keep our technical manuals in front of us when repairing and maintaining weapons, as human memory is fallible, and having the instructions out in black-and-white in front of you is the easiest way to avoid making mistakes. On a development project, your SOP will often be defined in a wiki (wiki itself being an acronym for ‘What I Know Is’), and if your project doesn’t have one, start one. NOW. I cannot stress enough how important this kind of detailed documentation can be, even to someone who has worked on their specific project for an extended period of time. This wiki should contain things like lists of software you’ll need to run and develop the project, contribution guidelines, pull-request and peer-review instructions, code-style guidelines, best-practices, code-quality metrics used on the project, and instructions for merging and deploying new code. As for referring to our technical manuals while working, this correlates to keeping API documentation, Stack-Overflow articles, and Google (or your search-engine of choice; I’m a Duck-Duck-Go man, personally) open at all times.
BOHICA: Bend Over, Here It Comes Again
My final term is often nervously uttered by Marines and Soldiers when faced with yet another imminent, unwanted screwing with the proverbial ‘Big Green Weenie’ of their chosen military branch. BOHICA can be utilized to warn others of anything from upcoming police-calls, barracks field-day or ‘health and welfare’ inspections, surprise random urinalysis, or being deployed to a particularly hot theater of war. In software development, BOHICA applies when your business product team tells you that they’ll be speeding up the op-tempo, requesting complicated new features with the potential to break existing features or negatively impact performance, or that they’re planning to conduct performance reviews. A BOHICA moment is usually a precursor to a period of incredible stress, long hours, and general frustration. While BOHICA moments are unavoidable, rather than complaining, remember your training. By following a well-defined SOP and conducting Proper Planning, you’ll be able to avoid SNAFUs and keep your FNGs from panicking, enabling your team to stay on track, and accomplish any mission.
