CHAPTER 3

• Monday, September 8

After the Town Hall, Maxine returns to her desk. She looks at her calendar. It’s day four of her imprisonment and her quest to perform a Phoenix build, but it feels like it’s been nearly a year, the hours passing like molasses.

She gets a notification on her phone, startling her back to reality:

Phoenix Project: stakeholder status update (starting in 15 minutes).

This is a new meeting for her. To further her quest, she has asked everyone to feel free to invite her to any meetings. It beats sitting at her desk, and she’s still trying to get the lay of the land. She’s hoping to find someone who can get her some of the things she needs. She’s been careful to avoid getting assigned any action items or to volunteer to work on fun-sounding features—she cannot be distracted from the Phoenix build.

Everyone around here thinks features are important, because they can see them in their app, on the web page, or in the API. But no one seems to realize how important the build process is. Developers cannot be productive without a great build, integration, and test process.

She arrives early and is surprised that there’s no room except in the back. She stands against the wall with five other people. Looking around, her eyes widen—all the movers and shakers in the company are here. Maxine smiles when she sees that Kirsten Fingle is leading the meeting. She heads up the Project Management Office. Maxine loved working with her when she was supporting a major program that had several of Kirsten’s project manager ninjas assigned to it—they were typically reserved for the most important projects that required lots of coordination across many groups within the company. They’re aces at making things happen. They can escalate and resolve issues quickly, often with a single text message.

At the front of the room is Chris, who gives her a terse nod—he oversees the efforts of over two hundred developers and QA people, dominated by the Phoenix Project. Chris is glaring at someone across the table from him who looks like Ed Harris from Apollo 13. When she quietly asks the person next to her who he is, he responds, “Bill Palmer, the new VP of IT Operations. Promoted last week after the big executive purge.”

Great, Maxine thinks. But she enjoys seeing the seniority of the people in the room. It’s like being up on the bridge of the starship Enterprise and watching the officers interact with each other.

She enjoys the first fifteen minutes of the meeting. It’s chaos. Everyone is trying to decipher what exactly Sarah meant at the Town Hall when she said that the launch was “later this month.” Kirsten says emphatically, “The date is still being negotiated and nothing specific has been communicated to me yet.” Could it really be another false alarm? Maxine thinks, incredulous.

Maxine guesses that there is extra urgency as they review the business priorities, the top issues needing escalation and attention, and the priorities that need deconflicting. She doesn’t know what all the acronyms mean, but she adds the ones that she thinks are actually important to her list and leaves out the insipid corporate argle-bargle.

As the meeting drones on and against all her expectations, she grows bored as the focus turns toward meaningless minutia, passionately pushed by … she honestly has no idea. Does OEP stand for “Order Entry Protocol” or “Order Entry Program”? Or were they talking about the OPA again? Or maybe they were the same thing? Do I really care?

Forty minutes later, her eyes are glazed over—it’s the “task status” phase of the meeting, and Maxine has lost all interest. If she had anything else to work on, she would have left by now.

Her feet hurt from standing so long, and she is reconsidering her decision to stay in the meeting when she hears someone complaining about how long they’ve been waiting for something they need. She smirks as she thinks, Join the club. That’s what I do all day long.

One of the Dev managers responds from the “junior people” side of the table. “Yes, we’re definitely behind, but we have a couple of new developers starting this week to help, and they should be up to speed and productive in a week or two.”

Ha. I’m really good at this stuff and I’ve made almost no progress, she thinks, looking at the floor. She smirks to herself. Good luck, chumps.

There is a long, awkward silence in the room. Maxine looks up. To her horror, everyone is looking at her—she realizes that she must have said something aloud.

She looks at Chris, who has a stunned expression on his face and is wildly gesturing with his hands at her in a “no, no, no” kind of way.

From the front of the room, Kirsten quickly says, “Great to see you, Maxine! I had no idea you were on Phoenix. We’re glad to have someone of your experience helping this effort—you couldn’t have shown up at a better time!”

Chris buries his face in his hands. If Maxine hadn’t already been standing against the wall, she would have been backpedaling. Mimicking Chris, she waves her hands in front of her. “No, no, no … Sorry, I’ve only been here a few days. You’re all doing an amazing job. Please carry on—I’m just here to help with documentation and builds.”

Kirsten, with the earnestness that makes her so effective, doesn’t let it go. She leans forward. “No, really. I think you said, ‘Good luck, chumps.’ I’m always interested in your perspective, given your extensive success in plant operations. I’d love to better understand what made you laugh.”

“I’m sorry I laughed,” she starts. “It’s just that I’ve done nothing except try to get Phoenix builds going on my laptop since last Wednesday, and I’m basically nowhere. I’m waiting for credentials, license keys, environments, configuration files, documentation, you name it—I know everyone has a lot on their plate and I know that Phoenix is such a large application that getting all the pieces together to do a build must be a pretty immense undertaking, but if we all want our developers to be productive, they need to be able to perform builds on Day One. Ideally, they should be writing code in a production-like environment so they can get fast feedback on whether the code they write works with the system as a whole. After days of trying, I still don’t have anything resembling the whole system—I have a box of subassemblies, with a whole bunch of missing parts. And I’m really, really good at this stuff.”

