CORALINE:  Hello and welcome to Episode 46 of the ‘The World is Upside Down. Can DevOps Save Us?’ I’m here with the lovely and talented, Astrid Countee.

ASTRID:  Thank you, Coraline but I think I should remind you that our show is actually called Greater Than Code.

CORALINE:  You think I would know that by now after 46 episodes?

ASTRID:  We all working on it. I have empathy for your struggle, Coraline.

CORALINE:  Thank you.

ASTRID:  I’m also here today with my great friend, Janelle Klein.

JANELLE:  Hi and I’m here to introduce Aria Stewart. Aria is an unschooler, performer, queer activist, avid cyclist and theater nerd, originally from the mountains of Colorado. Now, living in Somerville, Massachusetts with her husband and two cats. They started their own internet service provider, worked in web development for companies large and small and consult on diversity and development process. Welcome, Aria.

ARIA:  Hi, thank you. It’s nice to be here.

JANELLE:  We normally start the show asking a few questions about just your background, your story and where you came from and how you turned into the person you are today.

ARIA:  Awesome. That’s kind of tough to trace because I’ve been around this industry a long time and how I got here is a lot of little details.

ASTRID:  Don’t be shy. Tell us everything.

ARIA:  I was born in Denver. I grew up in the suburbs for the first 13 years of my life. I had access to computers and at school, computer labs occasionally. I was unschooled after fourth grade. I didn’t actually go to school at all but until that point, I was in and out the public school system. My parents want to fight for me to get access to things so I could access the computer labs before and after school. I had computers at home. I had a lot of interest and I was kind of the quintessential 80s nerd kid in a lot of ways.

CORALINE:  Right there with you?

ARIA:  Which is interesting in the way that played out later on in my life but as part of my unschooling, I ended up taking a part time class of high school on computer programming and the teacher sent a few of us to a computer programming contest sponsored by HP and they gave some sort of coding challenge for four hours to complete, that kind of a thing. We didn’t placed. Turns out that we were all stymied by the fact that none of us had a calendar for reference and the task involves date math so we could not check our work and this was in the days before computers had calendars built in so we literally could had no way to check our work with the stuff available and we weren’t allowed to leave the room or use outside references. We ended up not placing because we can’t check our work but we got a participation t-shirt, which turned out to be one of the most important objects in my life.

When I was 13, we moved to this little town up in the mountains of Colorado called Ridgway and the same month that we moved there, an internet service provider opened up. This was 1995. We were just getting settled in there. I’d had internet access through local libraries and things in the Denver area but when I moved out west, there wasn’t much in the way the internet service or anything like that so an internet service provider putting up was a big deal.

I marched over there one of the first days, asking if I could sign up for an internet service and I happened to be wearing the t-shirt from the computer programming contest and I got offered a job on the spot. I’m this 13-year old boy walking into a little tech company in the mountains of Colorado and I get offered a job. I’m a non-schooler so I actually have afternoons free. I don’t actually have classes and things that I have to be attending so I start working nearly full time when I’m 13 years old. Some of the weeks, it was 20. Sometimes it was 30 hours a week and sometimes it was a full 40-hour week, doing tech support like, “How do I get my email? How do I set up Netscape Navigator? What is the Trumpet Winsock thing and do I need it? I was cleaning up my desktop and threw it away and now my internet doesn’t work.”

This was in the days when getting on the internet at all was kind of a miracle. Computers are cantankerous, modems were unpleasant and when I started, the entire town was connected to the internet via a single 56kbps leased line. The entire town was sharing 56k, not too long after we accreted to T-1 but even so, by today’s standards, you have faster data service on any given cellphone in the middle of nowhere. T-1 is no longer fast internet and we’ve seen interesting experiments. That company was kind of unique in a unique place so we played by doing internet service by wireless. We end up going up on the side of the mountain and placing wireless internet down into town and I’m facing down into this service provider and people out in the valley know the town would get these expensive devices and antenna pointed at the side of the mountain. We ended up getting high speed internet people in 1995 or 1996. A town of a thousand people in the mountains of Colorado, about six hours from Denver.

I had high speed internet in my home a full five years before [inaudible] Denver to get it. It was a really an interesting place and time to grow up and I had a lot of opportunities being in this weirdly small place. But the way it started into my web career was, a couple of years later, my boss put one of those O’Reilly’s books with the animal on the cover and [inaudible] in my desk and says, “Can you learn this?” and I flip through a little bit and the book is CGI with Perl and flip through the book a little bit —

