How I got a medal from the Army for writing code(vivin.net)
vivin.net
How I got a medal from the Army for writing code
http://vivin.net/2014/06/26/how-i-got-a-medal-for-writing-code/
81 comments
My first reaction: "Fuck, we should hire this guy...".
Then I read the commendation, read the name and realize we did hire you as an intern last summer, and I know you. I never knew this story though. Really impressive, man.
Not as life-saving, but a friend of mine got a job for the federal or provincial government in NB, I forgot which.
His job was fairly simple: controlling access to information. Other departments would send him requests for information about certain individuals, and his job was to send them the data that they required, but only that data, to prevent other departments from intentionally or inadvertently accessing the wrong data (and violating privacy laws).
So his day consisted of getting an e-mail with a request for data X about person Y, and then sending them that data. A fairly straightforward task, but when he was hired there was a three-month backlog.
After a week or two, he wrote an application in VB that would access the database directly; he could type in a name, choose a result, select fields, generate a PDF, and e-mail it to a given e-mail address. What used to be a 5-10 minute job became a 30 second job. His three-month backlog turned into a three-month headway. People were getting their results within minutes of sending the request, rather than hours, days, or weeks, and productivity everywhere increased.
At this point, his job consisted of sitting at his desk watching anime on his netbook until a request came in, typing for a few seconds, clicking a button, then watching anime again.
He was bored constantly; he asked his boss for more work, something else to do, automation or paperwork or anything, but his boss refused. Union job, defined role, can't give you more work.
Haven't talked to him in ages. For all I know he's linked his app into Outlook to pre-fill fields by now and he's running a startup out of his office in his eight hours a day of extra spare time.
His job was fairly simple: controlling access to information. Other departments would send him requests for information about certain individuals, and his job was to send them the data that they required, but only that data, to prevent other departments from intentionally or inadvertently accessing the wrong data (and violating privacy laws).
So his day consisted of getting an e-mail with a request for data X about person Y, and then sending them that data. A fairly straightforward task, but when he was hired there was a three-month backlog.
After a week or two, he wrote an application in VB that would access the database directly; he could type in a name, choose a result, select fields, generate a PDF, and e-mail it to a given e-mail address. What used to be a 5-10 minute job became a 30 second job. His three-month backlog turned into a three-month headway. People were getting their results within minutes of sending the request, rather than hours, days, or weeks, and productivity everywhere increased.
At this point, his job consisted of sitting at his desk watching anime on his netbook until a request came in, typing for a few seconds, clicking a button, then watching anime again.
He was bored constantly; he asked his boss for more work, something else to do, automation or paperwork or anything, but his boss refused. Union job, defined role, can't give you more work.
Haven't talked to him in ages. For all I know he's linked his app into Outlook to pre-fill fields by now and he's running a startup out of his office in his eight hours a day of extra spare time.
Amazing work. Imagine if a skilled developer did 2 week rotations in every department.
That is an amazing story, in more ways than one. I am amazed that these tools DIDN'T already exist.
Heck, my brother is commander of the 10th medical wing in the USAF -- I should ask him what tools he thinks they are lacking.
Heck, my brother is commander of the 10th medical wing in the USAF -- I should ask him what tools he thinks they are lacking.
"Being the canadian army, they don't give medals" - could you clarify that?
The Canadian army doesn't give medals as easily as the US does. You'll never see a Canadian soldier with a rack of medals big as the ones you can see on a US soldier.
That's an awesome & inspiring story on so many levels, one that gives me chills to read, is fantastic. Thank you very much for sharing.
Really speaks volumes about how key it is to take the initiative upon yourself to solve problems and advance your own knowledge. Thanks again.
Really speaks volumes about how key it is to take the initiative upon yourself to solve problems and advance your own knowledge. Thanks again.
That's a great story and quite inspiring too! It's great that you took the initiative. That's what the military teaches us to do anyway. I think it's amazing what you did because your improvements had real impact and I'm pretty sure you actually ended up saving lives. Great job.
Battle Captain, right? I know exactly how you must have felt. I did this job as a 1LT in a bunker in Korea with shitty outdated MS Office and I never even thought to write a VBA app.
This sounds like an interesting startup idea: TOC software. It would be easy to write. I wonder how difficult it would be to sell to the Army.
I see from your Github that you, too, write Go. We should talk sometime.
http://github.com/chrissnell
This sounds like an interesting startup idea: TOC software. It would be easy to write. I wonder how difficult it would be to sell to the Army.
I see from your Github that you, too, write Go. We should talk sometime.
http://github.com/chrissnell
Better TOC software would be great (though I haven't been in uniform in almost 6 years). But I remember ASAS and ASAS-L being pretty terrible for what they were.
This the Chris Snell that I know from Bikeworld? 'sup, man?
I'd like to write logistics software for the Army too. I could have replicated the system we were using in probably a month, maybe less.
Sadly, having done this type of work before replacing existing systems with better UI is seen as a waste of resources and Bulding new systems involves rediculus levels of paperwork and changing requirements.
I once worked on a project that spent 7 years in the planning stages and they decided to take a 6 month break from development after the first demo to reevaluate things. Not because the demo had issues, they where not sure if this was the correct approach.
A different project was considered a complete success except we increased productivity to much.
I once worked on a project that spent 7 years in the planning stages and they decided to take a 6 month break from development after the first demo to reevaluate things. Not because the demo had issues, they where not sure if this was the correct approach.
A different project was considered a complete success except we increased productivity to much.
Yup, in the canadian forces, they call it 'Duty Officer', much less glorious sounding than Battle Captain =)
I think the best way to make a difference with software would be as a consultant, deploying with units and doing work straight from there, in an ad-hoc way. Similarly I guess to the stories about how the Obama elections team worked. Deploying a small group of devs with a battle group, who have for purpose to write custom software to make the battle group more efficient. By participating in the pre-deployment training and exercise, the devs could familiarize themselves with the most important tools that need to be created for the deployment. Then while deployed, polish the rough edges and adapt the tools to new situations.
Otherwise, going through the procurement chain of the army will inevitably lead to insanity and bad software, and no actionable result. We had software when I went about writing those tools; it was just so bad and inappropriate that nobody used it.
I think the best way to make a difference with software would be as a consultant, deploying with units and doing work straight from there, in an ad-hoc way. Similarly I guess to the stories about how the Obama elections team worked. Deploying a small group of devs with a battle group, who have for purpose to write custom software to make the battle group more efficient. By participating in the pre-deployment training and exercise, the devs could familiarize themselves with the most important tools that need to be created for the deployment. Then while deployed, polish the rough edges and adapt the tools to new situations.
Otherwise, going through the procurement chain of the army will inevitably lead to insanity and bad software, and no actionable result. We had software when I went about writing those tools; it was just so bad and inappropriate that nobody used it.
The challenge of being a contractor embedded in a unit is that ultimately, someone procured the billet spot for you, and often thinks of you as another resource to be tasked. This tends, unless you're lucky to have a contract rep that let's you flex your expertise, to lead to you solving "good idea fairy" problems instead of solving observable needs.
This is awesome. I'd love to buy you a beer or a coffee sometime!
Writing code that saves lives is the best kind of code. You deserve that award. Thank you!
I love that story, it genuinely made my day to read.
It might sound corny, but this is what I like to think the profession is 'all about' - identifying real problems and using our talents with whatever resources are available to solve them.
Best of luck with your studies.
It might sound corny, but this is what I like to think the profession is 'all about' - identifying real problems and using our talents with whatever resources are available to solve them.
Best of luck with your studies.
It's an AWESOME story- with a bit of flourish and narrative it would make a great introduction to a book or lecture.
In 2004 my airborne infantry unit deployed to Iraq. To make a long story short I helped us purchase a commercial off the shelf satellite internet system, get it shipped, set up, and configured for the unit. I got an ARCOM as well. I really was just trying to help my unit keep in touch with home. Laughably my command thought I was undercover CID, how else would a dumb grunt be so smart? What my command didn't know was that before I joined in 2003 at the age of 23 I already had 6 years (I started working while in High School) of professional software development, systems/network admin work under my belt.
When we got back I was useless physically as I had to rehab after a surgery. The XO stuck me in the arms room and I also tried to help our (typical) overworked admin NCO with normal company business.
Here's where it gets interesting. The admin NCO was a super bright guy with zero programming background. In fact it turns out he was just one of man bright NCO's with no programming experience who had held that job at one time or another. Guess how he kept track of the company's business? In a custom Microsoft Access application with plenty of home spun Visual Basic. The funny thing is he didn't write the app, oh no, some NCO years before him had written it and like some odd cultural tradition handed down for generations every NCO after him just progressively enhanced it to suit their needs. There was an old Access book on the shelf in that office and each admin NCO had picked it up, learned what they needed too, and carried on. Said admin NCO is now a doctor.
As a consultant I've come across similar stories in different industries of people picking up VBA and building custom things with no programming background. They always warm my heart.
When we got back I was useless physically as I had to rehab after a surgery. The XO stuck me in the arms room and I also tried to help our (typical) overworked admin NCO with normal company business.
Here's where it gets interesting. The admin NCO was a super bright guy with zero programming background. In fact it turns out he was just one of man bright NCO's with no programming experience who had held that job at one time or another. Guess how he kept track of the company's business? In a custom Microsoft Access application with plenty of home spun Visual Basic. The funny thing is he didn't write the app, oh no, some NCO years before him had written it and like some odd cultural tradition handed down for generations every NCO after him just progressively enhanced it to suit their needs. There was an old Access book on the shelf in that office and each admin NCO had picked it up, learned what they needed too, and carried on. Said admin NCO is now a doctor.
As a consultant I've come across similar stories in different industries of people picking up VBA and building custom things with no programming background. They always warm my heart.
The Army environment is ripe for improvisation. Especially if you're dealing with a lot of manual process that can be automated. Your story is definitely heart-warming. It shows what bright individuals can do, even if they don't have professional training.
I recall the off-the-shelf satellite systems! We had one too (I was stationed on Camp Liberty) and an Iraqi engineer dude would show up to help us set it up. It only worked about 70-75% of the time and once we had a serious rainstorm that damaged the dish. It took us a while to get us a replacement.
Eventually I was able to find a PDF manual for the system and was able to do some of my own troubleshooting when issues came up.
I recall the off-the-shelf satellite systems! We had one too (I was stationed on Camp Liberty) and an Iraqi engineer dude would show up to help us set it up. It only worked about 70-75% of the time and once we had a serious rainstorm that damaged the dish. It took us a while to get us a replacement.
Eventually I was able to find a PDF manual for the system and was able to do some of my own troubleshooting when issues came up.
Good on you. Sounds like you had great leadership.
I've met a lot of smart Soldiers during my time in the Army. SSGs with PhDs, Specialists in law school, etc. It helps being in a branch that has a higher ASVAB requirement but there are smart guys in all of the branches. The military (especially the reserve forces) needs the skills that talented civilians like the folks here on HN have. The military also has a lot to give back in return. Besides the leadership skills and the usual GI Bill stuff, there are some pretty solid technical skills to be acquired. My previous employer, Rackspace, has network engineering teams that are heavily populated by former enlisted signal personnel who got Cisco and Juniper training in the military and left to make some very attractive salaries on the civilian side. If you are young and smart but lacking in the big iron skills, it's not a bad way to jump-start a great career.
I've met a lot of smart Soldiers during my time in the Army. SSGs with PhDs, Specialists in law school, etc. It helps being in a branch that has a higher ASVAB requirement but there are smart guys in all of the branches. The military (especially the reserve forces) needs the skills that talented civilians like the folks here on HN have. The military also has a lot to give back in return. Besides the leadership skills and the usual GI Bill stuff, there are some pretty solid technical skills to be acquired. My previous employer, Rackspace, has network engineering teams that are heavily populated by former enlisted signal personnel who got Cisco and Juniper training in the military and left to make some very attractive salaries on the civilian side. If you are young and smart but lacking in the big iron skills, it's not a bad way to jump-start a great career.
Thanks! Yeah, I was definitely helped out by my leadership. They all kinda knew I was good with computers and so I was kind of the unofficial "tech support" for the company as well.
I also know a few of my friends who were in signals who came out of the military to get some pretty good jobs. Another good thing is that the Army encourages you to take courses online while you are deployed or even when you are serving. So you can get credits which you can transfer to a university when you try to get a real degree.
I also know a few of my friends who were in signals who came out of the military to get some pretty good jobs. Another good thing is that the Army encourages you to take courses online while you are deployed or even when you are serving. So you can get credits which you can transfer to a university when you try to get a real degree.
+1 on the leadership count. I feel like that is the biggest benefit I have gotten from my experience as an infantry Marine. It also helps with humility - I feel it can become very easy to become egotistic in the money-fueled world of tech, and it's a humbling experience when you're working with people who don't care one iota about that.
Being in the military does suck for various reasons also though, but even that experience gives you lessons & motivation to take away from it.
Being in the military does suck for various reasons also though, but even that experience gives you lessons & motivation to take away from it.
There is likely a near limitless number of ways that military information tech could be improved and streamlined, due to the usual tendency for large bureaucracies to have stale systems and the increased opaqueness that the military operates under...and also, the relative lack of programmers in the recruiting pool...but it's encouraging (and surprising!) to see that at least a few Army higher-ups care enough about technical details to award medals.
Also, couldn't help but think of Grace Hopper, who was received a special promotion to Rear Admiral, post-retirement, because of her work on computing. I didn't realize until re-reading her Wikipedia entry how much of her work and leadership (serving as director of the Navy's programming languages group) occurred after her retirement at age 60:
http://en.wikipedia.org/wiki/Grace_Hopper#Retirement
Also, couldn't help but think of Grace Hopper, who was received a special promotion to Rear Admiral, post-retirement, because of her work on computing. I didn't realize until re-reading her Wikipedia entry how much of her work and leadership (serving as director of the Navy's programming languages group) occurred after her retirement at age 60:
http://en.wikipedia.org/wiki/Grace_Hopper#Retirement
I'm not sure how things are like now (I got out in '09), but things were definitely opaque and bureaucratic when I was in. It was intensely frustrating as well, because the tools I had to use were horribly inefficient. That's why I was so happy when the BMO turned a blind eye to what I had done, because the important thing was that I was getting results. It's good to have enlightened leadership.
Opaque and bureaucratic?
Perhaps you did not have time to use Grace Hopper's language COBOL to truly understand opaque bureaucracies.
Perhaps you did not have time to use Grace Hopper's language COBOL to truly understand opaque bureaucracies.
[deleted]
But its a perfect example of her wisdom:
" Its easier to get a medal afterwards, then to ask for permissions beforehand "
Well not for actual code, but how about a medal for repairing a database?
It was 1984. I was stationed at Babenahusen, Germany - Field Artillery. Yes, I was a 13 Bang Bang (13B). At that time, I was the only one to have a PC in the barracks. I used to stretch a phone code to the wall phone in the next building and dial up BBS's.
Anyway, I ended up working on the brigade's Wang System. I got there cause the S2 saw me hacking away on my Commodore one night and thought I was perfect for the job. Next week I was reassigned. Classic for the Army.
The PBO (Property Book Officer) did something, I never found out what - but the system crashed. Many of the personal records were stored in that system (and on 8" Disc's - remember those?). And it was my job to fix it.
I had completed Wang's various training courses so I was familiar with the system. But I had no clue how to even figure out what happened. I ended up calling Wang in NYC. And over the phone their engineers and I got the system back up. It took almost 2 days. And I got at most an hour of sleep.
I got an Army Commendation Medal out of it.
It was 1984. I was stationed at Babenahusen, Germany - Field Artillery. Yes, I was a 13 Bang Bang (13B). At that time, I was the only one to have a PC in the barracks. I used to stretch a phone code to the wall phone in the next building and dial up BBS's.
Anyway, I ended up working on the brigade's Wang System. I got there cause the S2 saw me hacking away on my Commodore one night and thought I was perfect for the job. Next week I was reassigned. Classic for the Army.
The PBO (Property Book Officer) did something, I never found out what - but the system crashed. Many of the personal records were stored in that system (and on 8" Disc's - remember those?). And it was my job to fix it.
I had completed Wang's various training courses so I was familiar with the system. But I had no clue how to even figure out what happened. I ended up calling Wang in NYC. And over the phone their engineers and I got the system back up. It took almost 2 days. And I got at most an hour of sleep.
I got an Army Commendation Medal out of it.
This is the reason that I say that most people need to learn to code, even just a little bit. Regardless of what career path you choose, it's highly likely that you'll at least use a computer for some of it, and being able to write macros or simple programs to automate things can make you stand out from your peers.
[deleted]
Agreed. Automated many reports or information gathering processes the same way. I don't get a medal, but end of year reviews are awesome. Even better is when you share the code or process with others so they can copy it for some of their work .
I'll tentatively agree, with the reservation that I would like to see some studies on the effects of this before we go all out teaching everyone to code a little.
My concern is that while macros or simple programs would let people do things more productively or do things that would not be feasible manually, they also let them make bigger and more costly mistakes. We need to figure out how to get the former while minimizing the latter.
My concern is that while macros or simple programs would let people do things more productively or do things that would not be feasible manually, they also let them make bigger and more costly mistakes. We need to figure out how to get the former while minimizing the latter.
Code can also stop manual errors from creeping in.
This spring, I put together a graphic novel. When I was creating the list of source files to drop into InDesign's batch processor (a tedious task that involved full file system paths to a bunch of sequentially numbered files), I left one out. I managed to miss the forest for the trees when proofing, and didn't realize I'd made this mistake until I was sitting down to relax and enjoy reading the advance copy. With 399 more sitting on a loading dock waiting to be shipped to me.
I had to do a new print run; this cost me about $6000, which pretty much puts the Kickstarter for this volume in the red.
I also wrote a simple little script that I can point at a directory full of files, and get a CSV of everything in it to feed to InDesign. I will not be making this particular mistake again on a larger project. There will be other ones, I'm sure. And I'll try to find ways to automate stuff I can, and improve my proof reading process as well.
You are going to make mistakes. By hand, and in creating automated systems. This is a fact of life.
This spring, I put together a graphic novel. When I was creating the list of source files to drop into InDesign's batch processor (a tedious task that involved full file system paths to a bunch of sequentially numbered files), I left one out. I managed to miss the forest for the trees when proofing, and didn't realize I'd made this mistake until I was sitting down to relax and enjoy reading the advance copy. With 399 more sitting on a loading dock waiting to be shipped to me.
I had to do a new print run; this cost me about $6000, which pretty much puts the Kickstarter for this volume in the red.
I also wrote a simple little script that I can point at a directory full of files, and get a CSV of everything in it to feed to InDesign. I will not be making this particular mistake again on a larger project. There will be other ones, I'm sure. And I'll try to find ways to automate stuff I can, and improve my proof reading process as well.
You are going to make mistakes. By hand, and in creating automated systems. This is a fact of life.
The thing I like about making automated mistakes is that when I fix that mistake it usually doesn't happen again.
I also wonder about the percent of mistakes made.
A long time back I made some scripts to bulk load new employees into our associate management software. Before that it took an admin loading them in one at a time. The admin could probably get one employee entered, give or take, per minute, given network latency. The script had delays and such to not slam the network, but ran in the background. My first version got a field wrong for 90 or so employees, but I just had to do some small modification and it went back and fixed them all.
Basically, I made 90 or so mistakes, but managed to make the mistake and fix it in a tenth the time it took to manually enter all of them, and then that mistake was never made again.
I guess a lot of it depends on how critical correctness is straight out of the gate (like in your case). For our purposes, it was fine.
I also wonder about the percent of mistakes made.
A long time back I made some scripts to bulk load new employees into our associate management software. Before that it took an admin loading them in one at a time. The admin could probably get one employee entered, give or take, per minute, given network latency. The script had delays and such to not slam the network, but ran in the background. My first version got a field wrong for 90 or so employees, but I just had to do some small modification and it went back and fixed them all.
Basically, I made 90 or so mistakes, but managed to make the mistake and fix it in a tenth the time it took to manually enter all of them, and then that mistake was never made again.
I guess a lot of it depends on how critical correctness is straight out of the gate (like in your case). For our purposes, it was fine.
Part of coding is (or at least should be) verifying results. Anytime I need to build solutions, I spend more time verifying (and fixing if needed) the results. Make changes? Verify again.
My father is a retired South Wales steelworker - he worked in the Hot Mill, which is where you put slabs of steel in, and take huge coils of hot rolled steel out (http://en.wikipedia.org/wiki/Rolling_%28metalworking%29). The building is half a mile long, and the thickness of the steel slab is gradually reduced as it passes through dozens of rolling stations - pairs of rollers (or rolls as they're called).
To get the best product quality, it's important to monitor the shape of the rolling surface of each roll. If they distort out of tolerance, they have to be taken offline and machined to a new finish - something that would stop production for hours.
My father told me of the time when they bought an expensive new computerised lathe to reduce the time it takes to fix up the rolls - this was in the 1980s when a PC on a production line was still a thing of wonder. For a while, everything worked as planned. Then, for some reason, the quality of the reconditioned rolls dropped drastically. Despite the fact that the PC dump showed that the rolls had perfect surfaces and profiles, production defects skyrocketed and it was discovered that the reconditioned rolls were to blame.
To cut an even longer story short - they eventually discovered that the lathe operator had taught himself how to edit the PC logs (in hex!) to make the results look good, without having to get down and actually do the work.
To get the best product quality, it's important to monitor the shape of the rolling surface of each roll. If they distort out of tolerance, they have to be taken offline and machined to a new finish - something that would stop production for hours.
My father told me of the time when they bought an expensive new computerised lathe to reduce the time it takes to fix up the rolls - this was in the 1980s when a PC on a production line was still a thing of wonder. For a while, everything worked as planned. Then, for some reason, the quality of the reconditioned rolls dropped drastically. Despite the fact that the PC dump showed that the rolls had perfect surfaces and profiles, production defects skyrocketed and it was discovered that the reconditioned rolls were to blame.
To cut an even longer story short - they eventually discovered that the lathe operator had taught himself how to edit the PC logs (in hex!) to make the results look good, without having to get down and actually do the work.
Ah, Army IT style. Back in my conscript days, the unit's secretary once had to take a list of soldiers from system A (LASTNAME/FIRSTNAME) and convert them to the format required by system B (FIRSTNAME,LASTNAME)... so she was doing this manually in Excel: click, highlight, ctrl-X, delete, cursor cursor, ",", ctrl-V, repeat.
So I dumped the file to CSV, wrote a one-liner awk script that did the transformation, and imported the result back as a new column. No medal, but one very happy secretary!
What really astonished me, though, is that she didn't even think that this kind of thing was possible. In her worldview, one Machine spit out data in a fixed format and another Machine demanded it back in another, and it was just too bad if humans had to do mindless work to conform to their needs.
So I dumped the file to CSV, wrote a one-liner awk script that did the transformation, and imported the result back as a new column. No medal, but one very happy secretary!
What really astonished me, though, is that she didn't even think that this kind of thing was possible. In her worldview, one Machine spit out data in a fixed format and another Machine demanded it back in another, and it was just too bad if humans had to do mindless work to conform to their needs.
You could text-to-columns it then concant it via B1 & "," & A1 then drag down. Alternatively, you could use =left(find()) and =right(find()) to function it.
I touched on it in the mainteannce/ops space, but the admin space is also susceptable to this. I find that there's a very rapid change in fundamental understanding of capability between age groups. Of course there's exceptions in both parties but many people born after about 1980 really do underestimate the benefits they have by having grown up with personal computers. They simply just think about them differently.
I touched on it in the mainteannce/ops space, but the admin space is also susceptable to this. I find that there's a very rapid change in fundamental understanding of capability between age groups. Of course there's exceptions in both parties but many people born after about 1980 really do underestimate the benefits they have by having grown up with personal computers. They simply just think about them differently.
I'm sure you can do that 'natively' in Excel, but not my field of expertise; IIRC I actually spent longer faffing about in the Excel docs looking for a way to do this (and failing) than writing the awk regexes.
It did make me wonder how often some variant of this happens every day. "Data entry" is still a job, after all...
It did make me wonder how often some variant of this happens every day. "Data entry" is still a job, after all...
Occasionally I'll get a letter from the bank or phone company and the name is wrong .. and then I realise that this massive multi-billion turnover company has some poor data entry person retyping my data at some point in their chain. Then I wonder how on Earth they let that happen.
[deleted]
Slightly off topic, but anyone here receive the US President's Council on Y2K Conversion medal?
Last one on this page:
http://en.wikipedia.org/wiki/Awards_and_decorations_of_the_U...
Last one on this page:
http://en.wikipedia.org/wiki/Awards_and_decorations_of_the_U...
Great story! I did something like this for Epson about 14 years ago. I was a support person for printers and I one day overheard some grumbling by someone who was collating ink cartridge information.
Apparently they had "modified" a clipper database and added new records, but it was one record per file, with each field delimited by new line and field/values in ini format (key=value). They were opening each file in notepad, then copying each value into a spreadsheet. They had over 20,000 thousand files^H^H^H^H^H records, needless to say this took a long time to compile the excel file which they used for reporting. Like 9 weeks long.
I was mucking around with Perl at the time, and I casually mentioned this is what Perl is good for, I got this skeptical look, so I said I'd prove it. They gave me 100 sample files, and then I spent some time using file globbing and some regexes to split out the data. Whilst I was about it, I fiddled with hashes and worked out how to use refs, mainly because I was a bit bored and learning some Perl concepts.
I then returned the next day with a working program, installed a Windows version of Perl, then copied the 10,000 records locally, ran my script, tweaked it, then emailed the guy the CSV file I created. The script took about 45 seconds to run (it was a bit inefficient).
I then walked over to the guy, asked him to open his email and watched his eyes bulge a little. I then walked to my desk and took some more calls about printers.
A few weeks later, I was surprised to discover I had been made employee of the quarter by Epson Australia.
Apparently they had "modified" a clipper database and added new records, but it was one record per file, with each field delimited by new line and field/values in ini format (key=value). They were opening each file in notepad, then copying each value into a spreadsheet. They had over 20,000 thousand files^H^H^H^H^H records, needless to say this took a long time to compile the excel file which they used for reporting. Like 9 weeks long.
I was mucking around with Perl at the time, and I casually mentioned this is what Perl is good for, I got this skeptical look, so I said I'd prove it. They gave me 100 sample files, and then I spent some time using file globbing and some regexes to split out the data. Whilst I was about it, I fiddled with hashes and worked out how to use refs, mainly because I was a bit bored and learning some Perl concepts.
I then returned the next day with a working program, installed a Windows version of Perl, then copied the 10,000 records locally, ran my script, tweaked it, then emailed the guy the CSV file I created. The script took about 45 seconds to run (it was a bit inefficient).
I then walked over to the guy, asked him to open his email and watched his eyes bulge a little. I then walked to my desk and took some more calls about printers.
A few weeks later, I was surprised to discover I had been made employee of the quarter by Epson Australia.
The US Army is really just 10 thousand motor pools. All the war, guns and explosives are really just an excuse to make more motor pools to maintain.
What a great story - thank you for your service, and for sharing!
I have a much, much less impressive story, but maybe someone will find it interesting: I was working at a military library as a civilian, and I automated repetitive parts of our workflow to add books to WorldCat using Autohotkey (We added books to WorldCat so other libraries could request them). I also came up with the idea of using our barcode scanners to check books out to people using a Word document - our library database at the time was slow, far away, and went down regularly. Up till then, no one had realized that you could scan bar codes into a document.
Unfortunately, I didn't realize that the automation I did was unauthorized; there was a shakeup that had to do with misuse of CAC cards, and as part of that, my scripts were discovered and I lost my job. Still, I think that kindled an interest in programming, and I now hack away happily at personal projects.
I have a much, much less impressive story, but maybe someone will find it interesting: I was working at a military library as a civilian, and I automated repetitive parts of our workflow to add books to WorldCat using Autohotkey (We added books to WorldCat so other libraries could request them). I also came up with the idea of using our barcode scanners to check books out to people using a Word document - our library database at the time was slow, far away, and went down regularly. Up till then, no one had realized that you could scan bar codes into a document.
Unfortunately, I didn't realize that the automation I did was unauthorized; there was a shakeup that had to do with misuse of CAC cards, and as part of that, my scripts were discovered and I lost my job. Still, I think that kindled an interest in programming, and I now hack away happily at personal projects.
When I was in the military if I would have tried something outside of my "MOS" or rating I would have been in a lot of trouble! Great job my friend.
Not bad for a motorpool guy. The place that I remember really needing some programmers was on the MI (military intelligence) side. They spend all of their time looking for patterns in data, and in 2009 it was still mostly done by hand. Plus that is where most of the smart Soldiers end up.
The only reason I ended up in logistics is because my recruiter asked me what I was doing in college. I said "Computer Engineering" and he said "This has computers in it!". I was 19 years old and I had no idea about anything so I said "Sure, I'll do that!". We were also an artillery unit and so there weren't any MI positions AFAIK. By the time I was deployed I was working at Intel and I had already graduated with a bachelors in Computer Engineering. So that definitely helped!
Why doesn't the Military hire more computer science graduates then?
The right answer probably isn't to hire computer science people as Soldiers. At least not many of them. It is probably better to just contract out the occasional job where this is needed. It is actually disappointing how few officers can do any programming. They are all college graduates, and I think a little but of computer science is pretty standard these days.
There are several reasons.
Government pay scales are inflexible. A college graduate in CS would typically enter government service as an O-1 or GS-7, step 1. Both are less than $40k/year. Pay maxes out at around $150k/year after 18 years of unremarkable service. If you somehow manage to become a 4-star general of the cyberbrigades, in essence the CEO of Army Programming, Inc., you could possibly earn $180k per year, with no equity, but a nice pension plan.
But you won't get even half that far. The mental processes involved in creating military procedures are fundamentally incompatible with those involved in software development. It is worth noting that everything Original Poster did to improve anything was completely against the rules, and was only permitted because it actually worked out in the field, and did not negatively impact anyone's duties.
Government hiring is ridiculous. I once overheard a conversation about the possibility of converting contractors to employees. As it turns out, thanks to the preference ranking systems, the person most perfectly qualified to do the job, because that is exactly what he was currently already paid to do, with over 10 years of experience doing just that, would typically turn up no earlier than the third page of applicants. Every one of them would have to be individually considered and rejected before reaching the person already doing the job. Also, he would have to take a 50% cut in pay.
Essentially, the government cannot compete in the open job market for any skill that makes a person worth hiring. They are therefore forced to train existing military personnel in software wherever necessary. And as expected, they train for that in a similar manner to the way they train everything else. The person is ordered to transfer to Fort Wherever for six weeks, to become a programmer. You end up with a person that thinks Waterfall is a good process, better programs have more lines of code, and that unit tests are written from an Excel template.
You cannot solve a problem from the same state of mind that created it. The military is covered with leechlike contractor companies because they have been forbidden by law, by regulation, and by standing order from solving their own problems in an effective way. As always, the worst problem is bad management.
Government pay scales are inflexible. A college graduate in CS would typically enter government service as an O-1 or GS-7, step 1. Both are less than $40k/year. Pay maxes out at around $150k/year after 18 years of unremarkable service. If you somehow manage to become a 4-star general of the cyberbrigades, in essence the CEO of Army Programming, Inc., you could possibly earn $180k per year, with no equity, but a nice pension plan.
But you won't get even half that far. The mental processes involved in creating military procedures are fundamentally incompatible with those involved in software development. It is worth noting that everything Original Poster did to improve anything was completely against the rules, and was only permitted because it actually worked out in the field, and did not negatively impact anyone's duties.
Government hiring is ridiculous. I once overheard a conversation about the possibility of converting contractors to employees. As it turns out, thanks to the preference ranking systems, the person most perfectly qualified to do the job, because that is exactly what he was currently already paid to do, with over 10 years of experience doing just that, would typically turn up no earlier than the third page of applicants. Every one of them would have to be individually considered and rejected before reaching the person already doing the job. Also, he would have to take a 50% cut in pay.
Essentially, the government cannot compete in the open job market for any skill that makes a person worth hiring. They are therefore forced to train existing military personnel in software wherever necessary. And as expected, they train for that in a similar manner to the way they train everything else. The person is ordered to transfer to Fort Wherever for six weeks, to become a programmer. You end up with a person that thinks Waterfall is a good process, better programs have more lines of code, and that unit tests are written from an Excel template.
You cannot solve a problem from the same state of mind that created it. The military is covered with leechlike contractor companies because they have been forbidden by law, by regulation, and by standing order from solving their own problems in an effective way. As always, the worst problem is bad management.
Like most aspects of the military, they don't want/need experts. They want someone who knows which knob to turn until all the nixie tubes light up.
Have you tried to hire programmers?
Now imagine you're not offering stock, and are offering well below market rates, but at least they'll have meals made for them.
Now imagine you're not offering stock, and are offering well below market rates, but at least they'll have meals made for them.
Offer to do their laundry. https://news.ycombinator.com/item?id=7817895
What has kept me in (after joining to get better pay during college) was medical services for my child and (related to that) the potential to get one of the few remaining good pensions available in the U.S.
In fact the latter thing is the only real incentive keeping many very talented members of the military (or at least the Navy) in technical fields at pay below the private sector.
In fact the latter thing is the only real incentive keeping many very talented members of the military (or at least the Navy) in technical fields at pay below the private sector.
Agreed. I just switched from Marine Corps to Navy after 10 years to keep from dying at 50, and mostly for the tricare and the free TS.
[deleted]
I think the army does that too, however, I'm not sure.
A thousand times this. As an officer who served in infantry and intelligence officer positions-turned software engineer, there are countless time-consuming tasks that could be automated just like the author's example. And yes, MI is probably the place where it's most needed.
Plus that is where most of the smart Soldiers end up.
Sometimes. :D I say this as a former 98C who has seen the dumbest people in MI units.
But you're right about the need for programming support: during the Gulf War I discovered that the '386 (possibly '286) that we'd been using primarily as a Wing Commander Entertainment Console in one of our comms huts also had a copy of DBase III on it. Figured out how to create a table and query it, and applied it to my job. Didn't get a medal out of it, but it opened my eyes to the usefulness and power of databases.
Sometimes. :D I say this as a former 98C who has seen the dumbest people in MI units.
But you're right about the need for programming support: during the Gulf War I discovered that the '386 (possibly '286) that we'd been using primarily as a Wing Commander Entertainment Console in one of our comms huts also had a copy of DBase III on it. Figured out how to create a table and query it, and applied it to my job. Didn't get a medal out of it, but it opened my eyes to the usefulness and power of databases.
You'd want to keep some of those people around though. Computers are great for detecting anomalies and known patterns but you need the human brain to invent new patterns to look for.
Of course, sometimes a brain will invent a really weird pattern. You get agriculturally incompetent aliens, government employed blues brothers fans and all kinds of nonsense. I guess that's why intelligence gathering should be done in a group. More eyes results in less errors, right? :)
Of course, sometimes a brain will invent a really weird pattern. You get agriculturally incompetent aliens, government employed blues brothers fans and all kinds of nonsense. I guess that's why intelligence gathering should be done in a group. More eyes results in less errors, right? :)
Very cool story. Can you imagine how fun an Army hackathon might be? 'We've hooked up this Missile Command arcade game to a Patriot missile battery. Now you shoot down enemy targets with a track ball!'
Thanks for sharing. I'm in the National Guard too. I've done some VBA to automate tactical operations center (TOC) reporting while deployed. I wrote an iPhone app / website for ammunition net explosive weight calculations (https://itunes.apple.com/us/app/dodic-calc/id660062276?mt=8). Working on a bunch more. I'm in the logistics field and would love to collaborate.
It is good to hear a positive story about command leadership. I have never been in the military but have friends that were mid-level NCOs and staff level officers. Unfortunately the stories I've heard from them are pretty sad. Crappy software delivered late with the cycle continuing because the retiring NCOs and officers know if they don't make waves they can get a good post-retirement job at the contractor delivering the software.
This sounds a bit like my experience in a standard civilian transport company, except that I don't get medals (rightly so) and I don't deal with life and death (thankfully).
Our operational database is still accessed via an emulated version of IBM 3270 terminal [1], where we have Windows emulator for the client that connects to the DB2 database. It's freaking ancient, to the point where the emulated version uses the mouse input to emulate the "light pen" [2] from the original system, which was used because the mouse barely existed at that time. The thing uses 4-letter terminal codes to access every function. Oldschool.
Our employee distribution is quite significantly skewed towards the older generations. Compounding it, many of the people who interact with it tend to be trade-staff who started in workshops then climbed their way into being semi-technical admin (roles such as fleet planning, etc.). It works, but the mind boggles when you imagine the degree of time wasted every day by these guys because they don’t have any sort of significant batch processing capability.
In the course of doing my work, I was exposed at some point to ODBC drivers for the database. I managed to get some credentials used for running reports against it (I think I found another reporting query with them saved in the file and ripped them out of it) which that allowed me to arbitrarily query the database. From that, I started to automate a great many things - for example, where previously a yard coordinator would type in the code to query each storage road individually in his maintenance yard to see what he had around for the day’s work, I gave him a 1-click query for doing the same job.
Our maintenance database was a similar affair, except that it runs Oracle and is a little less antiqued. It also has a windows-native GUI but it is similarly lacking in many batch processes.
A more recent example that I tackled is that every single morning, a yard coordinator would work out which groups of vehicles would be coming in that day and were due for their roadside inspection (info from the operational database). He would then print out a list of these (literally on paper, next to his keyboard) and manually enter each vehicle, 1 by 1, in to the maintenance database to check whether they were then due for their yearly scheduled maintenance before their next roadside inspection. If they were, they'd be flagged for dragging in to the workshop. This took him approximately an hour, every single morning of his work life, and that would then be summed up and presented at his morning planning meeting.
He’d asked the guys who normally support this sort of stuff, but had got nowhere in about 7 months because it sort of fell between “fully-fledged IT department that can do this easily but comes with bureaucracy” and “guy who kind of knows how to develop database queries, but doesn’t know how to query 2 different databases in the one query” and so it never got anywhere. I was on site one morning for some unrelated work and saw him doing this. When I asked about it, I told him to give me some time and I’d come back to him and proceeded to write a query to do it in one click.
I’ve been doing this sort of stuff for about 3-4 years now and have a (good) reputation amongst the maintenance, operations, etc. guys now. The problem is that IT tend not to support them, as it tends to be more effort spent on bureaucracy than the task at hand. Furthermore, the guys don't know who to talk to in order to get this stuff done / don’t know any better, so they just deal with it and do it by hand.
In the end, I guess I did get noticed by middle management because I've now been tasked with being the lead on developing/acquiring a next-gen operations business intel solution which will draw together all the disparate bits of data we gather and put it to better use, so that's cool.
I guess my take-home message is that many of you guys work in the IT space in technology companies. You tend to be exposed to people who just get this stuff and so it all just happens. There's so so many more companies out there though, particularly established ones running operations (think mining, transport & logistics, the army as per the OP, etc.) where this stuff simply isn't done and it's a completely different world. They tend to have a distrust of "IT" because their experience with them is the bloated bureaucratic mess that is many corporate IT departments. IT in large, non-high-tech corporations can also be the sort of place where a problem either is too small to care about, or significant enough that it warrants a legion of SAP/Oracle DBAs and a whole heap of project management to develop a “solution” over a 12+ month period.
There is an astounding amount of potential for someone who gets operations / the guys on the coal-face, and can bring high-tech solutions to their problems rapidly. They will quite literally treat you as some sort of wizard who has mastered the arcane forces if you do this, because you deliver a solution that is otherwise unattainable in many situations. Your business impact is huge because you cut out a whole heap of otherwise wasted time, which is a direct benefit to the bottom line.
The major challenge IT has is bridging this gap. I’m not quite sure how you go about leaning yourself down enough whilst still appealing to the more rigid constraints of “IT in a big corporation” but I am convinced that there is no end of value to be created in this area.
[1]: https://en.wikipedia.org/wiki/IBM_3270 [2]: https://en.wikipedia.org/wiki/Light_pen
Our operational database is still accessed via an emulated version of IBM 3270 terminal [1], where we have Windows emulator for the client that connects to the DB2 database. It's freaking ancient, to the point where the emulated version uses the mouse input to emulate the "light pen" [2] from the original system, which was used because the mouse barely existed at that time. The thing uses 4-letter terminal codes to access every function. Oldschool.
Our employee distribution is quite significantly skewed towards the older generations. Compounding it, many of the people who interact with it tend to be trade-staff who started in workshops then climbed their way into being semi-technical admin (roles such as fleet planning, etc.). It works, but the mind boggles when you imagine the degree of time wasted every day by these guys because they don’t have any sort of significant batch processing capability.
In the course of doing my work, I was exposed at some point to ODBC drivers for the database. I managed to get some credentials used for running reports against it (I think I found another reporting query with them saved in the file and ripped them out of it) which that allowed me to arbitrarily query the database. From that, I started to automate a great many things - for example, where previously a yard coordinator would type in the code to query each storage road individually in his maintenance yard to see what he had around for the day’s work, I gave him a 1-click query for doing the same job.
Our maintenance database was a similar affair, except that it runs Oracle and is a little less antiqued. It also has a windows-native GUI but it is similarly lacking in many batch processes.
A more recent example that I tackled is that every single morning, a yard coordinator would work out which groups of vehicles would be coming in that day and were due for their roadside inspection (info from the operational database). He would then print out a list of these (literally on paper, next to his keyboard) and manually enter each vehicle, 1 by 1, in to the maintenance database to check whether they were then due for their yearly scheduled maintenance before their next roadside inspection. If they were, they'd be flagged for dragging in to the workshop. This took him approximately an hour, every single morning of his work life, and that would then be summed up and presented at his morning planning meeting.
He’d asked the guys who normally support this sort of stuff, but had got nowhere in about 7 months because it sort of fell between “fully-fledged IT department that can do this easily but comes with bureaucracy” and “guy who kind of knows how to develop database queries, but doesn’t know how to query 2 different databases in the one query” and so it never got anywhere. I was on site one morning for some unrelated work and saw him doing this. When I asked about it, I told him to give me some time and I’d come back to him and proceeded to write a query to do it in one click.
I’ve been doing this sort of stuff for about 3-4 years now and have a (good) reputation amongst the maintenance, operations, etc. guys now. The problem is that IT tend not to support them, as it tends to be more effort spent on bureaucracy than the task at hand. Furthermore, the guys don't know who to talk to in order to get this stuff done / don’t know any better, so they just deal with it and do it by hand.
In the end, I guess I did get noticed by middle management because I've now been tasked with being the lead on developing/acquiring a next-gen operations business intel solution which will draw together all the disparate bits of data we gather and put it to better use, so that's cool.
I guess my take-home message is that many of you guys work in the IT space in technology companies. You tend to be exposed to people who just get this stuff and so it all just happens. There's so so many more companies out there though, particularly established ones running operations (think mining, transport & logistics, the army as per the OP, etc.) where this stuff simply isn't done and it's a completely different world. They tend to have a distrust of "IT" because their experience with them is the bloated bureaucratic mess that is many corporate IT departments. IT in large, non-high-tech corporations can also be the sort of place where a problem either is too small to care about, or significant enough that it warrants a legion of SAP/Oracle DBAs and a whole heap of project management to develop a “solution” over a 12+ month period.
There is an astounding amount of potential for someone who gets operations / the guys on the coal-face, and can bring high-tech solutions to their problems rapidly. They will quite literally treat you as some sort of wizard who has mastered the arcane forces if you do this, because you deliver a solution that is otherwise unattainable in many situations. Your business impact is huge because you cut out a whole heap of otherwise wasted time, which is a direct benefit to the bottom line.
The major challenge IT has is bridging this gap. I’m not quite sure how you go about leaning yourself down enough whilst still appealing to the more rigid constraints of “IT in a big corporation” but I am convinced that there is no end of value to be created in this area.
[1]: https://en.wikipedia.org/wiki/IBM_3270 [2]: https://en.wikipedia.org/wiki/Light_pen
We used to have a role called "systems analyst", who's job (amongst other things) was to look at the existing system and figure out how it could be improved by software. Of course, that role's kinda fallen out of favour these days...
This is a great story, I hope this get's picked up in regular press/media/blogsphere and shared more.
Great story and inspirational too.
Agreed. And I'm enjoying the other stories that appear higher in the thread.
1. The code I wrote was to download the NSA database. Script really.
2. The army was the Russian Army.
signed
Ed Snowden
signed
Ed Snowden
On other pages of this website people are being lectured how they should adapt to the website etiquette. I would like to learn how you guys expect Europeans to behave in this context. Should we say what we think? Do you want us to cheer you on? Do you expect us to shut up? How do you want to see this? Just be honest, use whatever language you feel necessary, I'm not easily offended. Here we all thought you would stop eventually, that there would be an end to this. But it has been 34 years now. We've tried pretty much every kind of response. Non of it was what you liked to hear. So, I think it is a fair question? If it isn't, If you think I'm out of line for asking, could you explain why that is? What is the correct behavior for people like myself over the last 34 years. Just your personal opinion, I understand you don't speak for the whole country.
I too enjoy Markov-chain text generation.
The HQ was processing things like medical evacuations, support fire missions, contact reports. The way it was done was very inefficient, frustratingly so. For instance, a medical mission would go like this.
A unit would report an IED strike with critical injuries. The unit would pass a MEDEVAC request by radio to their company -> batalion -> brigade HQ (us). We would then be the dispatch center for the helicopters and synchronization of airspace and hospital and all.
When the request would come in, it would typically be ~30s to 1m after the actual strike. I would yell at an airman that would get up his chair, walk to the center map and with his rule, measure the distance in miles between the hospital landing pad and the strike. He would then compute ETAs and for the helicopters based on various parameters. He would then ask the helicopter HQ to send a chopper on site. He would then slowly type a message in a proformat, post that in the channel. That's ~5m later.
When I was there, I've picked up VBA (VB for Applications), the macro system behind Excel. I didn't even know what a programming language was back then.
This 5min latency in sending the request to choppers, and giving back ETD/ETA info to the unit on the ground would result in people dying off their wounds, or staying in dangerous/exposed locations longer than strictly necessary (waiting for chopper ETAs). This 5min latency was putting people at risk and killing folks.
So I wrote a tool to automate this man's job, in VBA. I picked up the language on site and reduced that latency to ~15s. Being the canadian army, they don't give medals but I got this:
https://s3.amazonaws.com/antoine.im/AIR+WING+COMD+COMMENDATI...
Then, I wrote tools to automate many other parts of the HQ, like a database to handle multiple concurrent critical incidents or a tool to manage airspace for fire missions. Then I realized I liked this programming thing much more than running around with guns. Then I came back to Canada and started a degree in software engineering. Then I'm here today.