She looks around the room and gives a half-hearted shrug to Chris. She really needed to get that off her chest. Chris looks aghast.

“I’m just hoping these new engineers that you’ve been hiring have better luck than me, that’s all,” she concludes quickly.

There’s a long awkward silence. Randy nods emphatically and crosses his arms, looking smug. Someone from across the table laughs loudly. “She is so right! They’ll need a lot more than luck! Getting a Dev environment around here is like going to the local DMV to renew your driver’s license—take a number, fill out a bunch of forms, and wait. Hell, I can get a driver’s license in a day … it’s more like trying to get a permit to start a new construction project—no one knows how long it’ll take.”

Half the people in the room laugh unkindly, while the other half of the room is clearly offended.

Maxine looks at the wise-cracking person who spoke—he’s about forty-five, slightly overweight in an “ex-athlete” sort of way. He’s square-jawed, oddly clean-shaven, with big, square glasses. He’s wearing a skateboarding T-shirt, and his face has a permanent scowl.

Based on his crankiness, Maxine bets that he’s a senior developer—being stuck in an environment like Phoenix for a long period of time must take a toll on people.

Someone from the front of the room starts responding—she recognizes William, the super nice Director of QA, who has gone out of his way to help her. “Look,” he says, “our teams are getting further behind on testing, so we all agreed that in order to hit our dates we would deprioritize environment work—shipping fully tested features would take priority. We all knew that this would increase the lead times for getting environments to our teams. Trust me, my teams are being hit just as hard as yours—QA needs environments to test in too.”

The cranky developer immediately responds, “William, you got suckered. That was a terrible decision. This is a disaster. Maxine is right—developers need environments to be productive. You should have an entire team of people assigned to fix the environment creation process. I’m on three projects that need staging environments, all of which have been waiting months. In fact, this is so important, I’d like to volunteer to help,” he says.

“Denied,” says Chris wearily from the front of the room. “Stay in your lane, Dave. We need you focused on features.”

William says, “Wait, wait … I’ll have you know that we’re not actually the bottleneck for environments—we have several environments that are ready to go, but we still need login accounts from Security and storage and mount points from Ops. I’ve escalated it but haven’t heard anything yet.”

Chris points a finger accusingly at Bill and turns to Kirsten, “I need help on escalating our needs to Operations.”

Bill quickly responds. “If we’re the bottleneck, I need to know. Let’s figure out how to get William what he needs.”

Kirsten nods, appearing slightly exasperated. Maxine assumes it’s because more and more dependencies are surfacing. “Yes, good idea, Bill. Alright, let’s move to the next milestone on the list.”

As Kirsten talks, Chris turns to look at Maxine, his expression screaming, Which part of “lie low” did you not understand, Maxine? Maxine mouths the word sorry.

Out of the corner of her eye, she sees a younger man kneel by Kirsten, whispering in her ear while gesturing at Maxine. Instead of wearing khaki pants, he’s wearing jeans and is holding a black Moleskine notebook.

Kirsten nods and smiles at him, points at Maxine, and whispers a couple of sentences in return. The young man nods, furiously taking notes.

Maxine decides to make a beeline for the door, leaving as quickly as possible before she does something else stupid.

She makes it into the cool hallway, relieved to be out of that hot, stuffy room. She heads to the kitchen, where it is even cooler. She’s thinking about getting a mug of coffee, maybe her fifth today, when she hears someone say behind her, “Hello, you must be Maxine!”

She turns around. It’s the young man from the meeting who was talking to Kirsten. He smiles broadly and extends his hand, saying, “Hi, I’m Kurt. I’m one of the QA managers who works for William. I heard in the meeting that you need license keys and environments and a bunch of other things to get a build running? I think I can help.”

For a moment, Maxine just stares back at him, not sure if she heard him correctly. For days, her life has been to search every nook and cranny for the components needed to build Phoenix. For days, she’s been submitting ticket after ticket into an uncaring and faceless bureaucracy. She’s stunned that someone actually seems to want to help her.

Maxine catches herself staring at Kurt’s outstretched hand, snaps back to reality, and shakes it. “Nice meeting you. I’m Maxine, and, yes, I’ll take any help I can get to get a Phoenix build going!”

She adds, “I hope that I didn’t step on anyone’s toes back there. I’m sure everyone is doing their best, you know, given everything that is going on …”

He smiles even more broadly, pointing his thumb back toward the conference room that they were in. “Those folks? Don’t worry about it. They’re in such deep trouble that they’re all covering their asses and throwing each other under the bus. I doubt they’ll even remember what you said by the end of the day.”