CORALINE:  I had that book.

ARIA:  Right. It’s a little quintessential books of the era, that and the HTML Guide and a couple of other standard references that every web programmer ended up with on the desk. The part of O’Reilly gotten popular as they did was they were the ones producing these books at all.

He slaps it down on my desk and says, “Can you learn these?” Yeah, I think I can figure this out, and there was my career built as a web programmer and I’ve been doing it ever since. I actually hit 21 years in the industry this summer, which is absurdly long time for someone who’s in their 30s but it’s because I got started at age of 13. When I got into the internet service business and web programming, I was 15.

CORALINE:  Aria, I have a very similar background as you by the way. Out of that experience, did you developed any super powers and if so, what are they?

ARIA:  I think the biggest thing I learned in all of that was diagnostics. Back in those days, there was no such thing as a frontend developer. There was no such thing, even as a web developer. You were just a software developer. I had to figure out Netscape Enterprise Server at the same time I was figuring out JavaScript, at the same time I was figuring out how to use vi on this old Solaris server so there’s no part of the stack that is unfamiliar anymore.

Web programming has gotten so complicated and so large and we use this incredible stack of tools and yet, I was there through the development of all of these. Even so, you come back to the server today and it’s like, “This is familiar. I’ve used things like this. I’ve used a dozen things like this.” The first time I came across server-side JavaScript was not when Node.js came out in 2010. I’d use server-side JavaScript in 1997.

CORALINE:  They had a special name. It was Rhino or something like that.

ARIA:  This was back in the days of Netscape Enterprise Server. This was actually the SpiderMonkey engine was embedded in their server, which is the same JavaScript engine that Firefox used for a bit long time, which is the original JavaScript engine. That’s what Brendan Eich wrote originally. They didn’t just stuff it in their web browser. They stuffed it in the server, they stuffed it everywhere so this JavaScript kept popping up in all these weird little places, even back in the 90s. I went to some server-side JavaScript programming all the way back then and it was terrible.

Error messages just didn’t work when things didn’t work. Syntax error, you might get the words ‘syntax error,’ and that was the only clue you had. You had no idea where and what file and what’s going on. But we figured out a lot and I developed some kind of super power debugging skills now so when something goes wrong, I can tell where in the stack it is and what kind of bug it is. It’s like, “I’ve seen that before like 15 years ago,” and we just now come around again to the same kinds of bugs because now we’re doing things that way again. Only computers are faster now and then software are better so it make sense to do it that way and it didn’t at that time.

CORALINE:  I have a feeling that people who do have the kind of level experience of 15 or 20 years of experience, who basically started their careers before there were specialization, I think we have a different approach to problem solving because we’re able to visualize the entire ecosystem for a given app, in a way that people who have focused on backend or focus on devops or focused on frontend. They haven’t fully developed yet.

ARIA:  Yeah, I think that’s something that’s interesting as we start teaching and as we start passing knowledge on to other, to newer generations is that keeping in mind that the context we operate it in is so very, very different. Despite a lot of the same skills applying, we really have to work hard to listen to what people’s actual experiences are and listen to where they are placed and give them advice that makes sense in that context and not from high orthodox-y sort of mindset that so many older programmers have had, where they grew up with the one true way, on the one true system and now, we’re just replicating that. We operate in fundamentally different ways. We’re doing a lot of the same work but in very, very new ways with different team structures and the way the knowledge have spread across our teams and through our ecosystem is very, very different.

JANELLE:  I have a question for you there. I’ve been thinking about as I’m listening to you, in terms of diagnostic troubleshooting, you mentioned this expert intuition effect where a system becomes really intimately familiar and then it’s this ideas that you see an error and you have that intuition about the system that’s broken. But at the same time, you learn the art of diagnostic troubleshooting itself. You seemed very self-aware. I would love to hear you describe your meta thinking process as you go through troubleshooting a problem. I know that’s kind of an abstract question —

