Storytime with Auntie Aja

Talks

Aja Hammerly

#software-development

#team-dynamics

#workplace-culture

#learning-strategies

Storytime with Auntie Aja

by Aja Hammerly

In this talk titled "Storytime with Auntie Aja," Aja Hammerly shares valuable career advice through storytelling aimed at both new and experienced software developers. Set against the backdrop of Ruby on Ales 2015, Hammerly emphasizes the benefits of storytelling as a means of conveying wisdom and experiences in a memorable way. The session is structured around several key anecdotes, each illustrating important lessons learned in Hammerly's career.

Key Points Discussed:
- The Role of Stories: Hammerly discusses how stories serve as powerful tools for sharing lessons and morals, resonating with people of varying experience levels.
- Know Your Audience: The first story illustrates the importance of understanding how to engage and negotiate with different colleagues using a humorous approach involving Cadbury cream eggs as 'bribes' to solve work issues.
- Choosing Between Right and Effective: Hammerly recounts a stressful situation where her team had a tight deadline for stress testing. They devised a quick but unconventional solution, leading to a discussion on whether to be right or effective in problem-solving.
- Proactive Communication: She shares an experience from a startup, highlighting the importance of addressing bugs proactively, reinforced by her partner's humorous advice about planned 'tantrums' to express concerns.
- Handling Criticism: In her journey as a developer, Hammerly faced challenges during code reviews that affected her self-esteem. This experience taught her that poor code does not define personal worth and the value of open-mindedness in feedback.
- Adaptability to Success: Aja concludes with her experience tackling a technical challenge involving real-time Sudoku puzzle generation, advocating for the openness to explore various solutions rather than striving for perfection.

Conclusions and Takeaways:
- The speaker urges viewers to assess whether they prioritize being right over being effective, a principle applicable beyond coding.
- Another central takeaway is the understanding that everyone produces subpar code at times, and it’s critical not to equate one’s worth with their coding output.
- Overall, Hammerly emphasizes the importance of personal growth, learning from mistakes, and the inevitability of improvement over time in one’s career.

The talk combines humor with practical wisdom, making it both entertaining and educational for developers at all levels.

00:00:29.840 Hello everyone, this is Aja Hammerly. Have you all met Aja Diaza? No? Say hello! I love this chair so much. I really wish the chair had been here the whole time so I could have used it along with the shawl and everything.

00:00:39.440 Aja actually has a well-prepared talk, so I'm going to let her speak since we are a little light on time. We had to do the sponsorship stuff, but please give a round of applause for Aja Hammerly.

00:01:01.359 Hello, welcome to storytime. I am Aja Hammerly, and this is not a technical talk, which is new for me. There are no slides that you can see; my slides are the black inside of a black hole, very spacey. Instead, I'm just going to sit here and tell stories, so grab a beer, curl up, and get cozy. We're going to have storytime.

00:01:30.799 So why stories? Well, stories are fun! Humans have used stories for millennia to pass on advice and morals, and to amuse. We had the bards of medieval times. Ballads are still a very common form of song; there's folk tales, fairy tales, and cowboy stories. I'm sure many of you attended preschool and kindergarten story times where you sat around in a circle on a rug and someone read you a book and showed you the pictures. This is because humans are wired to remember and retell stories, which are a great way to pass on information that can cross age and cultural boundaries and is good for a variety of experience levels. More advanced folks can relate to a story they've experienced before, and beginners can hopefully remember the lessons in an amusing way.

00:02:15.760 The stories in this talk are mostly fables. By a fable, I mean an amusing story with a hopefully pithy moral. Like most stories, the ones in this talk are embellished for dramatic or comedic effect, which means they are not entirely true or true at all in some cases. Additionally, I have shamelessly stolen liberally from other people in the grand tradition of storytellers, and any resemblance to companies or persons is purely coincidental. My opinions are not necessarily the opinions of myself, my employer, or any of my friends or organizations that I may try to associate myself with.

00:02:48.959 So, back in the day—stories I am most familiar with start here—I began my career in manual black box testing at a large company when I was just barely 21 years old. As a typical 21-year-old, I was incredibly opinionated and idealistic. Who would have thought? I didn’t understand corporate politics at all, and this was one of those companies where if you wanted to work with someone on a different team, you had to CC your manager and their manager on the emails you were sending. Otherwise, they would ignore you because clearly, if managers weren’t involved, they didn’t have to act on it. It was a low cooperation environment.