Maxine laughs, but Kurt is all business. “So, you need to get Phoenix builds going. How far have you gotten and what do you still need?”

Maxine slumps. “Not nearly as far as I want, and it’s not for a lack of trying.” She describes in considerable detail what she’s done so far and all the steps that still remain. She opens her checklist on her tablet, showing him all the open to-dos, pointing out everything she’s waiting for.

“Wow, most people give up long before getting as far as you have,” Kurt says. “May I see that?” he adds, gesturing to her tablet.

“Sure thing,” she says, handing it to him. Kurt runs his finger down the list, nodding and appearing to compare it with another list in his head.

“No problem, I think I can get you almost all of these things,” he says. And with a smile, he adds, “I’ll throw in a couple other things that I’m guessing you’ll need later. Don’t worry, you couldn’t have known. We had to learn the hard way too. No one around here documents the build environment very well.”

Kurt takes a picture of her list with his phone and gives it back to her. “You’ll hear from me in a day or two,” he says. “The Phoenix Project is in the Stone Age. We’ve got hundreds of developers and QA people working on this project, and most can only build their portion of the code base. They’re not building the whole system, let alone testing it on any regular basis. I keep pointing this out to the powers that be, but they tell me they have everything under control.”

He looks pointedly at her. “You wouldn’t put up with that back in your old MRP group supporting the manufacturing plant, right?” he asks.

“No way,” she responds quickly. “It’s like that guy said in the meeting—developers need a system where they can get fast and continual feedback on the quality of their work. If you don’t find problems quickly, you end up finding them months later. By then, the problem is lost in all the other changes that every other developer made, so the link between cause and effect disappears without a trace. That’s no way to run any project.”

Kurt nods. “And yet, here we are, running the Phoenix Project, the most important project in the company, like we would have run a program in the 1970s. Developers coding all day and only integrating their changes and testing at the end of the project. What could go wrong?” he adds with smirk. “They keep telling me these decisions are above my pay grade.”

They both laugh.

Kurt doesn’t seem bitter or cynical. He radiates a good-natured vibe with an easy acceptance of the way the world works. He continues, “I envy how much your manufacturing team got done and how many platforms you supported. We’ve got ten times as many people on Phoenix, but I suspect your old team gets a lot more done than we do.”

Maxine nods. She definitely misses her old team.

“Oh, and by the way, there’s a rumor that might interest you,” Kurt says, looking around as if afraid of being overheard. “Word is that Sarah pushed for Phoenix to launch this week, and that Steve just approved it. All hell is about to break loose. Let me know if you want to tag along as they assemble the release team. That’ll be super fun to watch.”

After that strange interaction, Maxine sits back at her desk and realizes that she is waiting again. Absentmindedly, she looks at a quote she always has taped to her desk from one of her favorite Dr. Seuss books, Oh, the Places You’ll Go.

The book describes the dreaded Waiting Place, where people wait for the fish to bite, wind to fly a kite, for Uncle Jake, for pots to boil, or a better break … Everyone is just waiting.

NO!

That’s not for you!

Somehow you’ll escape

all that waiting and staying.

You’ll find the bright places

where Boom Bands are playing.

Everyone on the Phoenix Project is stuck in the Waiting Place, and she is determined to rescue everyone from it.

It’s 11:45 a.m. Maxine looks at her calendar. It’s only day four of her forced exile. While she hadn’t hear back from Kurt, she did manage to get access to the third of four source code repositories. Today, she decides that she cannot wait for other people any longer.

She is going to build something.

Over the next four hours, she tries running every Makefile, maven POM, bundler, pip, ant, build.sh, build.psh, and anything resembling a build script she can find. Most fail immediately when she runs them. Some barf out alarmingly long error messages.

She pores through all the error logs, scanning for any clues on how to get something to actually run, sifting through all the poo for anything resembling a peanut—laborious and unpleasant work. She identifies at least twenty missing dependencies or executables that she needs. Several times she asks around to see if anyone knows where to get these things, opening tickets and sending out emails, but no one knows. She spends three hours searching around the internet for clues, pouring through Google and Stack Overflow.

In a moment of very poor judgment, she decides to try building some of the missing components from scratch, from similar sounding components that she finds on GitHub. Five hours later she’s in a terrible mood—exhausted, frustrated, irritated, and absolutely positive that she has just wasted an entire day going down rabbit holes she never should have gone down.

Basically, she tried to forge missing engine parts by melting down aluminum cans. That was really dumb, Maxine, she thinks.

That night when she gets home, she realizes that she has brought all the frustration from work with her. She warns her husband and kids that she is currently incapable of conversation and finds two mini-bottles of Veuve Cliquot rosé in the fridge. When her teenage kids see her, they know immediately to avoid her. She is wearing her “Mom is in a super bad mood” face.

While they prepare dinner, she crawls into bed and watches movies.

What an utter waste of a day, she fumes.