ARIA:  Yeah. Most of it ends up being in eliminating possibility because you’re starting off with anything could be wrong here and we don’t know what it is and you need to hone in on what the actual problem is. Sometimes, that involves things like a binary search of the code. What happens if you just delete the last half of the code? Do you still have the bug? And so, you can reduce your search space by mechanical like try this part and this part works, then the bug is at that part. If the code doesn’t work, there you go, you’ve narrowed it down a little bit.

You also get this idea of trying to eliminate systems. Can you replicate the problem without one of the pieces at all? If it’s a frontend bug in a piece of JavaScript, can you eliminate the server? Can you run the test case down? Can you shrink it down so that the other part of the system is never involved? Or can you dig under the hood and make the same [inaudible] the JavaScript is and break it down that way? But then at the same time, there’s this holistic mindset you can do.

One of my favorite tools to reach for is actually TCP or [inaudible]. Type a word into a web form and have [inaudible] set up to see if it can even spot that on the network. If I hit submit, did the thing even leave the browser? Looking at the system as a whole, did the data make it from end to end before it eliminate parts based on what you see there? I tend to alternate from this like trying to hone me in sort of actions to the whole system, “Can I observe it the whole way through?” sort of things. Alternating those two mindsets and talking about them has been really good.

It feels like sizing things both horizontally and vertically and being able to hone in on a right direction and it’s an interesting process because they teach you a little bit more information that lets you make those intuitive leaps and also explain those intuitive leaps of, “Well, hold on just a sec. Here’s a very simple but powerful tool.” If we look for this one specific thing, we know is going to be true but the hypothesis for testing is true, let’s just check out real quick and we can eliminate these hypotheses very, very quickly by alternating those two mindsets.

CORALINE:  How do you even begin to teach that? I have a lot of trouble with early career developers that I mentor and I can’t even teach me to read a stack trace.

ARIA:  You have to have the desire to do your job well and you have to have the feeling that you’re connected. Doing those things actually does your job well. Quite often, people get pushed into parts of their job that they don’t love, don’t enjoy or don’t find valuable. In particular, women get shoved into all kinds of these side roles, project management and all of these things and a lot of developer culture being built on contempt of other roles, contempt for other specializations, has led people to really not want to seek what’s outside the box of their current experience. It really isolates and separates us.

Getting people to want to learn things is getting them the psychological safety to explore outside their box and reward them for doing so because while specialization has let get far, far, far more productive, it has also had some really interesting other effects that it has isolated us. One is to try to enforce strict boundaries between jobs. No, that’s the designer’s job to decide whether or not that should be 10 pixels or 12. No, that’s the frontend engineer’s job to validate that form. Never mind that the backend engineer also has to validate the form because networks are not to be trusted.

We really have to work on it. We should have an overlap in our skill sets and overlap in our communication. We have to work with people on the next layer in the stack down so our frontend engineers have to sit with designers, not just receive orders from but sit with designers and work on things. The frontend engineers need to sit with the backend engineers and talk through the problem and say, “We just got this large request,” or, “We found this bug and we were thinking of solving it this way,” and they’ll write five pages of code and the backend engineers says, “We just didn’t see that in first place. How could that happen?”

A lot of these things would end up with a lot more cohesive development culture. It would let people find and learn those skills a lot more easily. We have a frontend engineer here at work and she’s quite brilliant but doesn’t particularly like backend work. But also, keeps getting handed tickets that isolate her from the backend work. We need to start dividing the work better in a way that will let her dive in just a little bit and be successful in that backend work.

ASTRID:  This whole conversation is really fascinating to me because as somebody who is newer to development, I think that would tends to happen is you hear the opposite that you need to not think more broadly. You needs to be very focused on something so that you can build up your expertise. But I have found that that’s a struggle for me because of the same things that you’re talking about, Aria of like wanting to understand how the system works, wanting to do my job well so that I’m not just only good at one thing. What would be your advice to people who are trying to get good at their job but also want to be able to understand more about the entire system and not just one particular specialization?

ARIA:  They’re not separate but you have to realize that nobody can know everything about everything. Our world is too large and too complicated so it’s okay to seek things out in relevance first order. If you’re a frontend developer, learning about the parts that are relevant to a frontend developer, how HTTP works, what latency and bandwidth are and how they relate to each other, those aren’t important.

Learning the details of TCP/IP and what [inaudible] is aren’t going to be as interesting or as relevant so it’s completely okay to start digging down and understand how the next layers down relate to yours and figure out that the other layer exists, that it is distinct and then what the interface and boundary between your layer and their layer is. Then know a bit about the other side of the fence but you don’t have to know over the other fence, on the other side of their field.

