What I Learned By Hacking At The National Security Agency
So, to be clear, in software engineering, the internship and self-directed projects have become far more valuable to the students, as an intellectual learning experience, than any university class. And they have become more valuable to employers, as a signal of student ability, than any formal credential, class taken, or grade point average. Communications of the ACM, Jan 2013.
I spent long hours on a self-directed project in the computer lab, building a program that generated Dungeons & Dragons game dungeons (monsters, treasures, etc.). I was teaching myself JCL, COBOL, and ISAM data access. I was 19 years old, in the US Air Force, at the National Security Agency, and using top-secret mainframe computers.
I later discovered that my supervisors knew what I was up to. But I was a young Airman whose job, at least for the first six months, was to tear messages off of classified printers and put them in mailboxes, keep those same printers supplied with paper and ink, and call in any hardware problems. They had no problem looking the other way as this young kid spent hours on Top Secret computers using them to generate D&D games because I was learning programming and how to use the computer system and was doing it on my own time and at no real cost to them.
This was also a period of the great “stolen computer time” stories. You know, someone used hundreds of seconds of computer time without paying for it. You know, those same computers sitting there, unused, sucking up electricity and air conditioning, but if someone uses them without doing all the paperwork and paying a big charge, it was considered theft of services.
In my case, it was just the next phase of my computer science career. The key was that I was not sitting in a classroom listening to someone regurgitate what I just read in a text book. Instead, I was struggling with how to get this COBOL code to randomly select monsters from a database, then from the same database find the expected range of monsters at any given location, and then generate a number, representing their hit points, for each monster at that location.
This would be printed out with a description of the monsters and the treasure available if our intrepid adventurers defeated them all. The dungeon master (me) would use this output to run the encounter with a half dozen other airmen and mark off each monster as they were defeated with fire balls, arrows, and lots of good sword slashing. I would design and draw by hand the dungeon or area where we would be playing D&D, and for each area (say 30 rooms or areas), I would have the program generate whether there were monsters or not, and if so, populate the area with the rule’s specific range of monsters and treasures.
By the time I got to college three years later, programming was easy. One semester, I signed up for three computer science programming classes. The advisor would not let me take three programming classes at once. He said that he would only let students take one programming class per semester as the classes were so difficult and time-consuming. It took awhile, but I finally convinced him to let me take them all. I told him that this would, in fact, make it one of my easier semesters. I finished most of my programming projects within the first few weeks of class and spent the rest of the semester helping the other students (ok, usually the cute girls).
The lesson here is that letting folks get out and just “do” something is needed as much, if not more, than classroom time, lectures, and credentials. In any organization, letting our folks take that 20% of their time and work on their own project is, in my experience, where we get the most learning, new ideas, and innovations. Having everyone in lockstep take credential-granting courses (e.g., PMP, Six Sigma, Scrum, etc.) has never provided the same oomph as letting a few driven individuals run off by themselves and do interesting things.
See also Certification Is Useful But Not For The Reasons We Think
Also, having too many rules about what one is allowed to do and not allowed to do is often counter to good innovation and idea creation. While we have to draw some lines, these lines should be as far apart as reasonable (adjusted over time as the situation warrants) so that when someone gets an idea or motivation, they can follow it through. Our organization, project, or team may gain a huge leg up from such individuals.
Just be careful if you are doing this at the National Security Agency. They may no longer be so accommodating to innovative young airmen.
What are you doing to help your project team members grow their experience and skills?
1 thoughts on “What I Learned By Hacking At The National Security Agency”-
Pingback: Winning The Bureauracy Game
Comments are closed.