She reflects upon the difference between a great day and a bad day. A great day is when she’s solving an important business problem. Time flies by because she’s so focused and loving the work. She’s in a state of flow, to the point where it doesn’t feel like work at all.

A bad day is spent banging her head against a monitor, scouring the internet for things she doesn’t even want to learn but needs to in order to solve the problem at hand. As she falls asleep, she tries not to think about how much of her life is spent searching the internet for how to make error messages go away.

It’s a new day. Fresh from a good night’s sleep, she sits at her desk, intent on not repeating yesterday’s mistake. Just because she felt busy doesn’t mean that she actually did anything meaningful. In a terminal window, she pulls up her work from yesterday and, without looking at it, deletes it all.

Then she pulls up all of her open tickets in the ticketing system. She refuses to feel powerless, at the mercy of distant powers, trapped inside a cold bureaucracy actively impeding her goals, aspirations, desires, and needs.

Maxine has a long and complicated history with ticketing systems, both good and bad.

Last year, she funded a Kickstarter project for a mug that promised to keep her coffee or tea at whatever temperature she wanted for hours. It even had a Bluetooth connection so that she could see and set the temperature of her drink from her phone. She loved the idea of it and quickly paid five hundred dollars to help the inventor.

She was thrilled every time she got a notification: when the inventor reached her funding goals, when a manufacturer was selected, when the first production run started, and, most importantly, when her mug had been shipped. It was so satisfying to be a part of the collective journey and to eventually hold one of the first five hundred mugs made.

The Dev ticketing system felt totally different. It was the opposite of the joy and anticipation she had felt with her magic mug. Instead, it reminded her of the horrific experience of getting her first high-speed DSL broadband package working back in the 1990s. Although she received the DSL modem right away, she then had to deal with the internet service reseller (who sold her the DSL service) and the phone company (who owned the copper wires to her house).

Whoever did the installation at her house must have screwed up because nothing worked—and when she called either organization, they told her that it was the other’s responsibility to fix it. Sometimes they could find a ticket related to her previous conversations, sometimes not. She was trapped in a cruel, uncaring, Kafka-esque bureaucracy. For four weeks, her awesome DSL modem did nothing except flash a red blinking light. It was as useless as a brick, and she had countless open tickets with both organizations.

One day, Maxine decided to take an entire day off of work just to tackle activating her DSL line. After three hours, she finally managed to talk her way up the chain to a Level 3 escalation support person who had access to both ticketing systems. He was amazing and obviously incredibly savvy, able to thread Maxine’s request to the right department, using the right keywords to get the two supervisors from both companies on the phone to line up all the necessary work. An hour later, she finally had her 64 Kbps broadband connection working.

Even decades later, she remembers how grateful she was to that support person. She had told him, “I’d love to talk to someone that matters about what an amazing job you did and how grateful I am for your help.” She happily stayed on hold for ten more minutes to talk to a supervisor and then spent ten minutes gushing in great detail about all the help that she had received.

It was so important to Maxine to describe how extraordinary and even heroic everything that Level 3 support rep did and how much she valued his help. Maxine was gratified to hear that he was being considered for a promotion and that her phone call likely sealed the deal.

Afterward, Maxine spent an hour watching the blinking green light and savoring the blazingly fast download speeds.

Remembering that savvy support rep, Maxine reminds herself that she loves solving problems, that she loves challenges, and how important her work is. It will help every developer become more productive.

Taking a deep breath, she summons the relentless optimism she’s been accused of having, and carefully scans her email for any new ticket status changes. She ignores all the team status updates, except for the ones where people are yelling at each other in ALL CAPS. She wants to know who the hotheads are so she can avoid them.

Continuing to scroll, Maxine’s heart leaps when she sees the subject line:

Notification: change to ticket #46132: Phoenix Dev environment.

Is her Dev environment finally ready?

She tries not to get excited, because she’s been fooled before. Twice yesterday she got a notification, but it was only for the most minor status changes on her ticket. The first was when someone finally looked at the ticket; the second was when it was reassigned to someone else.

Maxine clicks on the link in the email, which pulls up the entire history of the ticket on her browser. She squints and leans closer to her screen. She opened the ticket six days ago (if she counts the weekend), and there have been seven status changes as different people worked on her environment request. As of 8:07 this morning, the ticket is marked closed.

She hoots loudly. At long last, the Ops people are done! She is in the build business!

But she’s confused. Where’s her environment? How does she log in? What’s the IP address? Where are the login credentials?

She scrolls to the very bottom to the notes and comments, reading what each person typed in as they were worked on her ticket. It got bounced from Bob, to Sarah, to Terry, back to Sarah, then finally to Derek. At the very bottom of the notes, Derek wrote:

To get a Dev environment we need approval from your manager. The correct process is documented below. Closing ticket.

Maxine’s face turns hot and bright red.

Derek closed my ticket?! After all that waiting, he just closed my ticket because I didn’t have an approval from a manager?

Who the hell is Derek?! Maxine yells to herself.

