[this interview is available online at https://s.apache.org/InsideInfra-Drew ]

The second in the "Inside Infra" interview series with members of the ASF 
Infrastructure team features Drew Foulks, who shares his experience with Sally 
Khudairi, ASF VP Marketing & Publicity.

- - -
"I am in the business of making life easy for people who do phenomenal stuff."
- - -

 - What is your name --how is it pronounced?

My name is Drew Foulks. “Droo Follx”.


 - If folks were to find you at the ASF, like on Slack or elsewhere, what's 
your handle? How do they find you?

They'll find me at Warwalrux, spelled with an X, so W-A-R W-A-L-R-U-X.


 - So, "War Walrus", but with an X at the end. Where did that come from?

Kind of embarrassing story actually. I got picked on a lot in middle school 
because I was always really good with computers, but as bad as it sounds, I 
never really wanted to be. I always wanted to be one of the one of the cool 
kids and the cool kids were not going to computers. One day I got into a fight 
at school and one of my friends just absolutely made me lose it afterwards. I 
was sitting there on the ground crying and he said, "Man, you were a fighting 
walrus, like the walrus of war or something. It was awesome." I lost it. But 
ever since then, I’ve just been like, "You know what? I'm not even going to be 
ashamed about that anymore." I've been that since I started doing tech, which 
was actually not that long ago compared to the other guys on the team.


 - How long have you been in tech?

I'm 29, and have been in tech since I was 16, so 13 years.


 - When did you get involved with the ASF? How did you get here?

I was working at NASA for four and some change years, and I decided that I 
wanted to pursue some other opportunities because they really were not 
supportive of that work from home culture. And at the time I had a lot of stuff 
going on. My wife was sick, my daughter, my youngest, has special needs and 
stepson actually also has special needs, so being at home was something I had 
to do. A buddy of mine tipped me off on a Website called We Work Remotely. I 
ran across your ad there and thought, "There is no way that is who I think that 
is and I'm going to apply for the hell of it." Surprisingly, two months later, 
I got a call back.


 - You do understand how many interview candidates we had, right? A lot of 
people were competing against you.

It blows my mind. I heard the stories after I got hired and I was just like, 
"Man, that's nuts." And then when I got hired, I was actually told, jokingly, 
of course, the ASF was looking to launch its own brand of internet satellite. 
So that’s why we hired people from SpaceX and NASA.


 - The Infra guys have such a dry sense of humor! How long have you been a 
member of the team?

One year and one month, 13 months.


 - For some reason it feels like you've been part of the Apache family for 
years. What's your role in ASF Infrastructure? What are you responsible for?

My latest contributions have been the Website builders, so I'm working on 
helping people migrate off of CMS. Some of the ways that I've chosen to do that 
are by working with Humbedooh (the handle for ASF Infrastructure team member 
Daniel Gruno) on his ASF.YAML project, that so many projects seemed to be 
really enjoying.


 - YAML? Yet Another Markup Language?

That's it. Yet Another Markup Language.

So basically, I built the system that lets you build Websites from ASF.YAML and 
you just specify your Website builder, whether it be Pelican or Jekyll --those 
are the two that we support right now. And you give it a source branch and a 
target branch and every time you check in, boom. It builds your website.


 - Who is this aimed at?

This is for Apache Projects building their TLP Websites. When you commit your 
Website to the repo, say any project, they've all got Websites, but some of 
them are generated via Jekyll. Some of them are generated with Pelican, some 
are generated in a custom way with a Jenkins job. It's just how each project is 
determined to generate their website, but we're trying to make it easy and 
provide lots of options for projects to migrate off of the old CMS. But still 
projects are allowed to be able to choose their own method of publishing or 
their method of creating a site, but you have to be able to enable all of that 
to happen. 


 - Did you have to learn this or was this knowledge something that you came 
into the position with?

I learned it.


 - Was it difficult? How long did it take you to get this project up?

The Pelican one was a lot harder than the Jekyll one. So, Pelican took a couple 
of months. Really, Greg had a prototype when I came in that apparently had been 
kicking around for a little bit, so I tightened it up and pelicanized it. I 
think it works pretty well. I've not heard any complaints about it.

That took a while before I wasn't doing primarily Python programming, I was 
doing lots of different ops things just in a completely different way than what 
I do now. To be honest, I still haven't wrapped my head around exactly what it 
is I do here.


 - Do you mind sharing a little bit about that?

I came here from the government world, which is very silent. I worked for the 
OCIO, Office of Chief Intelligence Officer Data Center for NASA Langley, which 
is a very old NASA center. Older than NASA itself actually. Their 
infrastructure, as you can probably guess, is not the newest: It's 100 years 
old. They have wind tunnels from the 1920s. There are parts of the 
infrastructure that are 100 years old and it's insane. Everybody has a 
specialty, everybody's a subject matter expert in something, and there's 
nothing more permanent than a temporary government program, so if you take 
something on, expect to be doing that for the rest of your life. It's very 
regimented. If you've ever seen Hidden Figures, the computational research 
facility where they've opened the Katherine Johnson Research Center, was my 
data center.

And then to come to the ASF, it's like, "Okay, so we've got like 11 different 
Cloud providers and these are all the projects that we're supporting. Do you 
know this, this, this, this or this?” Jenkins, Buildbot, VMware, any of the 
Docker, Puppet and all that stuff. Do I know any of these myriad Open Source 
technologies that one doesn't really get to use a lot of in the government 
sphere. I mean, I've been doing Ansible there for three years.

It was very monolithic. We had VMware. I ran a data center. I had hardware. I 
had to track all of that. Coming here, everything is completely different. It's 
like, "We're juggling all these different Cloud providers, and oh, wait: we’ve 
got to migrate out of this one today, so let's do that. Okay. All right. Where 
are we going with this?" It's just like there's no end in sight. As technology 
progresses, so do we. It's just that we do it so much faster than anywhere else 
I've ever been.


 - Is that exciting or scary?

Oh, gosh. I've never stopped long enough to think about it. It is a bit of 
both. It is intimidating for sure, because before it was very silent. Like I 
said, I did my thing and I had my interests, my extracurricular interests, 
running home network setups and private media servers and whatnot. Then I come 
here and those hobbies go away, now I'm doing that for the Foundation instead.


 - Yeah, that's cool, though.

It is. I'm a professional hobbyist.


 - To get paid for doing your hobby is pretty rewarding.

It is. Yeah.


 - This has become your hobby in a different way, of course, because I'm sure 
you weren't planning on dealing with ~11 different Cloud providers.

No, I was not.


 - In our chat with Chris Thistlethwaite last month 
https://s.apache.org/InsideInfra-Chris , we learned more about who ASF Infra 
serves and the scope of the work that you provide. Can you tell me more about 
the who and how it works exactly? So, who Infra serves and to what capacity or 
what is it that you guys do? Because I get every person's perspective is 
slightly different because I get the same, we do it all answer, and is that 
true? I mean, you're saying that so far, it sounds like it's true. I guess no 
one has a reason to expand upon it in terms of embellishment, but tell me more.

We serve Apache project developers and development teams. It's not just the 
people who sit down and write the code, the people who orchestrate these very 
complex processes of building testing, checking, doing the sanity work behind 
the scenes, the people coordinating releases, PMCs planning out the future of 
these projects, we serve them, too, and we have to serve them in a capacity 
beyond, "Hey, here's a build platform," it's: "We support your email 
communications, we’re there to facilitate the goings on of the Project." 
Infra's domain is almost everything but the coordinating and writing of code.

Taking care of their code management systems, providing them with the means to 
do build testing and having it not kill us in the process. That's a big, big 
addendum to that requirement. Like I mentioned, email, I call them the central 
services, things like LDAP, authentication, your virtualization services, file 
sharing, all of those things that make the business of a TLP easy(ish). I am in 
the business of making life easy for people who do phenomenal stuff. That's 
honestly how I view my job and it's very, very different than my old one.

In my old job, I had one customer who I bent over backwards for; here, it's 
very much, "Listen, my job is to provide these services and to facilitate what 
you guys do, not do it for you." Drawing that line sometimes becomes difficult 
for me personally because I don't have as much experience in the ASF, I think. 
But that seems to be a skill that the other guys have is when to bounce back 
and say, "No, this is definitely a PMC or a PMC issue that you guys should be 
dealing with because it sets a bad precedent if I make this decision. I'm not 
going to do this work for you." It wouldn't be a right to pollute a project 
like that.


 - What you're saying doesn't come across as odd. One thing that I always want 
to know is how ASF compares with other infrastructure operations in general. 
Chris had said this also, here you have 300+ projects and all sorts of 
different groups that you're interfacing with, so it's a completely different 
type of interaction. Your response is totally legitimate: it takes a certain 
type of personality to be able to handle that because most people would likely 
be overwhelmed and run away. The fact that you're here and thriving and our 
projects are expanding is awesome.

Thank you. You can thank my wife for not letting me run away.


 - Based on my understanding, as a team you're autonomous yet coordinated. Is 
that the right way to describe how you work together?

Yes. That is a good way to describe how we work together.


 - Do you feel like that model works or do you think something else should be 
happening or how does that work for you?

That's a tough question because I'm not sure that the answer would make any 
sense, but I'll give it a go anyway. By constantly talking with each other, the 
team gets a sense for the direction that we need to be heading. Leadership is 
very organic and not spontaneous, but they're like a current guiding us towards 
the goal, really, whatever that is, so all of the decisions that we make on the 
daily really kind of help us towards that goal, because fighting the current is 
difficult.

In a lot of ways that long-term coordination is really facilitated by this, I'm 
going to call it “on a current of progress”. It's not forceful. That's kind of 
what it feels like. The team is driving towards something, it's not random, to 
be honest with you. It's typically a goal that we have in mind, but all of the 
work that we do is just like, "There's a cool idea that I had related to this, 
so let's just work on that." And we end up getting there. It's crazy.


 - Describe your typical workday. Are you on a rolling schedule? Do you guys 
work on a shift? How do you get it all done --and you're down one person now-- 
how do you get it done?

I have no idea. So really, personally, I have a nine-hour a day week schedule 
that I follow every day. So basically I start work and I break it up into two 
or two-and a half hour chunks and I do four of those, take little breaks in 
between, try to keep myself sane, try to throw in a dog walk. Really, I just 
approach it like I approach any other job, one ticket at a time.


 - Do you work in shifts? How do you cover those 24/7? How do you balance the 
load?

So there's a one week on-call rotation. So right now there are the... gosh, how 
many of us are there? Five? Anyway, so there's one week on-call rotation and 
that person is on 24/7 for the week, Monday to Monday. And then after that, 
it's pretty much just you cover your time zone. Yeah. So the scheduling, it's 
so loose that I mean really as long as you're putting in your eight hours a 
day, nobody really cares when you do that. I choose to have that nine-hour work 
day because kids really. It's fantastic for having a family, but whether you 
want to jump on at 1:00 in the morning and work for six hours, that's fine.


 - OK, so as long as someone's there, and it doesn't have to be you, you can 
work on your own timeframe. Are you guys usually slammed? Is it low-level? Is 
there a busy time for Infra on the whole? Is it like tax season if you're an 
accountant, or is it constantly just 24/7/365?

It's pretty much 24/7/365, but we do definitely have “seasons” as well. We do a 
one week on-call rotation, so somebody's always on, but the scheduling is very 
relaxed. So, it's optional, the hours you'd like to keep. I choose to work a 
work day because of the family and that just kind of fits in nicely actually. 
Some people may decide that, "I'm awake It's 1:00. I can't sleep. I might as 
well get some work done and I do that." And I've certainly done that before. 
So, yeah, it's pretty whatever and we're all kind of, I don't want to call us 
workaholics because I think that's a bad word, but we're all …

 - “Work enthusiasts.”

I don't know that I've called them busy seasons as much as busy cycles.


 - What are they? What triggers them?

Typically? Releases. The most tickets coming in is when some project is putting 
out a build or is putting out a release. For a large project release, we'll 
have a lot of tickets sent in because they're utilizing a bunch of resources 
and stuff gets backed up. That's typically it.


 - So whoever is on call during that time period, it's really their 
responsibility to handle: it's not like when Apache Wombat or whatever Project 
has an issue, it becomes "Drew's issue". You're not assigned to a project to 
facilitate that, it's whomever is there will help them however possible, 
correct?

Yeah. And I think that you said it earlier: everybody that you've talked to 
says that we do it all. I'm going to tell you that we do it all. It's every 
project from Apache Zeppelin to Airflow, whatever the first one is. That's not 
our work.


 - I don't know if this is actually the case, but I'm curious: is it possible 
for an ASF Infra team member to be an introvert or do you all have to be 
"client-facing"? I know that we don't have an office, and you see people from 
time to time at ApacheCon, but do you have a wall that you can hide behind or 
do you have to interface with people all the time?

Did you go to the end for Lightning Talks?


 - I was not at Lightning Talks at ApacheCon/Vegas, but I heard it had quite an 
activity that happened there, Chris told me about it during his interview, 
let's put it that way. No one said anything to me up until that interview, so I 
was surprised. Fill me in with some more. What do I need to know?

[laughing] So, an introvert and two extroverts that are way too drunk, get up 
on a stage in front of people and proceed to just make fools of themselves for 
a minute. That's pretty much it.


 - I guess I know who the introvert was.

Yeah. So the original plan was to go up there and make thunder noises because 
that is the sound of lightning talking. That was a fun experience. Not one that 
I would do again, I think but it was fun.


 - Let's go back to the daily schedule for a minute. This is always a curiosity 
for me for anyone who's super busy, which is pretty much everyone at Apache: 
how do you keep your workload organized? Your structure for your day is very 
impressive, I have to say, this two-and-a-half hours times four. I think it's 
fascinating. But your actual workload, for example, you get one of these huge 
releases, how do you manage all that?

Okay, so the first part of my day is typically spent organizing my day as awful 
as that sounds. We get so much email that I think that it's literally 
impossible to read it all. I'm pretty sure it's literally impossible to read it 
all and so much email, so the first order of the day is sift through that while 
you drink your coffee because there's no way I can get through that. I catch up 
on the stuff that the team has been talking about, catch up on all the slack 
channels, look at my tickets, prioritize my workload, and that usually takes 
about an hour. So right at 8:30, I'm ready to actually start doing stuff. Then 
it's usually tickets and then a break. And then I don't like to check my email 
too terribly often. I wish I could three, four times a day, because I think it 
gets me off task, but that's not really something I have the luxury of being 
able to do all the time, so I do have to monitor my Ubuntu alerts as emails 
come in, scanning for anything important. But yeah, it's ticket work for the 
first half of the day, a project work for the back half of the day. And then 
right after lunch, I'll sit down and I'll figure out where I am on my project, 
and then try to move forward from there. Typically, that involves research, but 
yeah, I like to spend the last couple of hours of my day trying to do 
something. So, typically project work, because I don't like doing ticket 
changes at the end of the day.


 - Why is that?

Well, if you're going to nail your foot to the floor, don't be surprised when 
you can only run in circles.


 - I presume when you do ticket work, more things come out of it, too, so it 
never ends.

Yes. Typically, ticket work involves making a change of some sort, to something 
that's actually being used, whereas project work is kind of this nebulous, 
unused, non-production thing.


 - I'm hearing that you need to know a little bit about everything in addition 
to your own areas of expertise. How do you stay ahead of the curve? How do you 
learn about everything that you need to know especially if you don't know what 
you need to know? How do you do that?

I don't think that you do stay ahead of the curve. I really don't. I think that 
we do our best to ride it. Getting ahead is so immensely difficult. This 
technology essentially fractalizes into these many different various facets of 
high computing.

>From virtualizing, networking, programming, you have all of these facets. 
>Nobody can really, truly stay ahead of the curve. I mean, holy cow, the guys 
>in the Infra team, they are all 12-pound brain-type dudes. They'll go from 
>talking about hardware specs to talking about virtualization. They'll bounce 
>around all these different facets of technology, and obviously you have 
>strengths and weaknesses, I don't think anybody can really stay ahead of the 
>curve at this point, and I feel like it's been a long time since anybody has. 
>Technology has just gotten so complicated. We've really tried to, without 
>specializing too much ... kind of pick out some of the non-essential fluff, 
>the stuff that we don't use. I mean, hypervisors aren't really like super in 
>these days. It's all about the Cloud, which is really just an abstract 
>hypervisor, but whatever.

So, we don't really have any "machines" anymore, spec-ing out a physical 
machine is not something many of us do very often. It's not part of our job 
anymore, but that's definitely one area of technology that continues to advance 
as they put out better processors and whatnot. Mostly we try to stay ahead on 
the DevOps side of things without focusing too much on this operational 
infrastructure portion. And that's where I came from, this operational 
infrastructure, the data centers, the servers, the hypervisors, making VMs for 
people. That's what I used to do and now it's a lot less of that and a lot more 
fine-tuning this nebulous system of intermeshed tools that I don't fully 
understand yet.


 - Seeing that you and others can't stay ahead of the curve, can ASF 
Infrastructure actually stay ahead of the demand? I mean, is there any way you 
aren’t constantly in a reactive mode of "this new thing we're responding to, or 
here's a new part." Can you get your house in order, or is the house in order?

At the ASF, especially Infra, we do a very good job of listening to our 
projects because we as individuals cannot stay ahead of the curve *and* have 
every good new idea that there ever was to be had. Our community is large, and 
our community is very smart as people and as a group. We have a lot of really 
excellent ideas that come in from tickets and you say, "You know? I think I'm 
going to look into that today." And you look into it. You realize that it has 
all this potential and suddenly, that's the service that we're now using, some 
things like Travis, which is a third party build validator, came to us in that 
way.

Since I've been here, some of them have come to us via tickets, where it's 
been, "Hey, I saw that GitHub has this new thing, you should check it out." So 
one of us will check it out and we’re like, "Dude, that's awesome. We should 
use that." I think that we're constantly being batted in front of the curve by 
a community, by a boots-on-the-ground community that knows what's up. We 
obviously have our own interests and our own passions, but I don't think if 
left to our own devices, it would look quite the same as if Apache TLPs 
couldn't put in tickets.


 - So it's been one year and one month, but how has Infra changed for you since 
you've come on board or has it changed?

Nope, still terrified. [chuckles]


 - How is the team coping with the ASF's unstoppable growth? We have 45 
projects in the incubator and there's more than 300 projects out there … 
there's a geographic influence now on demand, an increase in users and 
committers and projects from China, for example. Are there any issues that the 
team feels like, "Oh boy, we got to deal with this?" Is computing an 
international language, where it doesn't matter where you're from or what's 
happening? Are any shifts going on from the ASF's growth impacting you guys 
beyond more of what you're already doing?

So, typically, all of my jobs really have been this kind of larger, national or 
international affairs so basically, since I was 20. I worked for a really large 
mortgage company, and then I left there and I went to a massive health 
insurance company. Lots of international folks and so, aside from the language 
barriers, yeah, I would say that computing is kind of an international thing. 
As far as the unlimited growth, I don't really know. I'm not sure. That sounds 
like a question that I would definitely advise you to go ask one of the Board 
members about.

 - "Management."

Right: "Management".


- You had mentioned that you were working on the no-longer-CMS project. Is 
there another project that you're doing? Are you a go-to guy for something?

I don't think I'm the go-to guy for anything really. I just try to pick up 
whatever is there to be picked up. One of the things that I'm working on right 
now in the "demise of CMS" project is this custom builder. I'm still working on 
it, so it’s still a work in progress, but the idea is that you'll be able to 
have a custom build environment that would allow you to, from the ASF.YAML 
file, write a script, do a “thing” to create your own custom build environment 
so that we can really, really make a hardcore concerted effort to get off CMS.


 - Why? What was the issue with CMS? Why do we have to migrate from it? What 
was the problem?

To be honest with you, I've never actually used CMS. Fortunately, I have never 
been asked, too. John (former Infra team member John Andrunas) was, but I was 
not. I was spared, by the CMS gods, they shone their countenance upon me. It 
was pretty awesome. From what I understand, it's very cumbersome to use and not 
very friendly and also very old. My understanding is that although it works, 
there are changes we wish we could make to it that we cannot, so it might be 
time to just move on to something newer that maybe works a little bit better 
for us because our use case has changed.


 - You're still rather new to the role: when you first came on board, what was 
the biggest challenge or surprise? What really opened your eyes?

So, what really opened my eyes was how much of a learning curve there is. Man, 
that was rough.


 - Is that still the case?

Yes, that's still the case. It's just not as bad as it was. Where I was before, 
I was using all of the stuff that we're not using here, all the Enterprise 
Edition stuff. So I came in with a completely different toolbox than what I was 
handed, so the learning curve was massive. I had to relearn how to use the 
automation software and we were all Splunk, so I had to learn the ELK stack 
stuff and we were Ansible or they were Ansible, the Foundation is using Puppet. 
Just all of it down to the monitoring. We didn't have any third party 
monitoring because, "government": we had this really unfathomably convoluted 
Xymon setup, which was interesting but  we were using RCS for everything. So 
instead of git or subversion or even CVS.


 - Yeah, they're stuck with their legacy, that's for sure.

Yeah. You got text files in there that have got 10,000 versions in RCS. It was 
like, "Oh, my God. What am I going to do with this?"

So, I tried to implement some of the new hotness there. The git workflow, 
gitflow, actually, the exact same kind of thing that we do here.

I had a good understanding of how ASF did business from an operational 
standpoint. I understood it, because I've helped implement it elsewhere, but 
this is the first time I've ever been fully immersed in the river of PRs and 
tickets and all that other stuff, so it's been a hell of a learning curve, like 
it has really, really kicked my butt.

 
 - But you're kicking it back. I mean, you're here. You're making it work.

Oh, yeah, hustle, man. That's really all you’ve got to have is hustle.


 - As you're describing the way the ASF is and you were talking about some of 
the tools and the orchestration requirements, is this a common thing that 
Infrastructure today in general is heading in that direction, or is it an 
anomaly not only from your personal experience, obviously, but that is an 
anomaly but from the way you see the industry? Does "infrastructure" in general 
seem to be headed in this direction, or is ASF really a unique animal in that 
way? Do people really have to be more jack-of-all-trades?

So the ASF is a unique animal. It is. Typically, people don't have 11 Cloud 
providers and if they do, they've usually got some sort of system underpinning 
all of that whereas ours is tribal knowledge and text documents and we're 
really trying to get this knowledge codified and our technical writer Andrew 
Wetmore was really doing a kick ass job with that. But, yeah, typically an 
infrastructure team of this sophistication would probably have a different set 
of tools.

It's surprising that we're not using, like Vagrant and Packer and Teraforms 
which abstract the way Cloud providers make VMs. We still make them by hand. 
It's work, and really the only way to be good at that is to know what you're 
doing and to be confident in that particular UI, which is always its own 
special kind of awkward, trying to get used to a new UI, finding out where all 
the options are, and we're doing all these things by hand … everybody just 
picks up this knowledge through osmosis, just by stumbling through these 
tickets from time to time and it's really crazy to see sometime how much 
process there is and how little documentation there is. So I'm really happy to 
have our documentation writer on board.


 - That's Andrew, right? Andrew Wetmore is working on the documentation?

Oh, yeah. Yep, and he's doing a really good job, helping us sort it out.


 - And he hasn't left screaming and running either, so that's a good sign. It's 
a lot of work.

That's true. Yeah. It is. It is a lot of work and he has not left running, but 
he is a really chill dude.

Our infrastructure is unique in that we do all of the things that are kind of 
necessary. There really isn't too much of a go-to guy for any of this stuff. If 
there's a problem in the build system, you take care of it. If there's a 
problem with a Web server, you take care of it. That's where the autonomous 
nature of Infra comes in. If there's a problem, you just take care of it. You 
have these tools, you know how to do it, you just do it.


 - How do you know that someone's not fixing it on their own at the same time? 
If something's broken, you're like, "Hey, this is broken. I'm dealing with it" 
or something else?

Just Slack, typically. I always check.


 - Yeah. Okay, what's your favorite part of the job?

Oh, gosh. My favorite part of the job is not feeling icky at the end of the 
day. I've worked for some companies that kind of made me feel a little ick in 
their mission. So one of the stories that my wife likes to tell is that I quit 
[MEDICAL INSURANCE COMPANY] because I disagreed with them as a company and I 
paid $5,000 to do so. But yeah, so I worked in the mortgage industry a little 
while shortly after the housing collapsed and I just thought about it. It was 
like, "Man, I really don't feel good about this job anymore." And then I moved 
to [REDACTED], which was arguably a bad move.

 - Big Health.

I was there for like 11 months. I signed a contract, I got a sign-on bonus, I 
moved to get there, so the stipulation was I stayed a year. I stayed 11 months 
and three weeks and I quit. I couldn't take it anymore. I'm just like, "I'm not 
doing this. I'm not doing this."

I was walking on an image parser for the Affordable Care Act pipeline, which 
was awful. They were still implementing it. This was 2012, 2013.

It was really bad. So after that, I went to NASA and I finally felt good about 
what I was doing and to have made a move where, again, I agree ethically and 
morally with what we're doing. I mean, it really is noble work, not 
specifically the work that I do, but the work that the people that I support 
do, and so, by proxy, my work is also. 

At Apache, we have volunteers that dedicate hours of their life to these 
projects that we distribute freely because it really does make the world a 
better place. I mean, where would the world be without HTTPd?


 - What you just said right now has totally touched me. I feel like I'm ready 
to burst into tears, that's amazing. Really: I mean, wow. That's from the 
heart. I totally get you about doing things for people you don't believe in. 
That's so hard.

That sucks so much.


 - I totally get it and you're right. This is such a crazy group. It should not 
work and they do and it's incredible: 21 years of this. It's amazing.

Yeah, it's like trying to watch an eight-legged horse run.


 - [laughing] A what?!

An eight-legged horse. Somehow twice as fast, but you have no idea how it's 
working. Or which direction it's going to go.


 - I can’t stop laughing over the visual of that.

It's actually really funny because I'm a huge classics and mythology nerd. 
Technology was not my first choice in careers. I wanted to be a Latin teacher.


 - I love this. These are the backstories that everyone wants to know. You want 
to be a Latin teacher?!

I wanted to be a Latin teacher, yeah. I did Latin from freshman year in high 
school until I decided that college wasn't for me. So sophomore year, I took 
six years of Latin and it is really awesome what learning Latin does for your 
programming ability because it’s surprisingly similar to learning to code. But 
yeah, I make a lot of really, really stupid classics and mythlogy puns. So my 
daughter, her nickname is actually Livy, in reference to the famous historian, 
which is not something a lot of people get, but that's okay, it makes me 
chuckle. And Odin had an eight-legged horse that was twice as fast as the other 
horses, supposedly really fast because it had twice as many legs.


 - It's interesting with your career, you've worked at places that are big 
names and people would be very impressed with that, but you're stressing that 
just because it's a big name or big group, it's not what it's all cracked up to 
be. What are you most proud of with your career, your Infra career, with Infra 
as a whole? What makes you say “yay”?

To be honest, becoming an Apache Member was pretty freaking awesome. When I got 
here, when I start a new job, I always try to set a goal for that job. 
Sometimes I get it and sometimes I don't, and sometimes I don't realize how 
hard it is to actually do what I'm setting out to do when I start. My goal at 
NASA was to win a silver Snoopy, but that was never going to happen.


 - Silver Snoopy? What’s that?

That's an award given by astronauts to engineers. They don't typically give 
that to IT folks, but I didn't know at that time. 

But here, it was to kind of become a Member and really to be accepted. I feel 
like I'm doing okay on that. That's pretty cool. That's going along really well.


 - You fast tracked. I mean, if you've been here for 13 months and you're in as 
a Member, that's pretty cool. That's good timing, good performance on you.

Well, thank you. I have no idea of how well or badly I am doing. I'm just doing 
things in the hope that they affect the universe in a positive way.


 - You're there, we couldn't do it without you.

That's excellent. Thank you.


 - You got to pat yourself on the back for the work that you're doing, because 
with our community, you know if you weren't doing it, you'd hear it. People 
would grump about it.

That's true. That's very true. But again, this is a mindset that's really 
prevalent in IT is the Tetris mindset where when you're playing Tetris, you 
fill up a row and it disappears. As such, those are your successes. 

The Tetris mindset really is being bogged down by the monument to failure that 
you've built because really, when you're playing Tetris, that's what you're 
looking at is the monument of your failure, places you haven't quite gotten the 
row completed yet and shifted out of your bucket. And it's really easy to 
succumb to that mindset, especially in a place like this.

And I really, really enjoy the fact that the Apache Community is they seem 
eager to call out wins for other people and that is an awesome attitude for a 
community. It's something I've not experienced a whole lot of being called out 
for successes. I think that on the whole, the community and being embraced by 
the community has really kind of helped me not fall into that funk, that Tetris 
mindset just doesn't seem to be prevalent in this community, which is nice.


 - Do you think that puts people in a kind of "I'm not good enough" mindset 
because there's not a reward? You're young enough to be part of that community 
that likes or is accustomed to getting trophies for showing up. Apache doesn't 
allow that. It's nice for you to show up, but you're not going to be rewarded. 
Do you think there's an impact with that?

I was on a soccer team once and I did get a participation trophy. You know 
what? I couldn't even tell you what the name of that soccer team was because I 
didn't want to play soccer. So, really, I think that if you're coming to The 
Apache Software Foundation, you're not doing it for the participation trophy, 
you're doing it because you want to, so the reward doesn't matter. You're doing 
it because you want to. It's really weird to be surrounded by people who are 
motivated by nothing other than the fact that they want to be here doing this.

And it's refreshing and I love it. I do.


 - I love hearing that, that's great. Here come the somewhat personal 
questions: there's just a few of them. Chris was laughing hard when I was 
asking them; I don't know if you read the full Chris interview, but it's always 
interesting to hear what they have to say. So ... how would your co-workers 
describe you?

Less cool than my wife.


 - What is your greatest piece of advice... what would you tell aspiring infra 
people, sysadmins, people like yourself, what would you give them for work 
advice or career advice or life advice: what would you say?

Oof, that's tough. I guess I would have to say that if at the end of the day 
you don't feel like your job is worth it, it's probably not. 

So, if you're going to do something, make it worth it. That's my advice.


 - If you had a magic wand, what would you see happen with ASF Infra?

What would I see happen? Well, obviously bonuses and pay raises, but I have no 
idea. If I had a magic wand, I'd probably turn it over to someone who I thought 
could make the wish better than I could, but yeah, I have no idea.


 - What else do we need to know that I haven't asked?

Oh, gosh. So many things, but none of them would make sense out of the context 
of this particular conversation. To be honest, I'm still under the impression 
that everybody knows more about this than I do still, so I don't know.



Drew is based in Tennessee on UTC -5. His favorite thing to drink during the 
workday is a black coffee prepared using a French press or the pour-over method.

= = =

NOTE: you are receiving this message because you are subscribed to the 
announce@apache.org distribution list. To unsubscribe, send email from the 
recipient account to announce-unsubscr...@apache.org with the word 
"Unsubscribe" in the subject line.

Reply via email to