00:03:12.000 One day, while blindly checking things manually, I realized that something was wrong—something was amiss in production. It wasn’t an urgent issue, but on a scale of one to ten, it was about a six. The worst part was, if it wasn't resolved in the next 24 hours, it would escalate to an eight, and I didn’t want that kind of badness to happen to the company I was working for. Being young and idealistic, I spent the better part of the day sending emails, trying to find my boss, and calling people, walking around the office trying to figure out who had the keys to production so they could fix the issue.

00:03:18.720 I knew exactly how to fix it, but I didn’t have permission because I was just a lowly manual tester. Hours later, after lunch, I finally figured out where the person who could fix this was. I found their office on an off-campus mat, walked down two flights of stairs, found the hallway that led to their office, and put my key card on the door—only for the light to turn red. I tried it again, but the light turned red yet again. My key card did not work on the door to the one person who could set things right.

00:03:52.120 I walked back to my office, sat down at my desk, and started growling because this is something I do at work sometimes. My office mate, who was older, wiser, and actually liked business—he has since gone on to get an MBA—asked me what was wrong. I explained that something was bad and would get worse if we didn’t fix it in the next 24 hours. I had already spent half the day trying to fix it and hadn’t gotten anywhere because my badge didn’t work, and nobody understood. I was frustrated and hated that job, and he simply responded, "Ah, young tester, let me show you the way."

00:04:24.159 He opened his top desk drawer, revealing three fancy chocolate bars, two dozen Cadbury cream eggs, and a bottle of vodka. I didn't exactly understand how these items would help resolve my issue, but he encouraged me to follow along. Picking up a Cadbury cream egg, he left the office, walked down the hall to the office of a woman who had been at the company for several years, had 'senior' in her title, and—most importantly—was not a tester. He slid the Cadbury cream egg across her desk, and whatever she was doing, she looked up and rolled her eyes, asking what.

00:05:04.800 He said, "Office mates, like the young tester here, have a problem, and I'll let her explain it." I explained the issue, and she replied, "I can help you, but it’s going to require two Cadbury cream eggs." So my office mate went to get another Cadbury cream egg. While he did this, my older and wiser coworker picked up her phone and called someone who was orthogonal to the problem and calmly stated, "Hi, I have a Cadbury cream egg and a problem. How can we solve this?" It turned out, the mention of a Cadbury cream egg perked up their interest. They wanted to talk.

00:05:45.840 I explained the problem over the speakerphone. The person said, "Why don’t you come downstairs and meet me at the elevator lobby with the Cadbury cream egg?" So I went downstairs, handed him the egg, and he magically opened the door that wouldn’t open before. We walked in, and he said, "You talk to Aja; there’s something that needs to be fixed." I explained that two command-line commands needed to be run. We ran them, everything was fixed, and the moral of this story is to know people's bribes. It's crucial to know what people respond to!

00:06:36.560 A couple of years later, I was still at Big Co, doing automated testing. I had joined Seattle.rb and discovered there was actually a better way to handle things than at large companies. I was advocating that we should use TDD, release more than just once every six months, and stress test our app. Fortunately, Big Co agreed with the stress testing part, but our release was quickly approaching. Surprisingly, our stress testing team informed us they didn't have time.

00:07:10.000 So we asked if we could at least get one hour to explain our tool set to them since we were smart and could figure it out. During the meeting, they admitted they had no clue how to test what we were releasing because their tools didn’t work for it. Disappointed, we realized we had just three days to prove we had stress tested the application, or they wouldn't let us ship it. While brainstorming, I suggested transforming our integration test into a stress test by running it in an infinite loop. So we did, creating the infinite loop stress testing technique.

00:07:53.960 We took a spare machine, forked the process ten times, and let it run in an infinite loop all weekend. The first person who came in on Monday hit Control+C, killed the job, and we checked the server logs. Surprisingly, it worked; it was horrible, and I want to stress this is not the right way to stress test anything but it was effective. The moral here is that sometimes you have to choose between being right and being effective—ask yourself: would you rather be right or effective? Our solution was definitely not the right approach.