She moves her cursor around the ticketing screen, trying to find anything to click on. But the only clickable link is the policy document that Derek provided. She can’t find any way to find out who Derek is or how to contact him. She finds a button to reopen the ticket, but it’s grayed out.

Thanks a lot, Derek, you shithead, thinks Maxine angrily.

Fuming, she realizes she needs a break. She stomps out of the building and sits on a bench in front of the office, she takes a deep breath, closes her eyes, and counts to fifty. Then she walks back into the office and sits down at her desk.

She clicks the button to open a new ticket. When the blank ticket appears, with the countless fields that need to be filled in, she almost gives up and goes home. Almost. Instead, she forces herself to smile and summons up her friendliest self:

Hi, Derek. Thank you so much for working on my environment, which we badly need for the Phoenix Project—please see Ticket #46132 (link below). I’m assuming I can paste my manager’s approval (Randy Keyes) in this ticket? I’ll get an email from Randy with his approval for you in the next 30 minutes. Can I call you to make sure this gets processed today?

She clicks the Submit button, writes a short email to Randy asking him to okay the creation of a Dev environment, and runs to his desk. She’s relieved to see that he’s there and not in a meeting. She tells him what she needs and then stands over him as he sends a reply that merely says “Approved.”

By the time she gets back to her desk, she feels a sense of grim determination and relentless focus. She will do whatever it takes to get her Dev environment. She sits down, copies and pastes Randy’s approval from her email into the service desk ticket, and adds the note:

Derek, thanks so much. Here’s my manager’s approval. Can I still get this environment today?

She hits submit.

She pulls up the corporate phone directory and scans for all the Dereks in the IT organization. There’s three. The one in the helpdesk department is the most promising.

She emails him a nice, friendly note, CCing Randy, to thank him in advance for all his help and to let him know how grateful she’ll be to get builds going for Phoenix, practically begging him not to put her ticket at the bottom of the queue where it will take another week to process.

She hits send. Five seconds later:

This is an automated response—please put all service desk related tasks into the service desk. I will do my best to read all my emails and respond in 72 hours. If this is an emergency, please call this number …

She curses. She imagines Derek sitting with his feet up on his desk, guffawing at her misery. She prints out everything related to Ticket #46132, her emails, and the names of the three Dereks, looking up where each one of them sits. Helpdesk Derek is two buildings over, lower level.

She steps out of the elevator on Derek’s floor and sees rows of small cubicles with people wearing headsets in front of computers. There are no windows. The ceilings are surprisingly low. She can hear the electrical buzz of florescent lights. It’s oddly quiet. There should be more fans running to make the air less stale, she thinks. She hears people typing and a few people talking politely to people on the phone.

Seeing all this, she feels suddenly very, very guilty about her previous anger toward Derek. She asks someone where he sits. After walking through the maze of cubicles, she finally sees Derek’s nameplate, printed by an ink-jet printer without enough ink. Then she sees Derek.

He’s not a hardened bureaucrat at all. Instead, he’s in his early twenties. He’s Asian, with a remarkably earnest expression as he scans something on a small LCD screen. Maxine has had laptops with bigger screens than this budget PC setup. She feels even worse about all the bad things she’s thought about him.

There are no extra chairs, so Maxine kneels down beside him. “Hi, Derek,” she says in her most friendly voice. “I’m Maxine, the person who submitted the ticket about the Dev environment last week. You closed it this morning because I didn’t have a manager’s approval. I just got it. And because you closed the ticket, I had to open a new one. I’m wondering if you can help me get this through the system.”

“Oh, golly, sorry about closing the ticket. I’m new to all of this!” Derek replies earnestly, obviously distraught that he might have screwed up. “All I know is that I’m supposed to make sure that certain requests that need approvals have them. I can’t reopen tickets. Only supervisors can do that. And all new tickets go into the queue where they get assigned to the next open person. Maybe my supervisor can help?”

Maxine slumps, dreading what might be ahead. But looking around at the sea of people, she realizes that if she doesn’t get this straightened out now, she will never get her Dev environment.

“Absolutely. That would be great, Derek.” He smiles and they walk toward one of the outer offices.

Over the next fifteen minutes, Maxine watches Derek’s supervisor expertly navigate through the extensive ticket trail, examining its history. In the time since Maxine left her desk, someone named Samantha has already closed her new ticket, pointing out that approvals cannot be submitted in the “Notes” field.

Maxine refuses to lose her cool. These people are trying to help her. The supervisor apologizes about how inconvenient this is. She merges Maxine’s two tickets together, puts Randy’s name in the approver field, and resubmits the ticket. “Now Randy just needs to hit one button in the tool and you’re good to go! Sorry we can’t actually authorize requests—only designated managers can.”

“Can he approve it from his phone right now?” she asks, with forced cheer. Apparently not—the helpdesk tool was written before smartphones existed and mobile phones were probably still the size of suitcases capable of showing only seven LED digits.