A web developer is very rarely going to have to know the details about CPU architectures or things down into the machine. Our world is isolated from them. We work on phones and tablets and computers with the details of CPUs are so completely abstract and distant that we don’t care. We really don’t care.

CORALINE:  I have a friend who takes exception to that actually and she talks about having empathy for the machine for actually thinking about the impact that the code that we write has on the hardware. Are we making people’s laptops spin up and overheat? Are we putting undue pressure on servers such that devops has to keep adding hardware because of inefficiencies in our code? She posits that it’s, of course important to focus on end users but it’s also worth considering the impact that our code has on the middle.

ARIA:  Yeah, I think there’s a tension there. While web developers don’t need to know the details of CPU architectures, we do need to know what is spending time on the CPU and what is spending time drawing and what isn’t. We phrase it differently. We’re thinking about frames per second quite often or smoothness of animations but it turns out that those are the same thing so we do care about some part of it but we don’t have to care about what the instructions set is. We have to care about how much memory we’re allocating but we don’t have to care about pointer sizes.

JANELLE:  I got this question that’s been burning on my mind. Something you say about how isolation ends up leading to this cultural effect of content. That’s a pretty strong statement and I’ve certainly seen that happening all around me within the context of the organization but also very much in this context of this tribal splitting that we’re seeing happening all around us right now. What you see is a rise in contempt and shaming and things that are really disturbing in our culture. I’m wondering what kind of things that if you were to think about systems that are driving that kind of behavior, where do you see this connection with isolation leading to contempt. I’d love to hear your answer to that.

ARIA:  I think there’s a particular kind of isolation, where we abstract humans into roles. Often in development and in our jobs, we’re busy so we efficiently try to divide task up so that we can do as much as we can at once, so each person will be using their full output. The system of extraction, that is our modern business world, is trying to get the most out of things and those things are good for people. We put an abstraction there. This person is the project manager, you make requests to them by filing a ticket in JIRA and they will tell the developers what to do. The developers can take tickets from JIRA but they have to do it in priority order and talking to the PM directly is an exception.

In a healthy team, that’s probably a frequent exception but even so, the structure is that we want to reduce the unneeded communication. That’s what we’ve done. We’ve created an abstraction. The project manager as a person is now operating as the project manager role and in trying to be as efficient as possible, we lose a little bit of the humanity. Sometimes that’s needed because getting a task done isn’t being full human in the moment. We have the rest of our lives.

We can’t be all things all times so we can’t wear many hats but there’s a place where it become pathological where somebody is seen only as the role. We see it in companies of 60s, 70s, 80s and this is one of the failures of corporate. The corporate world is that people who are not in the same room more often get reduced to their role: the finance person, the marketing guy. We reduce people to just roles and I think this plays out in our broader culture too.

The people nearest us, our family [inaudible] people hopefully, if our families are functional. We see their opportunities and trajectories of growth. We see their fears and things but the waiter at the restaurant or the waitress or the barista at a coffee shop, we might see a little bit of their attitude or their style but we don’t see their hopes, their dreams, their fears and we don’t see how they want to grow and change as people and the people even further from us, the ones we don’t interact with on any kind of day to day schedule. Our society is super segregated.

I live in one of the most segregated cities in the United States. I don’t see people who aren’t white nearly often enough. I see non-queer people on a relatively frequent basis but a lot of non-queer people in my life, I’m quite often the only queer person that they see in any kind of regularity so I am always unknown. I am, in a lot of ways, play a role. I play a role of clown or weird outsider. If weird outsider is a role, I’m always been very comfortable but even so, it’s a role and it’s easy to get hidden behind that role. It’s not far stretch from there to go from relatively benign roles to ones where there are fear and contempt. We ended up with stereotypes and some really negative labels and people says really hateful things because they de-personalize those people into their roles, the roles that they play in the world around them.

It can be very terrible and one of the ways to fight that is to work together. One of the longest studied ways to reduce the amount of hate in the community is to get people to work together, where you have a shared goal and a common task, sitting down and working on it together. It brings people together, unless you have something driving the contempt at that point of, “This work is stupid,” or, “I don’t want to be working on this.” There are other factors there but people who actually want to work on the same things or who work to want to achieve the same goal working together, they very often become friends. It’s one of those things that is almost inevitable given that setup.