00:08:27.120 The 'right' choice does hold its validity, and I’ve made conscious choices to be right in my career. I firmly believe that tests run during development should not depend on the internet. After all, what do you do when the internet goes down? I worked at a company where the internet went away every three weeks, while another company's router reset at 9:00 AM every day for 15 minutes! You should be able to do your job without relying on it. I've also passionately supported TDD, which has led to many heated arguments with colleagues. I have lost every single one, but that’s the joy of right versus effective.

00:09:10.560 If you choose to be right, make sure it’s a conscious choice and be prepared to lose. Detach emotionally from the situation. Sometimes you will find you can choose right, but doing so often means forgoing effectiveness. On the other hand, if you choose not to be effective, you will likely lose, so make that decision upfront. It’s important to act rather than react.

00:09:54.560 After several inverted definitions of "successful" years, I moved from Big Co to manual testing at a small startup where we were one week away from beta. It’s essential to note we had separate client and server development teams, and I was working on manual testing on the server side. I finished my work and realized no one had sent anything else my way, so I pondered how everything worked together and pulled down the latest release candidate version.

00:10:23.200 To my surprise, the site crashed spectacularly, and I became frustrated. Nobody anticipated the bugs I was encountering, and I began venting to my partner about how everything was broken. Ultimately, I was told to report every bug I found, so I did, but my leads completely ignored my concerns about a critical bug that would compromise our beta. My partner offered a humorous perspective: "You get one tantrum a year at work!" This got me reflecting on how to approach such dilemmas.

00:10:50.720 The humor of it struck a chord and made me realize that tantrums, while often frowned upon in a professional setting, can sometimes serve a purpose—at least if strategically planned. My partner advised scheduling my tantrum to make it clear to my superiors. So the next morning, I prepped my boss, letting him know I'd be a pain. To my surprise, he welcomed me all the same! My message was straightforward; 'There’s a significant issue we need to address before the beta launch.' After productive conversations throughout my team, we made progress in fixing the bugs before it was too late.

00:11:16.880 We nearly reached beta time with serious consequences looming, and it became clear that these challenges I encountered could have led us into chaos if I hadn't flagged the critical bugs early on. There was indeed a bug that typically manifested 15 seconds after launch, making this experience an excellent learning opportunity for everyone involved.

00:11:35.200 The moral of this story is to be mindful of the effectiveness of your communication and ensure to be proactive rather than reactive in problem-solving. Too often we're afraid to flag ongoing issues properly out of fear of appearing to disturb the flow of productivity. Take charge of your work environment and influence change when necessary.

00:12:05.760 Moving into a new role at a different startup, I had learned a valuable lesson that success can present itself in many forms. As we attempted to solve a particularly technical issue—specifically, generating Sudoku puzzles in real-time. Generating and solving these puzzles quickly proved doubly challenging, since this problem falls under the NP-Complete classification, which means that it's inherently complex.

00:12:40.640 After two frustrating weeks of encountering hiccup after hiccup, we found ourselves coming close to resolving the issues but not quite getting there. Instead of holding out for perfection, we decided to run a computer over the weekend to generate 10,000 puzzles and pull from that in real time. It was a creative solution to an otherwise time-consuming problem, which just shows there are many routes to success.

00:13:12.960 The moral of this story: staying open to different methods and understanding that success could manifest in unexpected ways can help you reach outlined goals.

00:13:32.640 On to my last position, I started working as a developer and was met with enthusiasm by my new colleagues. I jumped into an authentication project excited, yet naive. In my first code review, my pull request was addressed with a multitude of comments—more feedback than actual code was in the original submission. I felt like a terrible developer, fighting back tears and feelings of inadequacy. One of my coworkers broke the ice by inviting me out for a beer, reminding me that you are not your code.

00:14:05.120 The takeaway was this: awful code does not define your worth as a person or a programmer. Everyone produces bad work occasionally; being open to criticism is vital for growth without letting it tarnish your self-worth.

00:14:40.000 As I close this talk, I’d like you to remember two key takeaways: First, consider whether you want to be right or effective—it applies far beyond coding and into everyday relationships. I always opt for effective over right when I can. Second, remember that you are not your code; everyone writes bad code at some point, and that's perfectly acceptable. Also, as you venture into your careers, keep in mind that over time, things get better. You will refine not just your skillset but also the atmosphere you thrive in, resulting in a more enjoyable work experience. And lastly: thank you to all my mentors and those who’ve shaped my journey, from Ryan to Scott and beyond, for helping me to acquire countless valuable lessons.

Ruby on Ales 2015