Maxine sighs, but she thanks them effusively because she is certain she is finally close to achieving her goal. As she turns to leave, Derek asks tentatively, “Do you mind if I ask a stupid question?”

“Of course. There are no stupid questions. Fire away,” she smiles, trying not to look manic.

“What’s a Dev environment? I’ve dealt with laptop issues, password resets, and things like that. But I’ve never heard of an ‘environment’ before.”

And there it is, Maxine thinks, thoroughly humbled. This week’s lesson on patience, kindness, and empathy, brought to you by Derek and the helpdesk department.

Maxine is proud that she has earned a reputation for being level-headed, compassionate, and having empathy for others. But right now, she feels like she demonstrated none of those things. Is being assigned to the Phoenix Project making her a bad person?

She realizes how misdirected her anger at Derek was. This poor guy didn’t hold anything against her because she was a developer. He didn’t even know what she was asking for, let alone understand how important it was. In his inexperience, he had merely closed her ticket by following the rules set for him. He was only trying to do his job the best he’d been shown how.

Maxine returns to her desk two hours later. She had taken Derek and his supervisor to lunch—out of appreciation for their help and to atone for thinking the worst of Derek. She got the chance to explain the world of development to him, and his earnest curiosity was infectious. She described all the exciting career tracks available for technical people outside of the helpdesk, hoping it might encourage him to explore some of the options available to him.

She goes to find Randy to make sure he approves her request. He’s not at his desk. She calls him on her cell phone right away.

“I can’t approve it until I’m back at my desk,” Randy tells her. “I absolutely promise that I’ll approve it when I’m out of meetings. It’ll be done before five o’clock.”

Maxine goes back to her desk, feeling conflicted. She understands the need for automated workflows. On the manufacturing plant floor, the MRP systems she wrote control everything that thousands of people do virtually every minute of the day. You can’t manufacture products in large volumes, costing thousands of dollars, without a rigorous process.

Even the helpdesk process, whether here or at the organization she had to deal with to get her DSL model installed decades ago, is a pretty good way to provide consistent customer service most of the time, even when it’s delivered through thousands of call center staff.

So why does the ticketing system here feel so awful? We’re all part of Parts Unlimited, so why does everything feel like I’m dealing with a government bureaucracy or an uncaring vendor? Maxine ponders. Maybe it’s because when friends do favors for friends, we don’t require them to open a ticket first.

The next day, Maxine sees that Randy delivered as promised—he approved the Dev environment ticket, but it was too late for anyone to start work on it.

Despite this breakthrough, Maxine is still waiting for a Dev environment. Disappointed, she wanders aimlessly from meeting to meeting, not wanting to be idle at her desk.

Killing time in the kitchen waiting for another pot of coffee to brew, her phone buzzes. Screenful after screenful of email notifications about changes to Ticket #46132 appear. A request to get a virtual machine assigned to the distributed systems group, a request for storage from another group, an IP address from yet another group, a network mount point from another group, application installs from three more groups …

Maxine whoops in delight—progress, at last! Santa just mobilized his magical elf army to start building the Dev environment that she so desperately needs. The cavalry is finally coming!

Exhilarated, she reads through all the tickets. So much work is being dispatched to what appears to be the entire Ops organization. Maxine suddenly becomes alarmed at just how many people are required to create one environment.

She works at her desk, planning out what she’ll do first with her Dev environment, when her phone starts buzzing incessantly. Opening her emails, her jaw drops at the forty notifications in her inbox. At the top of her screen are a flood of new notifications marking all her tickets as closed.

“No, no, no,” she moans, starting to trace through the ticket history from the beginning. She sees that the user accounts were created, the mount points configured, but then she sees a note from one of the storage administrators:

I’m sorry to have to close your ticket. Believe it or not, we’ve been out of storage space for the last three months. We have a big order for more storage that we can’t expedite until January, and worse, all the controllers are already at capacity. Purchasing says we can only order twice per year to get the best quantity discounts with our vendors. You are near the top of the list, so we’ll get this scheduled for February.

Maxine blinks.

It’s September.

Phoenix is the most important project in the company. They’ve spent $20 million over three years. And yet, here she is, trying to help, and they won’t spend $5,000 on more disk space. And now she won’t get a Dev environment for five months! She buries her head in her hands and silently screams down at her keyboard.

Completely defeated, she takes another walk, to nowhere in particular. It’s two thirty p.m. None of the meetings on her calendar seem interesting anymore. It’s just people complaining about waiting. Waiting for something. Waiting for someone. Everyone is just waiting. And she wants no part of it right now.

She returns to her desk, picks up her jacket and laptop bag, and decides to leave. She doesn’t know where she’ll go, but she just can’t stay here today.