CORALINE:  I feel like corporations are trying to address that by adopting corporate values or setting like, “Our quarterly goal is X,” but it feels to me like in my experience at GitHub, plays into this brother companies too. There’s a disconnect between stated goals of an organization and the actual goals of the individuals doing the work. As a software developer, I may not care about a 5% uptick in revenue. Of course, it affects me but that’s not really tied to my goals in that role. I have an impact on it through the software I create but my goal might be to get this application out the door or develop skills in swift or I have so many varied goals. It feels like corporate goals, in an attempt to get people to work together and breakdown this barriers but they fall short for some reason.

ARIA:  There’s a bunch of factors there. Corporate goals are quite often too broad. They’re not tangible or if they are, they are not meaningful to the people. They are abstract. They are far off. They are quite often capitalist. We live in a culture where that’s how we fund businesses. We live in a way where you have to make money as a business. That is the goal, that is the purpose and you care about revenues but if they don’t have material effect to people, they’re not their goals.

But on the upside, humans can have multiple goals. It’s okay to be working toward increased revenue for the company, even if you won’t feel that goal deeply. But if you’re going to align people’s personal goals and their team’s goals with the company’s overall goal, that’s when you end up being successful. Sometimes, it can be very oppressive when we try to force people’s personal goals into a narrow shape. You get a lot of corporate mentorship programs, a lot of things like that. You end up erasing people and trying to force their goals to be aligned with the corporate world. I think this is where a lot of discrimination are coming from. This is where people start feeling like they can bring their whole selves to work because if they admit that they have goals separate from the corporations, they are pushed aside.

But then also, a more mindful company, a more humane company may find more clever ways to align those goals because there are a lot of places where it’s a win-win, where to stage in development of our culture, where a lot of the easy wins have been found. Finding win-win scenarios where everybody wins instead of somebody winning at the cost of somebody else, they’re getting harder to find. Competition is fierce and quite often that means then that if you do want something, you’re actually going to be taking away from another company, that’s where competition is or maybe you’re just extracting it from your employees. Maybe you’re winning at the cost of your employee’s health or happiness.

Pushing for extreme efficiency is really dangerous but it’s also where we’re at in our culture right now. It’s a joke among some people but also serious that that’s what late stage capitalism is. The easy wins have been made and now it’s eating ourselves.

CORALINE:  Aria, you’ve talked about the walls that we built between each other and how people start being perceived by the role that they played instead of as whole human beings. I remember when devops was new. It seemed like one of the founding principles was that there should not be this barrier between a developer and a sysadmin that the responsibility should be spread or smeared across. What had been really strong organizational divisions before that?

ARIA:  Part of this comes from the transition into cloud computing too. It used to be that system administrator, they had a culture of keeping things up all of the time. You buy expensive computers that last forever, very durable, very reliable and you protect them like you worked very, very hard to control access. You don’t want to rebuild and they’re not replaceable. The servers, like the ones I grew up with the ISP, these little servers by today’s standards, a cellphone is more powerful. They cost $20,000 apiece. These were the entire capital investment in a system for the year while they replace servers. They were incredibly expensive. Replacing hard disks was in the thousands of dollars. It was an absolutely gargantuan expenditure so the way we ran systems was very, very protective. We form an entire team to protect them from the developers, to protect them from the users. Then that grew into our modern system administrators and security professionals.

The sharp division of that role comes from the expensive hardware. If you have this $20,000 piece of hardware, you share it with all of the other users. Then if you break a $20,000 piece of hardware, not only have you broken the hardware, you’ve also caused an inconvenience for those other users. You set up a lot of mutual distrust and that created the old guard of our culture.

Then with cloud computing, that changed. Computers are now infinitely replaceable. The hardware is virtualized and abstracted. It’s sitting in a server room somewhere in Northern Virginia or Oregon or San Jose and when you want a new server, you just type a command into an API and it builds a new one and you can throw away the old and it will be recycled for somebody else’s use. Multiple tenancy, sharing the system is done at a very high and abstract way. As far as you’re concerned, you’re operating on a computer that nobody else uses and you’re in complete control of. That capability changed our culture.

