The mental image you have in your mind of a Computer Science major and an Army Officer are probably very different. I've done both, and you're probably right. A Computer Science degree relates more than you would think.
The one class that was the least tangible was Software Engineering. This class proved to be the one that related to my time as an officer the most. Project development fundamentals were applied every day. The term "layers of complexity" is commonly brought up when developing software and sorting through abstraction. It is a core structure to the hierarchical organization of the Army.
Field Manual 1-02 even establishes how to graphically represent these various levels and the actions they can perform with symbols, the military's own version of UML.
Working in Operations Development and abiding by extensive manuals was a bit daunting. Doing things the sensible way and doing things the doctrine way were often very different. Efficient personnel knew this, but doctrine wins out.
Executing an Operations Order is rarely difficult. Writing one that is easy to understand is not difficult. Writing one that specifies all the details can be incredibly difficult. Re-using old portions of well written op-orders was an encourages practice or even mandatory. While writing op-orders I had to realize that I could take nothing for granted. I had to cast units to fit the form of other units, had to use temporary names, and even conditionals. The ideas of code re-use and other software engineering principles applied regularly.
Promotion focused people tended to use fear driven development. I had plenty of examples how to not manage projects, but still a few that were thankfully on the other end of the spectrum.
A Computer Science degree involves a lot of data science. The skill most noticeable to my coworkers and most appreciated by my superiors was my ability to organize information and develop systems to process information. Building a spreadsheet to monitor 273 personnel through 13 different gates that could be filled out with check boxes and would note any outliers and give a rollup of the progress of the 6-sub units? Took a few hours. Automatically generating a schedule to put 21 squads though 19 different stations over a 3 day period and color coded? Have to use a recent version of Excel, but it was doable.
In the process of distributing information I did educate my units on the terms border cases, special cases, and layers of abstraction. They are hugely important to handling various data, but rarely discussed outside Software Engineering. I cracked a smile every time I heard those terms used after I introduced them.
Using software in the military was generally teeth grinding. Software was not developed to be easy to use or learn, but instead to fill a list of requirements. The software ended up suffering from feature creep. Finding my own HR related details on AKO required a dozen or more steps and logins to other sites that were supposed to be integrated. AFATDS required manuals thicker than any language or compiler that I've ever came across. Although working with software that could put 100 lbs of explosives 30 miles away that was precise enough to account for variations in gravity was pretty cool.
The one class that was the least tangible was Software Engineering. This class proved to be the one that related to my time as an officer the most. Project development fundamentals were applied every day. The term "layers of complexity" is commonly brought up when developing software and sorting through abstraction. It is a core structure to the hierarchical organization of the Army.
- Colonel - Ensures that their 2100 personnel are fully trained over a two year period
- Lieutenant Colonel - Ensures that their 700 personnel are trained over a one year period
- Major - Ensures that all the training areas and equipment is on hand to conduct training
- Captain - Ensures their 120 personnel are trained over the 90 day training period
- Lieutenant - Ensures their 30 personnel are trained over a two week training period
- Sergeant - Ensures their personnel are present for that day's training
Field Manual 1-02 even establishes how to graphically represent these various levels and the actions they can perform with symbols, the military's own version of UML.
Working in Operations Development and abiding by extensive manuals was a bit daunting. Doing things the sensible way and doing things the doctrine way were often very different. Efficient personnel knew this, but doctrine wins out.
Executing an Operations Order is rarely difficult. Writing one that is easy to understand is not difficult. Writing one that specifies all the details can be incredibly difficult. Re-using old portions of well written op-orders was an encourages practice or even mandatory. While writing op-orders I had to realize that I could take nothing for granted. I had to cast units to fit the form of other units, had to use temporary names, and even conditionals. The ideas of code re-use and other software engineering principles applied regularly.
Promotion focused people tended to use fear driven development. I had plenty of examples how to not manage projects, but still a few that were thankfully on the other end of the spectrum.
A Computer Science degree involves a lot of data science. The skill most noticeable to my coworkers and most appreciated by my superiors was my ability to organize information and develop systems to process information. Building a spreadsheet to monitor 273 personnel through 13 different gates that could be filled out with check boxes and would note any outliers and give a rollup of the progress of the 6-sub units? Took a few hours. Automatically generating a schedule to put 21 squads though 19 different stations over a 3 day period and color coded? Have to use a recent version of Excel, but it was doable.
In the process of distributing information I did educate my units on the terms border cases, special cases, and layers of abstraction. They are hugely important to handling various data, but rarely discussed outside Software Engineering. I cracked a smile every time I heard those terms used after I introduced them.
Using software in the military was generally teeth grinding. Software was not developed to be easy to use or learn, but instead to fill a list of requirements. The software ended up suffering from feature creep. Finding my own HR related details on AKO required a dozen or more steps and logins to other sites that were supposed to be integrated. AFATDS required manuals thicker than any language or compiler that I've ever came across. Although working with software that could put 100 lbs of explosives 30 miles away that was precise enough to account for variations in gravity was pretty cool.
No comments:
Post a Comment