It isn’t until she’s behind the steering wheel that she decides to drop by her kids’ old school. Not to see her kids—they’re at that age where they don’t want to be seen with their parents anymore. No, she’s going to the lower school where the fifth- and sixth-graders meet for after-school activities. She is proud of having helped the teachers create a coding club three years ago, which has become wildly popular. And she is delighted they’ve found so many students who are having fun with science, technology, engineering, and math before they go into high school.

Maxine believes learning these skills is incredibly important, because coding is a proficiency that every profession is likely to need in the next decade. It won’t be just for developers anymore.

She walks into the classroom and immediately sees Maia and Paige, two of her favorite kids to work with. They’re best friends but also fierce competitors, sometimes even archrivals. They’re both smart, ambitious, and have a gift for problem-solving.

This is the first time this school year that Maxine has visited. She’s surprised at how much older everyone looks and how much their coding skills have progressed. Some are writing what look like games in JavaScript, some are working on web servers, and two students look like they’re writing mobile phone apps.

She spends the next hour learning what each group is working on, laughing in delight as they show off what they’ve created, and loving it when they ask her questions. When Maia and Paige ask her to help solve a problem, she quickly pulls up a chair.

They’re trying to complete a classroom exercise to compute the mean, mode, and interquartile ranges of an array of numbers in Python. She immediately sees they’ve made the same indentation mistake over and over again.

Of course, when they try to run their program, the Python parser vomits at all the indentation errors. They’ve clearly been struggling to figure out what exactly they did wrong, trying everything they can to make the errors go away.

“May I make a suggestion?” Maxine asks, taking a more active role.

“Of course, Mrs. Chambers,” Maia says. Maxine sighs, still not sure how she wants to be addressed by teenagers.

Maxine explains to them how Python indentation works and how it differs from most other programming languages. “But whatever language you’re using, the most important thing is to run your program all the time,” she says. “When I’m doing something for the first time, I run my program every time I change anything, just to make sure it still compiles and runs. That way, I don’t make the same mistake for hours without knowing. Better to catch the mistake the first time you make it, right?”

She directs them on how to correctly line up some of the indentation. “Let’s see if that fixes the first error …”

She scans the buttons on their editor. “It looks like you can run your program just by hitting Control-Enter. Ah, looks like there’s one more little change needed. Yep, you’ve now fixed that first error. Now fix up the next error until you’re back into a working state. If you keep checking after each small change, you’ll never have something big you need to fix …”

Reflecting on what she said, she adds, “One of the really nice things about running your program frequently is that you get to see it running, which is fun, and that’s what programming is all about.”

The girls smile in understanding and stomp out the rest of their errors in quick succession. Maxine grins seeing them use the keyboard accelerator she showed them.

The girls are smiling because their program is actually running now. Looking at the output, Maia notices that something seems wrong. Their computed average is way off.

“Hmm … I think this is an ‘off by one’ error,” Maxine says. “This is one of the most common errors that developers make. It often happens when we are looping through every element in an array, and we miscompute which one is the last element. And that’s what’s happening here—we missed the last element … and believe it or not, when you accidentally process one element too many, that can cause the program to crash or even be exploited by a hacker.”

Maxine can’t stop smiling. She’s so excited to share this lesson, because over the decades, she’s learned that state mutation and looping is so very, very dangerous and difficult to get right. That crashing ODBC database driver she fixed in the middle of the night a decade ago, which made her so notorious, was caused by this type of problem.

This is why Maxine is so dedicated to applying functional programming principles everywhere. Learning Clojure, her favorite programming language, was the most difficult thing she had ever done, because it entirely removes the ability to change (or mutate) variables. Without doubt, it’s been the one of her most rewarding learnings, because she’s found that about ninety-five percent of the errors she used to make (like the ones the girls just made) have disappeared entirely.

Functional programming is truly a better tool to think with.

“You want to see something cool?” Maxine asks the girls. When they nod, she says, “Here’s what I would do. It looks a little strange, but you can get rid of loops entirely by using iterators—it’s an easier, and much safer, way to write a loop.”

She scans the Python documentation she finds on the internet, and types one line of code in their editor, hitting Control-Enter a couple of times and converging on the right answer.

“Voila! Look at this. It does the same thing as what you wrote, but with no loops or conditional logic, such as checking for the end of the array. In fact, it’s only one line of code, with no risk of an ‘off-by-one’ mistake!” she says, actually feeling proud of what she just wrote.

Maxine is rewarded by “oohs” and “ahs” as the girls’ eyes widen at what Maxine shows them. Maxine is pleased, because even this small exercise has banished some unnecessary complexity from the world. It might save the girls from decades of frustration and make the world a safer place.

She spends the next hour floating between the teams, having fun watching kids solve problems and teaching them little tricks here and there to make them more productive and joyful. When the kids adjourn, packing up their huge, heavy backpacks, Maxine realizes that she’s in a very good mood.

The joy of teaching people something that they want to learn is awesome. Plus, these are really great kids. She thinks about how easy everything is here. You hit Control-Enter and the program builds and runs. If there is an error, you fix it, hit a key, and try again.

