Welcome to Pragmatic.
Pragmatic is a weekly discussion show contemplating the practical application of technology.
Exploring the real-world trade-offs, we look at how great ideas are transformed into products and services that can change our lives.
Nothing is as simple as it seems.
This episode is sponsored by LIFX.
Visit lifex spelled L-I-F-X dot co slash pragmatic
for more information and to take advantage
of a special discount off their amazing LED smart bulbs
exclusively for pragmatic listeners.
I'm your host, John Chidjy,
and I'm joined today by my guest host, Casey Liss.
How you doing, Casey?
- Well, how are you?
- Very good, thank you very much.
I wanted to get you on the show
to talk about something that we've both had experience with.
I suspect you may have had a little bit more experience with it, but that's about military
software development.
So it's something that I, when I worked for Boeing about in 2001 through to 2003, I worked
on a project for the Australian Defence Forces called the HF Modernisation Project.
And that was my first and only exposure to developing software for a military contract,
which required all sorts of hoops to jump through and so on and so forth.
But you've also had some experience in that.
Can you tell me a little bit about your experience?
Yeah.
So it was actually about the same amount of time and it was a few years ago, but I worked
for a wholly owned subsidiary of Northrop Grumman.
This particular company did a lot with naval navigation and things of that nature.
And so the stuff I worked on, obviously I need to be a little hand wavy about it, but
it was navigation systems for both the Navy, the American Navy and some civilian folks
as well.
So for example, this company does the navigation system or did at the time, the navigation
system for Royal Caribbean.
And so, if you've ever been on a Royal Caribbean cruise and you got to your destination roughly
on time and intact, then I'm going to claim responsibility for that, even though I think
I wrote like two lines of code for that product.
That still counts.
Two lines, it's still two lines.
Right.
Cool.
All right.
Excellent.
Well, one of the things that I think it's a good place to start is you don't just walk
into a job and sit down and start programming for military software because you have to
go through a vetting process or a screening process. And certainly, I did. And when I
first signed up, it was because the company had military contracts and I was slated to
work specifically on one, it was one of those things that if you didn't get your clearance,
you're essentially told, "Well, thanks for coming. See you later." It was a minimum requirement.
had to get it. So, yeah, you had to behave, I suppose.
But if there's anything dodgy, I mean, if there's anything dodgy in your past, it could jeopardise
your job. So, it was quite serious.
So, when I submitted the application, it took them probably about
six, four to six weeks, I think, to do the assessment.
And, you know, I had to sit down and have an interview and fill in a bunch of forms, going
back to, well, I don't know, some point just after I was conceived, if anyone
Like, I mean, it was insane.
It was pages and pages long.
And they want to go back and get contact details of anyone you've
associated with, particularly if you've been overseas is something I learned.
And because I'd spent two years, two and a half years roughly in two separate stints in North
America, I was flagged as a more interested- I don't want to say high risk, but I'll
say more interesting or worthy of more closer examination or something, which is why
one took longer to process apparently so I'm told. So did you guys do something similar?
Yeah so at the time I needed to get a some modicum of security clearance and as far as I know it's
not active anymore but certainly I had to go through a very similar thing and so I had to
fill out a form which even then I believe was done online but nevertheless it was a form I had to
fill out that just like you said went through my employment history to the beginning of time
including like in high school when I just had, you know, silly summer jobs,
my living history as in like a residence history forever, maybe, well, I think
it was like 10 or 15 years or something like that, but I was fairly freshly out
of what we call college, I believe you guys call university.
And so I had, I had moved, you know, a couple of times because of that.
And then my dad worked for IBM up until two days ago and when he retired.
And so we had moved, um, pretty much every two years for most of my childhood.
And so when you're, I don't know, I was like 23 at the time or something like that, 24.
And when you're that old and you need to go back 10 years, I had to go through like
10 different addresses or something like that.
Some of which, you know, you had to dig up from records that you weren't even sure
that even your parents had anymore.
And then of course, after that, you know, they, they tend to spend some time going
and interviewing some of the people that you've listed as kind of witnesses that
you are, that you are who you say you are.
and you are someone who lived in that place at that time.
And I actually never heard back from any of the people on my list, whether
or not they got interviewed, but.
Certainly I know the idea behind it was, and you kind of hinted at this was what,
what is in Casey's past and what leverage could somebody else have upon him?
So for the sake of, for the sake of discussion, if I had debt up to my
eyeballs, I had to report that.
And then that's risky because if I'm, if I'm really someone who carries a lot of
debt and I get to the point that I'm freaking out about it, some foreign
government could come in and say, here's a suitcase full of money and it'll get
all your debt problems away.
You just got to tell us the secret about what you're working on.
And that's, that's risky for the government and that's not good.
And so that's what the whole process was about.
And I, I pretty much had to stay away from most of the, from most of the code
base until I had my clearance.
And there were certainly absolutely meetings that I could not participate
in until my clearance came in.
Absolutely.
Yeah.
And exactly the same in my case as well.
I found myself excluded for that first month and a half, just, you know,
reading over the same induction manual, basically, welcome to the company.
And I'm like, oh, like, what am I going to do?
Oh, I guess I'll read the induction manual again.
It's only the fourth time.
Anyway, so now I definitely know where the coffee is.
But anyhow, the point is that I sometimes would hear-
Because at the time we were still on an old analogue phone exchange where I was staying,
was an old apartment building in Brisbane and it had an
old analogue phone line.
And if you've ever had an old analogue phone line, you can- You'll know the noises in the
background. There's always a little bit of a faint hiss in the background and strange clicks, and
sometimes you hear echoes and stuff, and like a digital line.
Anyway, I could have swore that during that assessment period that I could have swore that I
heard strange noises on my phone line.
I just- This is what I'm telling myself, right, Casey?
It's like they're listening to what I'm saying.
I even joked at it with some people that I was talking about on the end.
And I was like, you know, if they are, I really don't want to be too much of a smart ass about this, because what if
I, you know, if I jokingly say, hey, I've planted a bomb and blah, it's like, no, that would be just
dumb. I mean, I was old enough to not do something that stupid, but goodness me.
Anyway. I hear you.
In fact, just recently I was at, I was going to try to use the right terminology here.
I was queuing at an airport security gate and they actually had a sign up, like a poster up that said in so many words,
"Do not make jokes about bombs.
We will not find it funny and we will take it very seriously."
And I thought to myself, wow, okay, good to know.
People need to be told these things, you see.
Yeah, apparently.
Damn me.
Yeah, because there'll be some smartass at some point that'll say that, and then they'll be like in an interrogation room for the next five weeks.
Anyhow, god dear. Okay, so once you get through that vetting process and they say,
"Look, you're approved up to this level of classified information,"
then you can get on and do your job, which is great. But the thing is that I learned that there are so many
little things about working in that environment that are different or very, very strict.
So, I just wanted to go through a list of things that I thought were interesting and maybe you can add to
to some of these, we'll see how we go.
The first one that struck me is I'd worked
in at Nortel previously and a few other companies
had swipe card access systems, you know, nothing,
yeah, everywhere's got these things, no big deal.
But you know, you swipe a thing on the door,
it releases a solenoid, the door sometimes
auto magically opens, other times you got to push it.
That's, oh, well, fine.
Hey, that's okay, it's a few calories, right?
Push the damn door open, no big deal.
Point is that you swipe it, you hold the door open
'cause you're a nice guy, right?
You're going to hold that door open for the next five people to come in.
They're going to come right in and you're going to smile.
They're going to say good morning.
They're not showing their badges.
They're not swiping in themselves.
They're just walking right through that open door you opened for them.
It's very nice of you.
And when you want to walk out, there's an infrared detector.
Sometimes there's a release button.
You just push the button or it detects there's a body there.
It automatically unlocks the door for you.
Sometimes again, it magically opens.
Other times you open it and out you walk.
Yeah, well, when you're working in this military stuff that I was involved with,
that doesn't cut it.
You have to individually swipe in and swipe to get out again.
So, you can't just swipe in and hold the door open without getting into a lot of trouble.
And I did get into a lot of trouble because I picked up those bad habits from previous companies I'd worked for.
Did you ever get in trouble for something like that?
They call it tailgating.
Yep, yep.
They did call it tailgating where we were.
And I never got in trouble for it.
And I think in part that was because the company was only about a thousand people.
the, the, the subsidiary that I worked for was
only about a thousand people.
And, you know, you at least recognized almost
everyone else's faces, even if you've never
spoken to them and don't know their names.
And so everyone was very good about if you
were to hold a door open for someone, everyone
was very good about still bad, you know, hitting
the little reader with their badge, just to
make sure that you're counted or, or what have
you, you know, so the audit trail is there that
you just entered or exited the building.
And I'm trying to remember if exiting
required you to badge out. I think it did. Yeah, it's been a
few years now, but certainly to your point, getting in
absolutely did. And people would definitely give you a look or
remind you kind of sternly politely if, if you forgot to
badge in as you were as you as you know, somebody else is
holding the door for you, you'd get a reminder, oh, I think you
forgot to hit your badge. Yeah. And you know, they take it
seriously.
Oh, they took it very seriously. So it's interesting
you brought up that thing that you knew the people that worked there or you knew their
faces and one of the things when we went through our security induction which was designed
to bring people up to a standard that they would expect for your secure behavior and
it covered all sorts of things like this tailgating issue as well as locking your PC when you
get up from your desk and just the usual housekeeping sorts of stuff. But on this particular issue
they played out some scenarios and the scenario they played out was, well,
just because you know that that person you've seen them around doesn't mean that
they weren't let go.
You don't know that they weren't let go yesterday and they no longer have access to
the building.
What if they're being led in to do malicious damage because they're emotionally
upset from being let go?
You know, what if these people were removed from the building because they breached
the, you know, secrets,
official secrets act or something and, and divulge classified information?
I mean, you don't know that.
So, unless they have their badge, unless they swipe in,
and unless their face on the badge matches their face,
you should contact someone with security immediately.
And that's what we were told, and that's what we did.
And I made the mistake once, I'd like to say.
It was just once.
And yeah, I pulled up in front of security
for tailgating in behind someone.
And they didn't seem to care,
but someone else who was behind me did care and dobbed me in.
And I'm like, "Well, that was nice,
but I never made that mistake again."
took it seriously. Yeah, and the funny thing is now Casey is that I go into a non-military
environment, have done actually pretty much since 2003, and I'll swipe in and then I'll
swipe out and I'll swipe, well actually you don't have to swipe out but I'd do anyway,
and I swipe in even though someone else could be opening the door for me and I've had people
say to me, you know, I'm holding the door, you don't have to swipe in and I'm like, sorry,
bad habit or rather was it a good habit? I don't really know. I was just about to say
- I didn't say that.
- It's a habit, okay?
So anyway, okay.
So that's one of those little things that struck me.
So anyway, the next one about security badges also though
is their removal from view
whenever you're outside the premises.
And I made that mistake as I walking down the sidewalk
on a lunch break, going to get, I don't know,
whatever I was getting for lunch at that point.
And just my luck, one of the security guys,
from the company, happened to be walking just behind me, pulled me over to
one side, rather roughly, I might add, and pointed out that my badge was showing.
And it's like the rules were very strict.
You know, you leave the building, you take the badge off, put it in your pocket and get it out of sight
because that makes you a target for access to that building.
Yeah. So, I mean, what are you doing?
OK. I don't think- I don't remember having to do that.
I don't debate that it's the right thing to do, but I don't remember
them being particularly punchy about it. Although to be honest, more often than not, I just
ate at my desk anyway. So, it wasn't really that exciting.
In later years, after that, I had kids and was on a tighter budget and ended up eating
at my desk since then. So, it's less of an issue these days, I'll admit, but it's a habit
I got into and it's one of those things. Maybe I just got stuck with a really anally retentive
security dude. That's also quite possible. But hey, anyway, he took it seriously, even
if no one else did, but well, I did after that.
Anyway. All right, cool.
Another one about stairwells, and I think I talked about this briefly on a previous episode, I think it was episode number eight.
I worked in a high-rise- well, actually, I worked in a bunch of different buildings when I was involved in the project, but there's a high-rise
building. And in the high-rise building, there's this- there was a sort of unwritten rule whereby if you had to go
more than two floors, it would be okay to use the lift.
But if you didn't, if you're only going one floor or two floors,
it was expected you use the stairwells.
And, you know, I guess I had reasons for that.
It's like, well, maybe it's an exercise thing or maybe it's a,
we've only got four lifts and we need to be, I don't know,
if energy efficient, I don't know, whatever.
But that was just sort of like the unwritten rule.
So, you know, you would get in the stairwells, you know,
swipe in the stairwell, go to the next level, swipe out again.
No big deal, right?
Unfortunately, at five o'clock in the afternoon every day, at least at that
point, God knows what it is now, the anti-intruder alarms would be set at
five o'clock. You could swipe into the stairwells because that's a fire safety
requirement, but you couldn't swipe out again. In other words, once you're in, you
are stuck in them. Nice. Yeah, and I didn't know this. I've only been there a couple
of months and anyhow bottom line is I'm like oh I just got to drop this down to level 10 or whatever
it was and I go into the stairwell not thinking it's two or three minutes after five I'd normally
gone by five hadn't come across this problem before and I went in there and yep there go the
anti-intrusion alarms and they're these hundred and god knows what decibel in that ear piercing
pitch that's designed to make you feel nausea and and disoriented I didn't feel disoriented exactly
but geez I felt that nausea and I was like crippled up on the floor I was in
there for a good few minutes before they let me out sure enough I opened the door
to my favorite security guy with two other security guys behind him and I'm
sort of like staggering out of this stairwell and I'm like I'm guessing the
alarm got turned on at 5. Thanks for the memo guys. Yeah cheers so anyhow then they
drew my attention to some leaflet that I'd hadn't been given and said, yeah, it says it clearly here.
And I'm like, yeah, great. Thanks, guys. Anyway, suffice to say, didn't make that mistake again.
Anyway, OK, so one of the other things was that if you were to breach too many of the
safety, sorry, security rules after a while, then they threatened with revoking your clearance and you
would then essentially therefore be sacked because without your clearance, you couldn't do your job.
The Official Secrets Act applies for your entire life, so anything that you, well, whatever the equivalent is in the US,
but it's based on the same system as the British system, whereby once you come across any information that is considered to be classified
or need to know, you must maintain that secret for the entirety of your life.
And therefore, if you leak any information at any point in that future, you can still be prosecuted, go to jail, that kind of thing.
So, you know, obviously the rest of this episode, we're just going to be speaking in certain vagaries,
but I think it's okay to talk about the different bits and pieces of the restrictions of working in that
environment without being specific about exactly what we're working on.
So, that's the goal anyway.
So, if this is the last episode of, dear listener, if this is the last you hear of my voice, then perhaps you'll know what happened.
But Casey should be safe because he's such a nice guy that no one would take him away or something.
Yeah, hopefully. We'll see.
Okay, right. Let me see.
So, that was access requirements and so when it came to buildings.
The other stuff was pretty straightforward.
They had absolutely ridiculous password requirements and this is back in 2001.
So, these days I know it's got to be X number of symbols.
You got to have a mixture of uppercase and lowercase and numbers.
You can't have repeated numbers or letters.
It just get, you know, the rules for passwords these days are insane.
are insane but even back then they were really strict and they had a forced rotation it was
something like every four or six weeks I forget but it was very very regular and it was so
annoying because you're forever forgetting your damn password and of course you couldn't
write it down because you know how some people write it down on a bit of yellow sticky note
or something well yeah if they catch you doing that well that's a big cross and that's a
fail so don't ever even try that but yeah getting up and walking away from your computer
and not locking the screen I got pulled up on that a few times thankfully though that
was by my manager not by the security guy that was probably more serious but
yeah control or delete walk away because yes we're developing in Windows right
yeah okay no Max of course you are of course but I mean yeah you're you're a
you know you're a dotnet guy so it's all good right yeah there you go see yeah
Windows is your friend up to a point okay it's a it's okay all right um okay
so beyond that beyond that I think it's we should probably talk a little bit
about the levels of secret because everyone,
I guess a lot of people know this,
maybe they do, maybe they don't,
but 'cause there's different levels of classified, right?
- So, yeah, well, it's in the US,
I'm gonna probably butcher the details,
but my recollection of it was that there was classified,
which is a pretty darn simple check for clearance.
Like they don't really go that deep into your history.
There was secret, which involved a more thorough check
into your history. And then there's Top Secret, which involves putting on a polygraph and
actually interviewing you and things of that nature. And then anything north of Top Secret,
I'm sure there's several levels, but I don't know them offhand.
Yeah, that's it. So, basically, there's been a bunch of different variations of this. And
the funny thing is that I, something I learned when I was just brushing up on the details
for this show is that back when I did it, Australia had a subtly different system. There's
more or less a pseudo international standard which is derived from the British definitions
originally. And it's the top four that are the most well known. So this classified, as
you say, is referred to as either protected or restricted. And protected or restricted
information would cause, by their definition, undesirable effects. Now, it goes into undesirable
effects but, you know, there's a link in the show notes if you really want to read up into what that
means. But if this is all, if the information is made public, so, you know, classified slash
protected slash restricted, same kind of thing would result, would cause undesirable effects if
it was made public. Confidential information would cause damage or be prejudicial to national
security if it was made public. Secret would cause serious damage, so that's getting serious now,
to national security if it was made public. And top secret would cause exceptionally grave damage
to national security. So, that may or may not help. But yeah, and as you say, in order to get
clearance at different levels, you need to go through ever increasing levels of scrutiny,
including polygraphs and all that sort of other rubbish. And I say rubbish because, you know,
you know, every time I hear polygraph, I just keep thinking of ways of beating polygraph tests, but never mind that.
Not that I- And I'm neither confirming or denying what my clearance level was or what I went through
specifically in that sort of regard to get it.
But the bottom line is that all of those levels of secret mean nothing unless you have a need to
know. And this is the thing that I didn't appreciate before I worked on the military project is the whole
concept of need to know just because you've got clearance up to top secret
ultra super high awesome level doesn't mean you just can walk in there and read
every single top secret document that you want to feel like reading you have
to have some kind of need to know you specifically need to know in order to
carry out your job and I guess the funny thing for me was the decision about
whether or not you actually have a specific need to know it's a little bit
it can be a bit flimsy because it depends on the person.
So someone who is a superior or who is higher up in the chain
in the project you're working on,
gets to make that decision, that choice.
And it's sort of a bit strange to me
'cause I thought, well, what if he thinks
what I might need to know is actually not what I need to know
and there's actually something else that I might need to know
that he doesn't think I need to know, you know?
Yeah, it's very, it was very, very subjective. And I mean,
generally, well, that's being a little unfair that this, it was
pretty clear most of the time what I did or did not need to
know. And but there were certainly occasions where it was
subjective. But there were also some odd rules about it kind of
going back to the earlier part of the conversation about odd
oddities with the security. Yep. One of the things that I that I
learned quickly was that unless you were actually boarding one of them, you were,
none of us were ever supposed to know all three of the following facts about submarines.
What submarine we're talking about, where it will be and when it will be there.
So if, if say, for example, that there was a ship, a submarine called, well,
no, they're boats, aren't they? There was some big divide. And I forget, I think submarines
submarines or boats, the things above water or ships.
Anyway, if one of the submarines, let's say the USS
Dallas, because I love Hunt for October.
So let's say the USS Dallas is going to be somewhere on the 4th of July.
Then I can't know where that somewhere will be.
Or alternatively, I know that there will be a sub in Newport News, Virginia on the 4th
of July, but I can't know which sub that will be.
And so, you would only ever be allowed to know two or three pieces of information.
And I never actually got lucky enough to get a sub ride when I was working there.
But if hypothetically, like some of my coworkers did, and they basically knew, "Okay, I'm going
to Newport News on the 4th, and there will be a sub there.
I have no idea which one."
And then as they were getting on the boat, they would find out, "Oh, this is the USS
Dallas."
- Right.
Okay, cool.
Yeah, I didn't come across that specifically.
I didn't have anything to do with the submarines to be honest. Mine was HF Mods. It's a good
way of splitting it up because then one person doesn't have all the information required
to actually know the specifics about what, where, when. When I was involved, I did a
a little bit of software and I did a little bit of system work. So, systems integration.
And the thing with systems is that you have to know a little bit about the fringes of
the other systems that are connecting together, but the need to know was not always as clear
because I didn't know what I didn't know and I had to rely on people that did know to tell
me that I had a need to know in order to get access to what I needed to know.
Right.
If that... and I don't actually... I'm not... the funny thing is I'm not actually trying
to be funny when I say that, that is actually accurate as to what the problem was. But anyway.
All right. So I just want to pause this for a second and talk about our sponsor for this
episode. So LIFX, spelled L-I-F-X, is a smart light bulb that gives you previously unheard
of control of your lighting. Each bulb is Wi-Fi enabled and can give you light in whatever
color of the rainbow you so desire. It's an energy efficient LED light bulb that you can
control with your smartphone. With over 1000 lumens at your disposal it's incredibly bright
but only consumes 18 watts of power at the maximum. Controlling the brightness, colour
and a range of cool effects is really easy through the smartphone app and the LIFX smart
bulb is made to last. It's ready for 27 years and that's averaging 4 hours a day. That's
the equivalent of 40,000 hours. So you're probably going to move house before you need
to change the light bulb again. The LIFX bulbs support both standard Edison
screw and bayonet connectors and will work at all standard voltages around the world
between 100 and 240 volts AC. It has a developer friendly SDK currently
available for iOS, Android and Ruby which means that if you can think of a great way
to control these bulbs you can go out and build it on whatever platform you like right
now. I've been testing some of the demo bulbs and
my kids went crazy, I put on the disco light effects and some strobing and they went absolutely
crazy. I had a dance party in the main lounge room. It was just absolutely fantastic. Lifex
bulbs are shipping today for only $99 US dollars with free shipping worldwide. Head on over
to lifex.co/pragmatic to learn more and enter the coupon code pragmatic for 15% off the
total price of your order. Thank you to LIFX for sponsoring Pragmatic. So I just
want to talk about the IT infrastructure a little bit and I'm gonna be a little
bit generic because I think it's probably better that I am. So first of
all I want to talk about Tempest. Did you come across Tempest? No that doesn't
ring any bells. Okay well Tempest is something that I came across. It's
actually believe it or not an NSA code name so not even an Australia thing it
was actually a North American thing United States thing I should say and
what it does what it is is it refers to the spying on information that is being
emanated so emanations from equipment and that could be emanations that are
either electromagnetic ie radio or or magnetic or electric fields it could be
visual or it could be sound or it could be vibration.
Anything that emanates from equipment that you're using that has secure
information on it.
So the thing that you learn a little bit about Tempest is that not just any
building can be used.
So the thing is that there are restrictions as to how close you can be
to windows, how close other buildings can be to your building.
And some buildings require, you know, fitting with, you know,
additional shielding and all sorts of other little requirements.
Now I don't have the list of requirements and I'm not going to go through them,
but that's just an idea of something that needs to be considered.
You can't just set up shop wherever you feel like it and start working on a
defense project. The whole building needs to be approved.
So that whole Tempest thing is a very big deal with IT
infrastructure. Now, beyond that,
even that's not enough in some cases because well, let's face it visually,
you've also got the ability of people to look in through the windows.
And there's ways of cutting through reflective glass and so on.
And there's methods and all sorts of things.
So what you want to do is make sure that you also have rooms for the really highest
level of security stuff.
And these are rooms that are double, triple, heavy shielding, no windows,
you know, completely isolated rooms where you can work on the highest level of
information. And that sort of stuff is was something that I was never,
I only heard about because I was never involved with.
but some of the information I was told
is essentially so sensitive
that it's not even left in the PC.
So in order to actually work on the information on a PC,
what you would do is you would check out a hard drive
and you would insert it into a special dock
and that dock would allow the PC to function.
You would work on what you had to work on
and when you were finished,
you would then check it back in
and lock it back into a secure safe.
And this is all like ultra, ultra,
you needed to know definitely,
and you had to have the highest level of clearance
to get in there.
And they were very careful
what went in and out of that room.
So you can't just go in there with your swipe card
and do what you want.
It's locked down very heavily.
So the networks are split into two networks.
And one of them I like to think of as the secure LAN,
but they refer to it as the red LAN or the red network.
And the other one was the corporate LAN,
which is the so-called the black network.
And that was just for general business
and any non-classified information.
So you're setting up a meeting and it was sort of like,
oh yeah, meeting for wink, wink, nudge, nudge,
we are all code names, these are my code name,
but you know what I mean?
Yeah, it's a meeting for blah in this room.
Yeah, that's corporate land stuff.
Whereas a secure land was of course,
for anything that was classified up to a certain level.
And if you wanted to get data in and out of that secure land
there was a massive rigmarole you had to go through
because they would lock down everything.
They locked down the USB ports,
they would lock down the Mac address.
So the switches that were connected on the Redland,
you know, they were locked to the Mac address.
So that port on that ethernet switch specifically
in that rack and that room on that floor
could only ever connect to this ethernet card,
you know, port number one of that ethernet card
on that computer.
And if it ever got connected in or disconnected
something else, then an alarm would go off, which I discovered
one day. You see, because- Where you go?
Well, yeah, because, okay, it was perfectly innocent, of course.
And that was- It was a simple mistake.
I was moving desks and I moved my computers because that's just what you do, I suppose.
And I was actually keeping the same- The move-
I was keeping the same hardware, the same cables, same everything.
But my cables, for whatever reason, were the same colour.
They were supposed to be different colors, right?
One for the black LAN, one for the red LAN,
but no, no, no, mine were both blue.
So, you know, unless you trace the cable,
you lost track of which end was which.
So all the Mac address ports had all been set up.
It was all good to go.
It had been unplugged the night before.
I was, you know, moving it in, plugging in the next morning.
All was hunky-dory,
except I plugged them in the wrong way around.
So my corporate LAN PC was plugged into the red LAN
and vice versa.
And I think it took about 30 seconds,
maybe 45 before the security guy walked up to my desk,
tapped me on my shoulder and asked me what I was doing.
- Was it your same friend that you met outside
on the way back from lunch?
- As it happens, yes it was.
- Funny how that is.
- He really didn't like me.
I just, he didn't like me.
I think that's what it was.
That's a shame.
Anyhow, nevermind.
So it was all perfectly innocent,
but yes, there were alarms set up.
Yes, they did find out, they were notified and they found me.
So yeah, they take that seriously.
So just as an aside, people that don't know
what MAC address locking is real quick,
just in case you don't,
MAC stands for a Meteor Access Control
and it's six groups of two hexadecimal digits
and that's unique to every physical ethernet address.
I think, you know, Wi-Fi as well.
And, you know, Apple doing some cool thing
with rotating MAC addresses randomly
to stop prevent tracking in iOS 8
and that's all, you know, very cool, thumbs up, awesome.
But so far as this goes, that would not work
in this sort of an environment, obviously.
that relies on the fact that MAC address is fixed.
But anyway, so did you have any experiences like that
or anything similar?
- Not really, not with regard to networks.
I know that certainly if not in the office,
but on board vessels,
that there were two different networks.
There was a, there was the kind of dirty network,
if you will, that you can run almost anything on.
And then there was the kind of clean, if you will,
classified information, things that are required for the ship
to run properly, those sorts of networks.
But generally speaking, during my day-to-day activities,
I didn't really run into that very much.
The one thing I will say, though,
is that I was one of the first engineers, or developers,
I should say, because we had other kinds of engineers.
I was one of the first developers
to get a laptop, which was a very weird thing.
And this was in, what, 2006-ish, 2007, something like that.
And it was very weird to have a laptop.
Most of us had desktops.
In fact, most of us had CRTs at the time,
and this was late enough that CRTs
were kind of going by the wayside.
But we mostly had actually IBM mini towers,
and that was our work computer.
And one thing I do-- well, I mean,
I miss a lot about that company.
But one thing I miss very much is
that because it was all government contracting,
we couldn't work overtime without permission
from the government.
And so unlike the kind of consulting
I do now where, you know, if you work overtime power to you there, you had to put your pencils
down at 40 hours and get the crap out of there because we didn't want to get in trouble for
overcharging the government.
And so that was actually very refreshing because I never worked more than 40 hours a week except
a couple of rare occasions.
Yeah, that's an interesting situation.
I haven't come across that before, not in this particular case.
I guess it was the way perhaps the contract was set up.
But in my case, no.
You want to work extra hours, oh yeah, they're going to make you or let you or coerce you
into doing it.
Some people there would really burn the candle at both ends and they didn't mind.
You only charge the same amount of time, of course, but you're going to be working those
extra hours.
Oh dear.
Anyway, that's not exploitation at all.
Anyhow, so ... It's terrible, but anyway.
So, the next thing I just want to talk about is the red tape.
And I don't know how much of this you came across, but one of the things and I've
been out, I've been working now for all, pretty well getting on 20
years, and it was the single most amount of red
tape of any job I've ever had to work in.
And- Yep.
Yeah, you know, it's like if you wanted to, you know,
release your build of what you're working on.
There was all of these forms you had to fill in
and they had to be signed off and so on.
When you are actually doing all of this work,
you had to get all your interfaces set up, right?
So these interface specifications that had to be,
they were just so detailed.
And the reason I suppose in that case was that
each of the individual teams didn't know all the details
about all the other sub teams were doing.
So if your interface specs between your different sub teams
weren't actually detailed enough,
then I guess you could get caught out
and you might have something where,
this message doesn't actually respond
with the right information or whatever.
So they spent all this time
and that required all this extra rigor
and all this red tape and it was frustrating as heck.
Did you go through something similar?
- Oh yeah.
You have to understand that when I went to this company,
this is my second job out of college, out of university.
And the prior one was working on slot machines for the Oklahoma
Native American casino market.
Wow.
And the group I worked with-
So, just to interrupt you for a second, you got to listen to the last episode I just did about slot machines then.
I saw that that was one of the things you talked about, and it immediately piqued my interest.
Sorry to interrupt, sorry, keep going.
No, no, not at all.
So, I went from that, which was a bunch of old game developers, not old as in age, but like, you know,
prior prior experience was doing real video game development.
Um, at some point their company got bought up by EA and then the EA shut
them down like they do to everyone.
And so it was a bunch of these generally speaking, uh, guys that were in their
mid to late thirties who really generally speaking, didn't have wives or girlfriends
or anything like that, and they worked constantly and it was, it was an
adventure, but they were extremely knowledgeable, extremely, extremely
knowledgeable and very casual about things because the shop was all of 20
people or something like that.
So then I go from that to, to this big government contractor where I couldn't
check in a piece of code unless I had an issue request to associate with it.
So if I see a typo that's on the user interface, I can't just go
in there and fix it real quick.
I've got to raise a bug.
It has to go through the change review board or whatever we called it.
They have to approve it.
It has to be scheduled, prioritized and approved.
And then at that point I can go in and make that change.
And I left the company I'm speaking of mostly because we were
moving to where we live now.
But I think I don't, I don't think I would have lasted too much longer
anyway, because of all the red tape.
We did code reviews for every line of code that ever got checked in,
which at first I hated in, in the end, I actually ended up liking it.
But it was also, it was kind of like handcuffs because anytime I wanted to
get anything done, even fixing a typo, it still had to go through code review.
And you had to set up a coworker and a superior.
You had to get the diffs squared away.
They had to be posted on a shared drive so they can look at them in advance.
Then these people had to look at them in advance and figure out what they
wanted to complain about, if anything.
And my code when I was writing non-trivial things got demonstrably better because of these code
reviews. So again, I don't really besmirch the idea, but nevertheless, there were times when
all I wanted to do was change a darn typo. And it was still hours upon hours of work between
the reporting of the bug, the change review board, the opening of the bug, fixing of the bug,
checking in of the bug, code review of the bug, and all of this is to change, I don't know,
favorite to not have a you in it or something like that. You know, I mean, it was the most
ridiculous thing in the world. But it was for a reason.
That's what you think.
Yeah, man, you just put that on the table. So, hey. But yeah, hey, exactly right. And it was
the same for me. And I'm fortunate, I say fortunate, I guess I was involved in a very small
part of a set of drivers essentially for a small piece of equipment involved in a particular
subsystem that Charo may name us. The point is that I was just, I was not dealing with
this on a daily basis, but I worked in a team of engineers, developers that were working
on with this stuff on a daily basis and you never heard the end of it. And although I
only went through it a handful of times, what you just described is very, very similar to
what I went through also on the systems engineering side, because I was writing a whole bunch
bunch of documents about different interfaces and requirements and such and
it was the same kind of issue. I needed to get signatures from seven department
heads in order to get the changes incorporated into the document by the
document control team and this is sort of when I had that the epiphany is that
working with the military is like working with a government department
essentially and it comes along with all of that red tape that comes with it. It's
It's not just about classified information, secret, secure information.
It's not just about that.
It's just process driven to the nth degree.
And just when you thought it was not possible to add more process and more red tape, they
added it.
It's just unbelievable to me.
Yeah, absolutely.
And I think that there are several reasons that that happens.
I think the biggest and most obvious reason is it's fixing everything by process.
time anything ever goes wrong, well, now there's a procedure to prevent that.
And it was more deliberate and less organic.
And as I've gotten a little bit older, I happen to believe that having just a
more organic error handling approach where you learn from your mistakes, but
you don't necessarily add process because of it, I think that makes a little more
sense, but anyway, so there's a lot about process and a lot about fixing or
preventing future bugs and issues.
But I think a lot of it is also that the
government is a big entity, or at least here
it is, and it employs a lot of people.
And the easiest way to employ a lot of people
is to have a lot of checking and balancing
going on all over the place from the top, all
the way to the bottom.
And I think some of it, not to say that it
was necessarily deliberately written for
that purpose, unlike where I believe that a
lot of the process is deliberately written to
prevent some issue from happening a second
time. But I think the kind of, maybe I don't know if subversive is the word I'm
looking for, but it's the best one I can come up with.
But the subversive purpose of it, of all this process was just to keep that big an
organization that big.
Because to bring the process back and lean it down means somebody's losing their job
because they just don't need to have all these checks and balances anymore.
I mean, I'm with you on that, mate.
I mean, seriously, I do wonder how much process is there for process sake.
I don't, and this is going to sound a little bit odd, I guess, maybe coming from me specifically,
but I guess I see process as being something that you should try and keep at high level
so that people are on the same path.
But if it has to be so specific and so detailed and have so many other requirements, then
process becomes for its own sake.
And it doesn't actually add any appreciable value.
It actually starts to subtract value.
striking that balance is always going to be difficult.
But honestly, I honestly think there's another angle as well to it,
is that you create process in a lot of cases to spread accountability.
- Oh, that's a very good point. - Yeah.
So, yes, like someone will say, "I'm concerned about this
because I'm not an expert in this particular thing.
So, I'm going to put it out for a review
and I'm going to spread this accountability across multiple different people.
Okay, so let's go and do that. Now I'm going to say, okay, you know what?
I'm doing this a lot of the time. So what I'm going to do is,
I'm now going to create a process.
This document in this topic must be reviewed by a minimum of these number of
people. Great. Now I'm covered. And it's like, okay, I've done it.
And there's an earlier episode on design reviews and name only.
And it's the same kind of idea as well.
So if you want to go back to listen to that episode again,
if you want that particular episode,
that I went through this,
and just to touch on it really quickly again,
is that just because you give someone something to review
doesn't mean they're actually gonna effectively review it,
because people have other things that they need to do,
like, well, I don't know,
getting their own documents reviewed,
actually being productive,
that's another thing they might wanna do.
And you don't always have time to go
and do a thorough review of other people's stuff.
So it comes down to, I now am waiting on signatures,
and that's another thing they love,
is damn signatures and everything.
It's got to be wet ink too.
Did not this digital signature stuff.
No, no, no.
(laughing)
God.
Yeah, anyway, that's another whole episode.
Yeah, I should do one on that.
Wet ink versus digital signatures.
Goodness me.
Anyway.
So yeah, it just, it reaches that point
where if you spread accountability wide enough,
then no one individual can be to blame.
So, you know, I missed this on this document.
We went through and accidentally something sank
or, you know, exploded or whatever.
And then they do a big review and they say,
"Oh, well, it went out to review."
know multiple people would have blamed we're gonna sack all of them well I don't know maybe not maybe
we should fine all of them no I don't think so that is so cynical of me well no but I think there's
some some modicum of truth to it if not a lot of truth to it because you know again part of the
reason the government entity is so big is just like you said to spread that accountability so
no one head is going to roll if something goes pretty badly or at least mildly badly now maybe
there'll be one singular human that takes the blame if the submarine runs aground. But in normal
circumstances where something inconvenient happens, well, just the whole department as a team is given
a stern tongue lashing and that's about it. - Yeah, that's it. Yes, well, honestly, yeah,
I don't know what the answer is because when I actually left Boeing, one of the big reasons was
was the red tape. And, you know, because it just, it just drove me out the wall
because I was getting feedback on the grammar in my
sentences. And this is the thing that used to really irritate the heck out of me.
And I'm trying so hard not to swear right now because it was really, really annoying.
I'm writing a sentence, okay.
And there was this one particular guy, department head, who was, who
saw himself as a grammar Nazi, but in the end, he was not fully qualified to be a
Grammar Nazi. So depending on the phase of the moon, the color of the moon or the
direction of the wind, he would say, "Oh no, this is the right way it should be
worded." And you're like, "Okay, I'll word it this way just for you." And you would go
and you'd do that update. But of course that would mean you have to go and get
all the departments heads to review that change and get their signatures again.
"Okay, no worries. There goes another week of my life." Because you had to have a five
working day minimum waiting period to give them opportunity to review it. Great.
So, you go back again the following week, you know what? He changed it back to how I
originally had it. And I just went down to his desk, I put the two in front of
him, both with his signature against the markup and I said, "Pick one now!" And I'm
like 22 or something. I was... Yeah. So, you know, that may have sounded
aggressive, but believe me, it was a lot more aggressive when I was younger. And I
don't think he was my friend after that. I certainly wasn't on his Christmas list.
But the point was that that was a sort of frustration that drove me to leave because it's it's just it was these people
Were not adding value. They were just
picking that my the way I structure a sentence does not change the intent of
The sentence of the detail of the design that I'm doing. So why are we reviewing this? Why are you reviewing this?
What value are you adding? Come on
So anyway
And that's when the process is just for the sake of process and I just had to go and I and actually
It was really good for me actually, because when I left, I then went to work for a company called MPI Engineering,
and that's when I got back into control systems, and it's more or less been the sandbox that I've been playing in ever since.
It's more on the software side, more in controls, and out in the cutting face, making machinery work, and that's, you know, very little red tape.
So, yeah, much better than that.
It's funny because I, being a consultant, I occasionally will work with, say for example,
a really big financial firm, and I see a lot of the same issues there, a lot of the same
red tape, and additionally, a lot of the middle management glut.
And I did a project at, about a year or two ago, somewhere local, and every meeting we
had, had what I would consider middle managers in it.
And usually like four or five of them.
And I think that in most cases, most of these middle managers deep down inside knew they
were expendable and that they were one of 15 people just like themselves.
And I think that a lot of times what they would do is they would pipe up and make a
stink about the silliest things.
And I genuinely believe the reason they did this was because they wanted to show everyone
else around them, they're worth something.
And so they would just pipe up at, let's say about a grammar
issue and have a fit about this grammar issue.
And because they think in their heads, well, everyone saw me make that smart,
you know, make that smart catch on that grammar problem.
They can't get rid of me.
They'll have to get rid of Joe or Susie instead.
And this isn't a place that was like living on cuts.
So it's not like there was a pending, um, layoff or anything like that.
It's just that I think that they deep down inside knew that they
were kind of redundant. And so, they did everything they could to seem not redundant. And oh my
goodness, it was very, very challenging. Even as a consultant where I knew I was getting
out as soon as the project was done, it was still very challenging.
Yeah, I did. I've done a few years as a consultant and during that time, that was something it
was nice to be on the outside of. But the funny thing is when I was working for that
consultant for two years there I was actually back in the cutting face doing
programming again. That's one of the things where you never admit that you
actually know how to do something because then they'll make you do that
something that you know. So it's like oh yeah experience with with SciTech SCADA
oh great you can fix up this enormous drama we have. Yeah it's like I came here
to do work in in this area and now I'm back to okay yeah because you know the
bottom line you know you want that paycheck at the end of the day so you
you shrug your shoulders like here we go again roll the eyes and you just get typing but anyway
yeah but it is it is terrible that whole minimal management bloat and that's another topic all
unto itself but the the thing is i do wonder though people listening to this that haven't
actually had the um i'll say pleasure quite a pleasure of working in on military development
is some people look on it with a sense of um i don't know it's like it has a sort of an allure
to it. It's like, "Oh cool, I'm working on a stealth airplane or something, or I'm working
on some submarine or something for a submarine, something for a plane that's really, really
cool or ammunition or whatever floats your boat." And it's like, "Oh, this is so cool."
Once you realize that, and you get on the inside of it and you've gone through all the
rigmarole to get clearance and everything, and you realize, A, you can't actually tell
anyone about it. B, there's so much red tape you have to go through and so much BS you
have to deal with on a day-to-day basis, it really can be quite frustrating.
You get to the end of it, I'm sure a lot of people get disillusioned, but the funny thing
is they still seem to have a lot of people that stay in that environment.
So I came to the conclusion that it's an environment that works for certain people.
I was not one of those people.
It sounds like you weren't probably either.
But if you're ever interested in doing that sort of thing, hopefully, if nothing else,
episode has given you an opportunity to kind of get a handle on what you could expect and
whether it's your cup of tea or not, or cup of coffee or cup of
Leucazade or whatever the heck you drink, you know, Mountain Dew, possibly, I don't
know, maybe not.
Yeah, but there's certainly some good things that came of my experience for sure.
And one example is everything that was done and that happened was deliberate.
many cases, I think it was taken way too far, like we just discussed, but it was deliberate.
And when a lot of developers oftentimes are kind of shoot from the hip and just, ah, screw it.
Well, I'll write some code. I'm sure it'll figure itself out. And that's not at all going to cut it
when you're working on things for an aircraft carrier or submarine or a stealth bomber or
what have you. And so they were very deliberate, which was something, which is a skill that I
think I've carried with me, or certainly a state of mind I've carried with me ever since.
And the other thing that this company was, for better or worse, they were extremely good at
reproducible results. And so if you look at on my podcast, ATP, in episode 55, when we talked about
software methodologies, finally, we talked a lot about how Agile and Scrum is a really good way of
learning from the past and trying to handle something that is
kind of inherently out of control. Well, once you get to
this sort of an environment, a big government environment, the company I worked for was CMMI
level three, I believe, which I forget. I don't even remember what CMMI stands for,
but what it basically says is how mature is your process? And at a level three, I believe
It said something along the lines of when you estimate something's going to take a thousand
hours, 80% of the time, it's going to take within 5% of a thousand hours.
And again, I'm kind of getting hand wavy with the details because I don't recall the specifics,
but that's the idea. And so it was very deliberate and it was very reproducible.
And that's something that I think all software developers should aspire to be is both deliberate
and be able to reproducibly estimate and also execute on projects. I think that a lot of the
red tape, just like you were saying, John, I think it was overkill. I think it was ridiculous,
but there's certainly a happy side. There's a yin to that yang, if you will.
Well, I'm glad you actually brought that up because I guess I did kind of paint that as being
perhaps less than an optimal experience and perhaps you should have different expectations.
But the bottom line is you're right, absolutely there were positives.
And one of the things that I did take away from it is the thoroughness with the documentation.
And that is something that I've tried to carry with me since.
Again, I don't always succeed. I'm human. That's fine.
And I get affected by bosses screaming at me at times saying, "Get the damn thing out the door."
Yeah, it happens.
But, you know, it's something that I am far more thorough than I was as a direct result of that working on that project and working in that environment.
environment. You also mentioned the whole code review thing and that's something else
as well is that we also did code review and in some cases it was line by line and I know
that my drivers had the once over and it was frustrating but it was also enlightening at
the same time because you get different people's perspectives. I mean just because this is
the way you're going to do a nested if statement or whatever else, you're going to have a switch
statement or whatever the heck you're doing so I was programming in C and it was you know whatever
whatever whatever you know someone else's approach to it and I'll say well here are the reasons why
I would suggest the following and you would learn something from that and you would go away and you
it would make you a better programmer because the thing is if you don't do line by line reviews of
code that stuff just doesn't come up people will just tend to be very you know hand wavy and say
"Oh yeah, I just didn't like the way you wrote this."
And they tend to be very vague.
Whereas if you're on a line-by-line code review,
they have to be specific.
Look, what specifically is wrong
about the way that I've structured this
or the way I've defined this
or the way that I've laid this out?
What specifically is the issue?
And I found that to be valuable as well.
And honestly, I think that more places
should do detailed code reviews.
But if you're gonna do them,
you gotta have the right mix of people.
And again, that's something that I discussed
in a previous episode, but in any case, yeah, it wasn't all bad.
You're quite right.
And there are good lessons to be learned from that.
And predicting time is always difficult.
And that's something that I'm eternally working on.
And I hope one day to master,
but I fear perhaps it is an impossible thing to master,
but certainly there's still room for improvement.
So I'm going to go with that.
And I mean, if I could get my estimates within,
what was it? 80%, let's say, then, geez,
I'd be happy with that.
I really would, 'cause seriously.
- Me too.
- Yeah, geez, it's so hard.
But 'cause you have people change
and deliverables change
and different project pressures change.
And you just- - I don't know,
if you're anything like me,
I always think I'm much better at what I do than I am.
And so I'll be like, "Oh yeah, that'll take me 40 hours."
And then inevitably it takes anywhere between 60 and 80.
And so it was not too long after I started developing,
doing this for a living,
that I just started multiplying
whatever my internal estimate was
by either a factor of one and a half to two,
to give, and that would be my reported estimate.
And so that 40 hour estimate,
I think to myself, yeah, I can do that in about a week.
Well, then I'll tell my boss or coworker or whoever,
yeah, that's gonna take me about a week and a half
to two weeks.
And more often than not,
I actually end up right that way
by almost doubling what I think it should take.
- Yeah, the old rule of thumb I was told
was double it and add a bit. And it's generally good advice. But I'll tell you what,
never, ever, ever tell anyone that that's what you do.
Because I made a mistake once of mentioning it to one of my
engineering colleagues, not, I will note, not the project planner, not the project
manager. And, you know, Mr.
Loose Lips Sinks Ships goes and says, oh, hey, did you know that John does this?
There's time estimates. And I'm like, burying my face in my hands.
And I'm like, you jerk, how can you do this to me?
So, of course, now he starts deconstructing all of my schedule estimates.
And I said, you see what you've done to me?
And he shrugged like it was no big deal.
And then for the rest of the time I was there anyway.
Yeah, it's tough.
It's over.
Especially, especially if you tell someone that's not a developer.
I got made the mistake of saying to a project manager,
you'll be thinking it through out loud.
Well, I think that'll take about 40 hours.
- Yeah, it'll probably be about two weeks.
And they'll be like, "What?
"No, no, no, no, no.
"You just said about 40 hours."
"Well, yeah, but I'm always wrong whenever I say that.
"So I always basically double it."
"All right, so 40 hours."
"No, you don't understand.
"It should be double that."
"Okay, fine, fine, fine, fine.
"I'll give you 45, maybe 50."
"No, it should be double."
"Okay, 60, but that's as high as I'm gonna go."
- Oh, the negotiation.
The negotiation, oh, it's so infuriating.
'Cause it's like, I need five days to do this thing.
'Cause of course I'm careful.
We'll keep it as an inner monologue, right?
Okay. So, I need five days and it's like Project Magic says,
really need it done in two. And I'm like, okay, so let's just
play back what's just happened here, shall we? Okay. You asked
me how long it's going to take. I told you honestly how long I
thought it would take. You're now coming back to me telling
me I can only have two days to do it. Well, here's the thing.
Next time, don't bother asking me. Okay, because you're just
going to put down two days and I'm going to be screwed either
way. Thanks. I see how this works.
Oh, it's the worst. And I'm totally derailing us now. And so
you'll just fix it in post. But just the other day, I was having
a marathon meeting at work. And we were doing sprint planning
where we estimate how long each user story is going to take. And
then one of the things we also come up with is what do we
think, or what will what one of the things we were told to come
up with is what we think our velocity will be for that
sprint. So that's to say that if each work item, each user story is, you know, so many points,
how many points of effort do we think will complete? And so the developers in the room
were looking at the project manager saying, well, how many did we do in the last couple of sprints?
Well, the fact of the matter was we weren't going as quick as we wanted, and it was starting to look
a little bad for the project managers to have this conversation. So they were like, well, no, no, no,
we're going to do better than that. And I'm thinking to myself, the whole point in agile,
The point of Agile, in my personal opinion, is to look at past performance as an indicator for future performance.
Yes.
And so, we know that, and I'm going to make the numbers up, we know we've done 10 points for the last two sprints.
And you're telling me you think we're going to do 30 just by pure magic this time?
Okay.
Yeah, that's it.
Oh, it's the worst.
I know.
And project managers that have never been in the thick of actual software development are the worst of the worst.
So, you know, that is, goodness me.
I hear you, mate.
I'm sorry, this got negative.
Let's end on a positive note.
I'm not sure what that positive note is yet, but let's end on a positive note.
Positive note.
Okay, well, just to do a quick recap then, there are good things about working in a military-based
software development environment.
It will teach you a lot more about thoroughness and consistency.
And there are downsides, but because we're focusing on the positive, if you want to have
listen to the downsides, you'll have to go back about 10 minutes
where we talked about the down. Does that work?
Yeah, something like that. Well, it actually so here's an example
of something that was good. One of the things that I got to do
as part of my job was I had to babysit a deployment and that
involved for the particular stuff I was working on going on
a destroyer for an overnight cruise. And so I went I went down
to one of the ports on the eastern seaboard got on this I
I think it was a destroyer.
I'm not, despite having worked at this company
for a couple of years, I'm still not good.
- Did it destroy anything?
- No, not while I was there.
- Well, then it's not a destroyer.
It doesn't destroy anything when you're there.
Anyway, sorry.
- Yeah, no, I'm with you.
But no, either way, I got to go on this ship
and spend overnight on the ship.
And it was doing like some high performance turns
and like high speed runs and stuff.
And it was extremely cool for 24 hours.
Much more than that, I think I would have been miserable.
But for those 24 hours, it was freaking awesome.
And so that was something that, I mean,
what job do you get where, other than being in the military,
where you as a civilian can go onto a United States
or Australian Navy ship and go for a spin,
just for funsies, 'cause that's kind of what it amounted to.
- Yeah, it's a very good point.
And on the project that I was working on,
it was spread over multiple locations,
spread around Australia.
and I had the opportunity to go to two different locations,
undisclosed locations, and see different parts of Australia
that I previously hadn't seen.
And one of those areas I haven't even been back to since.
Absolutely stunningly beautiful remote part of the world.
And if not for my involvement in that project,
I never would have been exposed to that.
And it was quite an experience.
And I thoroughly enjoyed that as well.
So certainly the opportunity to see things
that normal civilians don't see is kind of cool.
I'll also agree with that.
And that's actually probably the best point to end on,
I think.
(laughs)
- See, we got there.
- We got there, fantastic.
Okay, well, if you wanna talk more about this,
you can reach me on Twitter @johnchidjie
and check out my writing at techdistortion.com.
If you'd like to send any feedback,
please use the feedback form on the website.
And that's where you also find the show notes
for the episode under podcasts pragmatic.
And if people wanted to get in touch with you, Casey,
how would they do that?
Sure. Well, the easiest way is probably on Twitter. My handle is @CaseyLiss, C-A-S-E-Y-L-I-S-S.
I also occasionally write for my website, which is ohsocreatively@caseyliss.com. And
then you can catch me on my podcast with friends, the Accidental Tech Podcast, which is at ATP.fm.
Fantastic. Cool. I'd also personally like to thank LIFX for sponsoring this episode
of Pragmatic. If you're looking for a great LED bulb that's energy efficient, remotely
colorful and just plain fun to use. Remember specifically visit this URL
lifex.co/pragmatic and use the coupon code
pragmatic for 15% off the total price of your order. So thanks again for
listening everyone and thank you Casey for coming on the show. Thanks for
having me on. I had a good time. Cool, me too.
(upbeat music)
[Music]
[BLANK_AUDIO]