But even so, we had a culture setup previously of protecting servers. Sysadmin is a separate role and developers and sys administrator had been pitted against each other in any organizations. The [inaudible] the system administrators and they were very, very stingy about handing them out to developers. You have to prove you are worthy to use this machine in an unrestricted capacity because when we don’t, somebody breaks it and it causes an outage for everybody.

Devops came along and the devops mindset was really trying to spread that out because the old reasons for being, have no longer existed. This is the thing we see time and time again in the industry, the old recently did a thing, no longer applies because technology has changed, because our culture has changed, because the economics have changed quite often.

Servers are cheap, even the hardware is cheap but we are in a period of increasing cultural change in a lot of places. But actually, development culture is not one of those, I don’t think. This is a case where development culture piled up on itself but as one of the only ones. The other one, we have this massive continuity back to, at least the dawn of the UNIX era. We have a huge cultural continuity all the way back there. Other parts of our field aren’t quite so continuous. The web was a bump but development itself has a very long continuity.

ASTRID:  But I thought that the devops movement was supposed to be like a catalyst in culture change.

ARIA:  When it works, right it is and actually, we betray ourselves whenever we talk of devops as a role. A frontend person, a backend person and a devop person, that’s not the way it was originally conceived. There’s a reason for that. They came out of the same shops that extreme programming was coming out of, where whole teams would work together on a project, blending roles pretty seamlessly and these were small companies and mostly consultancies. I think Pivotal Labs is working in teams of eight, at most. They would roll it out on the server. There would be some developers that do that, that they didn’t have a separate system administrator type of role and they really encouraged blending that together.

But then you try to apply some of these practices to a larger company that has an existing and entrenched systems infrastructure. It’s a lot easier to take your system administrator and say, “Instead of being on the system admin team, we’re going to take two of you and put you on to this development team and the other two of you on this other development team, we’re going to draw a line to the new place,” and you still end up with this ops skill set separate from the developer skills set. We betray ourselves whenever we think of devops as a role and not a practice that a lot of us can participate in.

Frontend developers participate as well. We push our changes live. We learn git. We learn version control. We learn a lot of the systems architecture stuff. We may not be [inaudible] but we are using this infrastructure in a way that it is our infrastructure. It’s not separate from us. Devops has always been about breaking down, not just barriers between teams but barriers between goals. Good devops culture doesn’t just about getting things to [inaudible] servers. It’s about getting people to work together through the whole stack and think about the operations all the way from beginning to end as a whole team.

That means that developers have to be involved in the planning and the designers have to talk to the developers. Some of this comes out of agile process too. We don’t need to write a full specification in advance, when we could just talk to each other. That has worked for better or for worse. Sometimes that also mean that therefore, we can skip on the prep work, which is deeply unfortunate but —

CORALINE:  The side effect of agile is that we threw the baby out with the bath water when we [inaudible], I think.

ARIA:  Yes to some degree. As much as those are things that we ever did purely. It’s much more a spectrum and not a strict division between the two. Waterfall has always been a strong mandate of agile practitioners have held up as, while we don’t do it this way. Nobody, except maybe NASA has ever done an all-design upfront. Just implement the details afterward. Even in places that try to do that, it never actually happened. You always have the circles and loops in the process, where the developers come back and say, “That’s not possible. Not with the constraints we’ve got. Let’s rework this.”

CORALINE:  I remember my consulting days where we did [inaudible] front design and had requirements. We realized that something wouldn’t work or we have an idea how to do differently or if the stakeholders change their mind about something. There was this whole process in place called change requests. It was a formal document that you wrote up to say, “The specification says X but actually, we need to do Y and here’s the impact of that and here’s the impact on the timeline and here’s the new set of requirements and is very high friction.”

But the upside of that, of course change was really difficult to affect in a waterfall process but developers did documentation and requirements were relatively well understood. I don’t see that happening really with agile methodologies, where we’re at now we have this idea of architecture decision records, which I think is a step in the right direction and it takes the conversations the people have and the collaboration that we do outside of a documentation process and says, “Here are the things we discussed. Here are the things we considered and here’s the decision we made about how to address this and why,” and that provide some context for the people who come after when they’re trying to wrap their heads around how system comes together and they asked the inevitable question of like, “Why is X there? Why did they do X in this particular way?” I think having some kind of record of those conversations, a record of the context where much decisions were made, it can be very, very valuable.