In her current work hellhole, it’s the opposite. She still can’t build any part of the Phoenix system. Somehow builds have ceased being a part of everyone’s daily work.

Maia and Paige made the same indentation mistake for a half hour. At Parts Unlimited, there are a hundred developers probably making bigger mistakes, and it’ll be months before they realize they’ve done something wrong.

Everyone waves goodbye to Maxine, thanking her for all her help. She climbs into her car and slumps in her seat. To her surprise, she feels sad and dispirited—at work, there is none of the joy and learning that she just experienced here. She wonders if this is how everyone on the Phoenix Project feels all the time.

Maxine is about to start her car when her phone vibrates. It’s a text message from one of her collaborators on an open-source project she wrote to help her with personal task management. She started this project over five years ago to help her keep awesome work diaries. She’s always been a manic record-keeper of how she spends her time.

Initially, it was just to help her be more productive, to triage her incoming tasks from email, Trello, Slack, Twitter, reading lists, and what seemed like a gazillion other places where work is generated. Her app let’s her easily push work into GitHub, JIRA, Trello, and the many other tools where she interacts with other people and teams.

Over the years, she’s used this program every day to help her run most of her professional and personal life. It’s where she sends all her tasks. It’s her master inbox, where she can see all her work and move work between all the systems that she works with.

Many other people use her application too, and some have written adapters to other tools they need to connect to. She’s constantly amazed that thousands of people around the world use it every day, with over twenty active contributors writing code for it.

She looks at the new pull request from the text message—someone has created a new adapter to the task manager. The proposed change looks fantastic. She’s wanted to do it for years. Their change is quite clever, and she approves of the way the automated tests were written to show that his change works without breaking anything else. He also documented his work, writing several paragraphs on what he did and why. She approves of the way he’s turned it into a tutorial, so others can do something similar.

She loves seeing other people’s ingenuity and their willingness to make the app better. As the project owner, she sees it as her primary responsibility to ensure that any contributor can be productive.

A couple years ago, there were over twenty active pull requests, but for a variety of reasons, she couldn’t merge them in—sometimes the changes were conflicting, sometimes her API couldn’t quite accommodate what they needed. She knows it’s dispiriting when you submit a change to someone’s project, but no one ever looks at it or they tell you that it can’t be integrated. If that happens enough, people eventually give up or fork your project and splinter the community.

So, when this started happening to her project, she spent every evening for weeks rearchitecting her system so that people could quickly, easily, and safely make the changes they wanted. It took a lot of effort, and she personally rewrote every pull request so that the contributors didn’t have to redo their work. But everyone was delighted and grateful when their changes made it in—but not as delighted as Maxine.

Maxine knows that agility is never free. Over time, without this type of investment, software often becomes more and more difficult to change. There are exceptions, like floating-point math libraries that haven’t changed in forty years—they don’t need to change, because math doesn’t change.

But in almost every other domain, especially when you have customers, change is a fact of life. A healthy software system is one that you can change at the speed you need, where people can contribute easily, without jumping through hoops. This is how you make a project that’s fun and worthwhile contributing to, and where you often find the most vibrant communities.

She drives home and is delighted that her husband has already taken care of dinner. She regales her kids about her last-minute decision to visit their old middle school and the exciting new generation of geeks.

When they disappear to do their homework, she grabs her laptop and brings up the exciting new pull request. She pulls the code in and spins up the new version on her laptop. She logs in and clicks around, testing some of the corner-cases to make sure he got the details right.

Smiling, she brings up the pull request in her browser and clicks a button, which merges it into the code base. She writes a thank you note to the submitter, complimenting him on his cleverness and initiative.

Before hitting send, she notices something he wrote: “Maxine, I’d throw you a huge party if you could display a desktop notification whenever someone modifies this property …”

Good idea, she thinks. She pulls up her code editor, and in the next fifteen minutes takes a stab at implementing this idea. When it works the first time, she grins and laughs out loud, clapping her hands in gleeful selfcongratulation. She’s in a great mood. You can do so much with so little effort because of all these miracles of technology.

She resumes her note to the submitter:

Again, really nice work. I’m sure everyone is going to love it as much as I do. Thank you! (And I just added your notification feature. Your offer for throwing me a party is accepted.)

Hitting send, she wonders if the universe is sending her a message. Her afternoon with the middle schoolers and the ease with which she added functionality to her application (which is years older than the Phoenix Project) shows her what coding should feel like.

She is able to build things with focus, flow, and joy. She had fast feedback in her work. People were able to do what they wanted without being dependent on scores of other people. This is what great architecture enables.

She has been exiled to the most strategic initiative of the company, on which the survival of the entire company hinges. And yet, hundreds of engineers are paralyzed, unable to do what needs to be done.

In that moment, Maxine decides she must bring this level of productivity that she’s helped create for middle-schoolers and her open-source project to the Phoenix Project, even if it means personal suffering in the short term.