ARIA:  Absolutely. I think that actually come back to contempt. A lot of agile methods have contempt for documentation, have contempt for planning, have contempt for anything done upfront or anything that is more durable than necessary, which may be from a marketing organization, where you have the ability to throw away, that’s great.

Maybe if you’re building a prototype, where you’re just exploring a space as quickly as you can, sure. A lot of us are working on software that last years. I’m working on a system that was built in 2011 and right now is being rebuilt. I’ve worked on systems that were built in the 90s and are just now being rebuilt. Having contempt for planning documents has left us with no planning documents to refer to, when they go to do this rebuild. We don’t know what the feature set of our system is. Nobody knows it and it’s sad watching that play out. It’s really easy to get caught in those contempt things because it’s one of the easiest tools we’ve got for shaping culture.

CORALINE:  I think it happened a lot too with MVPs and that process gets thrown out the window when you’re building an MVP. But if you’re MVP is successful, it is now the heart of your system. No one ever says that an MVP is throwaway. It becomes the core. Those rash decisions or those undocumented decisions or the edge cases that lead to certain decisions are all lost and the people who come after, just sort of mop up the MVP, are living with the consequences of things that they have no understanding for.

ARIA:  Yeah, very much so.

JANELLE:  You mentioned before that contempt could get assigned to a process like documentation or planning, something that was just like this, “Oh, that thing. Don’t do that.” Then you’ve got this emotional attribution to this thing. Then if a person, a human is in a certain role and that role carries out that process, they’re carrying out that thing that we carry contempt for and then if that role gets assigned contempt, then the human essentially gets assigned contempt and the same distancing effect that you’ve been talking about before, where we reduce people to an object and this contempt toward process can kind of come together and it seems like to just cause this isolation contempt effect in our culture, in business.

ARIA:  Yeah, absolutely. I think that we are now reaping the result of that, having been contemptuous of a lot of these things in the past. We’re now seeing agile processes that fall apart and people who don’t feel that they fit in and alienation in developers and then documenters and testers, are one that we have widely hope contempt for agile processes. We don’t need testers. We write automated tests.

JANELLE:  I fairly recently did a keynote at SeleniumConf and it was the first time ever I’ve been immersed in a culture that was just all the tester people. What I realized being coming from the world of the engineers or the developers and then you walk in to the tester world and it’s almost like a group therapy session for all of these people that are just been stomped on a horrible way. It was mind-blowing and sad and made me feel awful for the way that because of this role and how people are seen as less than human.

Then we have this reduction of, “What is your output level and your cost as a resource. Oh, you’re not as important as these developer people because we don’t have to pay you as much,” kind of thing. That association, as well as manual testing contempt to the process, all gets attributed to the people and then you see more and more of this distancing effect going on and I just saw these people hurting. I was like, “I had no idea what it was like on the other side of the wall.”

ARIA:  Yep. Contempt management and contempt strategy at conferences have that group therapy aspect. Project management conferences have that, management conferences have that. Developer conferences don’t have that.

CORALINE:  I think the other place that’s missing is in InfoSec but ironically, I have a friend who does InfoSec recruiting and InfoSec has this very elitist attitude and they’re [inaudible] and lead us in contempt but I learned surprisingly that InfoSec people don’t get paid. I assume they would get paid more than developers but they actually get paid significantly less.

ARIA:  Very much so.

CORALINE:  I love to see the same kind of thing happen with security that happened with devops.

ARIA:  Absolutely. I think devops mindsets can lead that way but we need to identify why we push that away and how to integrate those skills into our teams. One of the things that we run into now is that we’re running into teams scaling limits. Teams can be no bigger than 12 people. Generally speaking, functional teams are smaller than that. It takes immensely more organization to build teams bigger that than. It’s not linear growth as teams has scale.

Past four or five people, you are starting to have communication dominate the team size and as you scale up to the ten or twelve people on the team, communication has to be formalized or else, it will completely override any ability to do work. You’re in meetings all the time. What we need to do is get better and having consultants, whether paid consultants or not, whether they’re just employees that flip between teams and consults and have a consulting relationship that way.

We need to get better at that because it means that we can actually have these people who are experts in these things available to us, rather than having to be the all-singing, all-dancing developer-documenter-commenter-tester-devops person and deployment engineer. I think that’s going to be hard because that means that we have to eliminate contempt and restructure how we think about teams and that means that a lot of people have to change their attitudes and their practices and that’s going to be very difficult.

Developers are an interesting bunch because being put on this pedestal, being the cream of the industry, the ones that everybody are seeking after are in a place where if we started acknowledge those places where we’re contemptuous, we started acknowledging the problems in our culture. It feels like it puts us in precarious position. It doesn’t. It makes us better at what we do but it feels like we’re undermining ourselves. There’s techniques to fight that — framing things in terms of uplifting others, instead of in terms of knocking down yourself — various things like that help a bunch. But what we do to fix these things is going to take some work and takes some cleverness too to make that happen.

ASTRID:  At this point in the show, we start out talking about our reflections and some of the things that struck us or stood out during the conversation. I can start. In the beginning, in your origin story, Aria you talked about how you found opportunities in a really small place when your family moved to the more rural part in Colorado. Throughout that conversation, I kept thinking about what you said because you were describing your introduction to the industry and how you started to really love software development as a whole.

You said that you had a holistic approach to it. In what we just discussed, it seems like that might be a solution to some of the issues that we are talking about or some of the culture problems that we see. A lot of times when we are describing ways that we might be able to make a difference, we’re thinking about these big macro problems and how to solve them. But there might be actually a better plan to start in a really, really small place and use that opportunity to try to think a little bit differently and think outside of our boxes and make an impact there so that that can be spread.

ARIA:  Absolutely.

CORALINE:  I was struck by the part of the conversation where we talk about specialization. Now, specialization can create boundaries between people in teams and lead to the contemptuous attitude toward other people in other teams, I actually think about this a lot, as a journalist, I know I have a different set of skills and a different way of approaching problems and a different way of working with other people. I do worry about over specialization and I think how we teach new developers to your point, Astrid we do encourage specialization because you have to rapidly develop skills that make you marketable. I’m going to be thinking about how we can solve that problem, especially for early career developers.

JANELLE:  I think I just had my head in the clouds this whole time. Software seems so small now compared to just what is going on around us. Humanity right now is frightening. I think we all feel that and it’s so easy to label people as criminals or label people with these negative words that allow us to turn people into objects, into roles, into clowns. It’s the same kind of thing. It creates this context of interaction that allows us to disable empathy in our brains and to push people as distanced away from us as possible to feel disgust and contempt for other people.

But the other thing that happens is developers are blind to their contempt. Developers don’t feel it. Developers are the ones that are sitting on top and if you take that same metaphor and look what’s happening, it’s interesting because you see these people that are in pain. You see these people that see themselves as victims that are afraid and lost in that and their solution to their pain is to see other people with contempt because it gives them an outlet for all that pain inside them to have some way for that to go. It’s so easy when people commit atrocities to forget that there is humanity inside them. As problems raised around us, I think the thing that we all have to remember is that inside of us, there is a soul. Inside of us, we all have a soul and it would be good for us to remember that.

ARIA:  Yeah, very much so.

CORALINE:  Aria, what are your thoughts out of our conversation?

ARIA:  I was kind of struck by just how solidly contempt connects to everything, how much it has driven so much of our culture and how little we talk about the things that worked well. It kind of caught me off guard that that’s where things stayed so much. Many developers who are actually joyful in what they do and they love teaching and there’s a whole new model that we don’t talked about nearly enough. We talked about the failures of the old model a little bit but there are some people who are very, very successful in building successful products and build fantastic tools for the people and really love what they do and makes me want to seek them out and start telling new stories, start telling stories of the people who are doing it wonderfully.

CORALINE:  Thank you very much for being on the show today, Aria. It was a great conversation. We really enjoyed having you.

ARIA:  Thank you.

CORALINE:  I want to remind people that if you like the kinds of conversations that we have on Greater Than Code, you can support us materially by going to Patreon.com/GreaterThanCode. All patrons, regardless of their pledge level, get access to our patron-only Slack community, where you can have conversations with other members of the community and panelists and guests to continue talking about the topics that we talked about on the show. Please consider giving to us through Patreon.

Also, we’re looking for corporate sponsors so if your company wants to support these conversations. They are definitely welcome to do so. Go to GreaterThanCode.com/Sponsors and we will talk to you all in a couple of weeks.