 Okay, this is, this is a talk about how I corrupted survey results and maybe ruined a business. Maybe it's in smaller letters because I think I did, but I'm not positive. But firstly I'd like to thank conference organizers who are here, all the other speakers, they've been so many great talks I got to attend since I've been here, unfortunately, many more than I missed. And that's why everybody here for spending a piece of your morning listening to me talk about my biggest professional failure. So with that said, let's talk about me for a minute. There's a big risk of talking about yourself at a conference like this, because everybody's going to think this is just some big elaborate exercise in egoism. I swear this is not an ego booster for me. If I was going to do that I'd talk about something I was proud of probably. But this story is about a terrible thing that I did, not that happened to me since I was kind of complicit in it and it was totally preventable. I'd like to believe that if I, looking back on it, if I'd heard a talk like this then, maybe it could have been avoided. No guarantees there, so if you're in a bad situation as well, I don't make any promises. More briefly about me, I'm the CTO of the company called Life.io. We're a small company based out of Philadelphia. We're not hiring right now, but that doesn't mean we're not fun to talk to. So you can find us and have some team members here as well. They're awesome. I'm okay. We like to talk about code every so often. I live with my wife and our two cats in Vancouver, Washington, which is just outside of Portland. The cats are not as thrilled about the holidays as we are. I'm 35 years old, so I've been programming for about nine years. Most of it will be at this point. I think I finally flipped that switch last year. And I've loved my career with about one noted exception, which we're talking about. And in that time, I've come to understand two traits about myself that are pretty fundamental to this story. And they're probably, and it's also probably relevant for just background about me. So I'm a lot higher strong than I'd like to be. It's probably coming through right now. I'd like to pretend it's not there sometimes, but every time I do, it seems to manifest in a way that I didn't expect. It's made interviews very hard for me in my career. I'll go to the thing, I'll go to it and start putting such a high level of importance on it, like, this is the job I need to have. And if I don't get it, I don't know what I'm going to do and who's going to hire me if I don't get this one. They all talk to each other. And then if I do get the job, that becomes even harder. I spend all of my time convinced I'm about to get fired at any moment. There's always this dagger just dangling over the top of me. It's not the best feeling, I swear. And it's led to a higher level of output for me, probably. I don't know if that's good. It's definitely put me in uncompromising situations. I'll commit to things that I shouldn't commit to. Say I've got just this herculean level of work covered and then work constantly for like weeks on end. I also don't handle confrontation well, and that's not to say I'm constantly screaming at people and losing my temper left and right. I actually quite the opposite. I'll retreat wholesale and just kind of check out of that conversation. I don't want to do it. I think there's something that was not a passive aggressive issue that the retreating that can be read is that sometimes it's really I just the idea of two human beings screaming at each other as adults in a professional context, especially, is really ridiculous in my opinion. I think the only noted exception is maybe my sister and me at the holidays. Thanksgiving is just around the corner. She's coming to visit. It's going to be great. I know these are not particularly unique characteristics. I think they're probably very relatable to a lot of people in the room. But for the purpose of the story, I think they're worth noting. But so let's get to it. In 2006, Ruby was version one nine. Rails was in version one, I think my notes might not be exactly right on this. Beyonce had just released her second album. And I had just finished earning a Masters of Library Science, which, you know, rocket ship to South Dakota, I was going places with that. So I started to look for jobs. I had been working somewhat with programming in the background with that. There is some tangential intersection in the library science program. A lot of those schools are now called Masters of Information. And so I found a job programming for a small micro consultancy in Manhattan. I say micro consultancy, you know, we're 16 people by file. So I say small company. There were five people total counting me at this micro consultancy for like rank and file, and then the boss. And we sat in this weird, perfectly square office with one office behind us. But anyway, so I got this job in Manhattan. It was a short train ride from my apartment in Brooklyn. It was it was pretty cool at the time. I was excited. I was more than excited, really. I was elated. I'd moved past the sphere, I guess, that my parents had had that I'd always be in school, which felt good. I was kind of realizing a lifelong dream, so to speak. I grew up in central New York, and moving to New York City was always something I wanted to do. My parents were terrified of New York City, and I was like, no, I'm going to go. This is my thing. So I was really excited to start programming, period. Like this was great. Like I had this job. There was no dress code. I could write the train to work, reading way too intellectual books from my weight class, it was great. And that optimism disappeared real quick. This was a terrible environment for me. I never forget. It's been great thinking about this so much, getting ready for this talk. I'll never forget the first time this happened to me. I said we sat in this perfectly square office with a door behind me to my boss's office, I think, right there. And so it's like the third day. All of a sudden I just hear this billowing yell come from behind me directed at the person who kind of sat, caddy cornered to me. And she was just getting dressed down for for what I now know to be a pretty insignificant bug. At the time, I was just, oh, she really messed up. Like that's terrible. I'm never going to do that. I did it quite a bit. Everybody was severely isolated. I said we sat in this weird square office where we had four corner desks all facing into the wall. Say what you will about the open office plan that was really popularized these days. Creating a circumstance where you're all in one room but can't talk to each other at all is a little bizarre. And it was even more bizarre when you consider that the boss would kind of monitor us in this Orwellian fashion. If we heard cross talk like, hey, how was your weekend? Or what are you working on? Whatever. I remember I routinely hear, do you guys not have enough to do? You got time to talk? Like what's going on there? And I was like, oh, sorry. I'll go back to my corner. Like that's fine. I was actually anecdotally on this. I was told to not waste my time on Ruby. I kind of wonder if you're taping into the live stream right now. That would make my day, honestly. I was chastised for asking for help, which is weird. There was a time I was working on something and he was bragging about how good he was at JavaScript. I'm terrible at JavaScript. And I said, hey, can I get some help on this? I'm not very good at JavaScript. And he said, well, you need to get better. Oh, okay. Well, I thought that's what I was doing. But I was also criticized for not seeking help subsequently if something took so long. This is in a book called The Wizard of Oz and Other Narcissists. There's this concept called the double bind that narcissists will engage in. Will there present one set of rules to you? And if you don't accomplish your task in that set of rules, the rules change. So you can never win, really. So I'm criticized for asking for help, criticized for not getting help. I'll just not talk to anybody. That seems like the way to go with this. I was actually called at home on one occasion. I took a sick day. I had laryngitis. And I sent an email saying, hey, I can't make it in today. And he literally called me and said, where are you? I was like, I can't come in. I can hear my voice. It was terrible. It was overall a really terrible environment for an anxious librarian who hates confrontation. It was pretty rough. But you got to pay the bills. And I made a pretty go of it. I made an OK go of it. I got to be competent, I would say. It's probably not how I thought of it at them. I keep thinking of this notion of sink or swim. And we say that phrase a lot. But what that's really kind of getting at a little bit is life or death. And so if you don't die, you live. And that seems pretty important. So if I'm succeeding in my version of it in this atmosphere where it's hard to succeed, I'm saying to myself, I am amazing at this. I'm like, wow, I took this over. I'm doing great. And I was doing things that I think a lot of developers do as they start to level up. I started to pursue more learning opportunities where they presented themselves. I went to meetups. I was an active participant in a Drupal forum. I read a book about Ruby, despite being told not to waste my time. I think I started to piece through the first pick of textbook. I learned enough to, I think, in hindsight, be really dangerous, which brings me to this project. So after a couple months, I get my first solo project. And it was a pretty straightforward survey application. The client needed to make decisions about their business for the coming year. So to do that, they were going to aggregate feedback from your users, asking them 25 questions spread out over five pages. Probably a lot of you were thinking, oh, I know, this is going to be a breeze. And it is. We have a lot of tools. We have a lot of tools now to do this. We could probably just do it in SurveyMonkey, honestly. But SurveyMonkey doesn't exist. I'm in a position where Ruby isn't on my radar. Rails isn't there. Erlang is not. I'm terrified to ask for help. And the only things I know are PHP and MySQL. So you can guess where this is probably going. The thing I built was complete and utter trash. I kind of bummed that Eric Patterson is over in the other room, because I could brag about this being the true marvel of modern engineering. So it was seven PHP pages where each one submitted to the next page. So every page that a user would load in its browser, like Survey1.php, Survey2.php, began with this chunk of custom PHP and MySQL writing directly to the database, and then you'd have HTML of the questions. It was pulling the answers out of the query string. It was really bad. And there was no validation happening. There was nothing even remotely resembling an object. Probably most importantly, nothing verifying the data ever saved. So it was a complete failure. It took me about a week to realize how badly it really was broken. When the user began the survey, I don't know why I built it like this, probably because I knew I was going to have to cover it up. When the user began the survey, a marker would tick off in the database saying, Survey begun. And when they finished the survey, there'd be a marker that ticked us, and survey ended. So I knew when a user started to survey and finish the survey and didn't drop off. And so I knew that if I had, I knew a certain number of those, I expected a certain number of answers to correspond to them. And I realized I didn't have all of the answers. Those were getting lost. So there's this record of 100 surveys being taken after the first week. I'm putting numbers on it. I think it was actually more than that, which is terrifying. Then I have the record of 100 surveys being taken. I think the drop-off rate was about 30%. So for every 100, I had 70 sets of answers. And this was bad. The client paid us for something that didn't work fundamentally or was paying us for something that didn't work fundamentally. But also, they were going to base their business off of this. So I should have stopped. I should have paused this, taken it down, apologized to my boss, apologized to the client, said we're going to fix the problem. I need a little help getting this set up because I don't know what's wrong. I'm not as good as I thought I was. But again, I'm terrified. I'm anxious. I'm like, this is going to be the thing. I'm going to get fired. So I hatched a plan. I realized that I could come in early and stay late and spend a big chunk of my day all day, every day, monitoring these results as they came in. And when I realized that something got dropped, the user started and finished, but I didn't have answers, I just make them up. I can just insert the values directly into the database. I think this person wanted this and this and this. It seemed a lot better than getting yelled at. So I'm making up these answers, saving them to the database for the survey that the client was using to inform their business direction. So again, I say maybe room to business. I say maybe room to business. All I know is they don't exist anymore. That's all I can confidently say about it. There was none the wiser at the end of it. I worked constantly for that whole month that the survey ran. And in fact, this is really the first time I've talked about it. No one ever has known about this. I got super fast at covering it up. I got super fast at covering up my mistakes. It was pretty intense in terms of stress. But at the end, the client was happy with what they knew. We have happy given their circumstances. Let me paraphrase that. And the end result, I guess, that made everybody happy was that my boss got paid. So not long after that experience, I left that company. It was a bad environment for me. I don't think there's any debating that. The guilt of...this was a client, remember? So we continued to do work with them. And the guilt of sporadically interacting with them and saying, hey, based on survey results, we want to build this thing. And my hand was going, yeah, based on those survey results. Okay. So the bad environment was a good enough reason to leave. But I really couldn't handle the guilt of interacting with that client in on-going capacity. I was hired at another consultancy that wasn't without its own set of problems. But those were problems that we worked to solve as a team. So let's take a look at what, if anything, we can learn from this. And I think the really obvious thing that comes out first and foremost is never hire me. I mean, I'm up here literally telling you about how I hired a client out to drive and how bad an employee I was. But, you know, maybe not. I like to think I bring this experience wherever I go. It's certainly, you know, I'll sporadically consider it in a lot of circumstances. And I promise I won't ever intentionally sabotage a project again. I wrote sabotage here, and I actually mean intentionally now. I'm sure I might do it accidentally. I'm prone to mistakes, but I won't scream at people if they make mistakes. And I'll never cover it up, especially when I know I've made it, I'll say something. And I know what I want to be as a manager. I'm a CTO now, which is still a weird concept to think of. But I know what I don't want to be in that position, so I'm still trying to learn what I want to be. But I think there's also a bigger concept to consider to all of this. Let's consider environments for a minute. In isolation, it's hard to understand why something exists the way it does to explain why this picture is so ridiculous of me. But if you put it into an environment that it starts to make a little bit of sense in, you're like, oh, okay, I get it. They're at a soccer game. It's still pretty ridiculous when you think about it, but that's my own cross the bear. But I think importantly, it's important to remember that I think software is really a product of the environment it was built in. The wells of business opportunity, and user happiness can be very shallow. If you're in an environment where condescension, fear, selfishness, egoism, those are the sort of feelings that you are, how things are run. You'll start to experience issues with retention. And I think when I say in retention, that seems like I'm only concerned about people working there, but it extends to employees, it's clients, it's users. Clients will go out of business, maybe you're at fault, maybe you're at fault. Users won't want to use their product. These problems will manifest in ways that we can't really even anticipate. They're kind of unknown unknowns. But conversely, what about a communicative, educational, transparent and positive environment? It's something more collaborative. You're going to build great things in that generally. I never hear a successful product owner give an interview saying, well, in our office, we don't encourage people to work together and they're not allowed to talk. And if a light mistake is made, I dress them down thoroughly. Maybe, I don't know. I believe it's genuinely true that people love using software that was built by people who love what they do and love where they do it. In my story, I think about the time I spent on an insane cover-up. I didn't love doing that work. That was actually like any minute now I'm going to get found out and I'm a fraud and you deal with so much from that. I could have just had help or some positive guidance, a mentor, somebody to collaborate with. But we also do need to remember that collaboration is tricky. It's a double-edged sword, so to speak. It means different things to different people. What if I was forced to work with the person who was making my life miserable? And so it's like, well, okay, you're going to get this collaboration as help you need, but it's from the worst person you know at that time and you're just going to have to sit with them for two hours and listen to them. No, I'm not going to do that. Oops, sorry. So you need to learn how you work best, but then also learn how the people around you work and figure out a way for you all to work together in that shared space, on shared terms. And share feedback about feedback. They talked on this yesterday. It was a great talk. If you can watch it through there, awesome. If you can go back and watch it, please do that. We don't only need code reviews. I think we also just need feedback about how we work together and how we're doing towards each other. And while we're fostering collaboration, let's encourage learning. And I mean, go beyond a company book club and attending a meet-up, which are great things. I love those, but if you kind of coordinate off learning to just those areas, it's harder to have it extend everywhere. So make it a part of your every day. Some level of cross-training. Check in with people. Questions you can ask are, hey, could you tell me about what you think of this? I do this all the time. I ask people, hey, I'm having trouble with this issue. Can you get a second set of eyes on it? I'm not sure of my approach. Naming things is impossible. So what do you think of this word? Why did you choose that approach you did? How do you help in a non-condescending manner? Sometimes people give signs that they could use help but are afraid to ask for it, and you can just say, hey, how's that survey you're working on going? If you need anything, I'm available. Somebody had asked me that question. It would have, oh, thank you. Build a culture of code reviews and insight and teaching. I feel a little awkward saying this just to a quick sidebar. At Lightbuy, we just got done with a big sprint, but we've made this promise to ourselves that we'll come back and fix them later. I'll talk about that more in a minute, but I put that note here for some reason. Oh, let's go through and talk about it later. Thinking back on the story through the lens of today's environment, I was a pretender. It was really hard to find an image for that, and then I remembered I loved the pretender, so worked out. That sink or swim mentality, again, led to some kind of learning, but what kind? A life or death comparison. I'm swimming, and I feel like I'm Katie Ledecky. In reality, I was probably one of those people in the Titanic that was taking everybody around me down as I flailed about aimlessly. I learned to be very dangerous and not do my job well. I came in cowboy coding at that next consultancy I went to, and that was immediately shut down because they weren't going to scream at me. They were going to fix the problem, and I was put in something that really resembled a mentorship program. That was really great for me, and I'd like to think I built off of that. That needs to be kept in mind. I look at the slide and it cracks me up because it's true, we make mistakes and we learn from mistakes, and some of the best learning I've done has been kind of getting confused on something, hacking around until I fixed it, or until I got to work and then I improved it. I think we have a pattern for that. But beyond that, I think there is also so much phenomenal and motivated talent coming into our communities and more experienced people are getting to work with new people and new perspectives. Megan Tew made a great point about this in our talk on Thursday. I'll go back and watch that one. That was excellent. And more experienced people are learning the work of being a leader, and that's tough. There was a great talk yesterday that I saw him earlier. I think you left. But it was about the senior developer as their career prolongs. You can't extend to this role of being a leader in your organization and your community, and that's important. It's something that you have to learn. You can learn to sling all the code you want, but learning how to interact with people and lead effectively is a separate skill set altogether. Caitlin Parve had a great talk about teaching on Thursday. I'm really unfortunate that I'm at the tail end of a lot of good talks. I feel like I should have gone first, and then the good talk is going to come afterward. New developers can learn a lot as well. And that goes beyond... Code schools are doing great. They're teaching patterns, they're teaching syntax, but they're not teaching the experience of working in software. And that's not the classic circumstance of oh, I can't hire you because you don't have experience, but you don't have experience because I can't... since no one will hire you. And that's the kind of negotiation for practices that they haven't used professionally. And the occasional compromises that business does require, that's the callback to what we just had to deal with at my company. It wasn't ideal, but sometimes you have to bend a little bit to continue to exist. And we all have an opportunity to be on very ambitious and thoughtful teams, where feedback is given and heard safely, constructively, and along with compliments, opinions, ideas, which brings up culture. Know that what you're a part of, know that you're a part of one and everywhere you go, you're joining a new one and you're contributing, not only are you contributing to it, but you should be expected to contribute to it. It's kind of your obligation. So be aware of that when you're considering a company or even if you're uncertain about your current company and you're thinking about it a little bit, you can ask some questions. How in an interview can you go about promoting personal growth? What values are valued? In an interview, were you the first person to even bring up culture? That might be a small concern. I literally thought back on that job interview and I was too nervous to think about these things then, and also I was junior, so I didn't really know what I was doing, but these are things I wish I had thought of, so that's kind of where this list is coming from. I could have, this is the big one, I could have looked around, it was an on-site interview and did everything seem kind of off? Because if I walked into this weird room where four people are all pointing to corners and then there's a boss's door in the background, like, yeah, that seems a little weird. Everyone looked kind of bored, that's a warning sign. Is everybody sharpening daggers? They weren't doing that, but if they are, I'd get out of there. In a remote interview, a weird distributed team, but in a remote interview you can also pay attention to certain markers. Is there more than one person on your initial call? And if so, how are they interacting with each other? Does that seem tense? Is that kind of off-putting up? We have, usually when we do our first intro interview, it's me and another person who are probably more nervous than the person being interviewed, and we're very jokie about it, and that's kind of a good reflection about us as a company. But let's summarize just a little bit. I think we can practice, oh no, okay. My notes disappeared, so I'm just going to read out this line. I'm going to read it out. I think we can practice now an obtrusive collaboration. Again, going back, learn how you work, learn what makes you comfortable, learn how your coworkers work. It's got to be a little individualized, and learn to do that together. A shared agreed upon space and a shared agreed upon context. Allow free communication. Don't cut off people. Don't say don't ask for help. Those are very obvious. I think it's much more subtle than that. It's probably a talk about the language that can prevent help. I think the canonical example we have right now is using the word just. Just put that in a PHP page. Leverage the above to foster learning and growth. If you start to build this environment where this is safe, it'll kind of begin to snowball itself, but the thing about snowballs is parts will fall off, so make sure you keep it on its path and keep it together. Remember that the end result is reflective of the environment it's created. If you start to see a lot of issues boil up in your software, users are dropping off or if you have a retention problem before you look to fill the people, the gaps leaving, maybe you should take a look at your company and try to improve what's causing everybody to leave. If you have a lot of bugs maybe you should look at what's causing those bugs to boil up. Treat the actual disease and not the symptoms of it, I guess. Don't engage in massive coverups. Can't emphasize that enough. That is effort and talent misused. I promise you that every time. And don't sabotage other businesses. I guess maybe if they're competitors, it's something to consider. But in general I wouldn't say if they're nice people, don't do it. But so I talked really fast because I'm a little nervous, but thank you everyone for spending your time at RubyConf hearing me share my most humiliating professional experience. I really do hope you guys got something from this or maybe got caught up on emails you're meaning to send while you're here. Either way, I'm happy to take some questions. My name is Mike again. Call Mike 0-1 and get on Twitter. Twitter is not anything meaningful. I think that's probably true for most people these days. Yeah, thank you. So the question was, does the micro-consultancy still exist? Could they find out about this from the talk? So the answer to both things is yes. There are a few people who know the company I'm talking about and it's funny because they've made no effort to update their presence in the world since 2000s. Their footer of their website still says copyright 2006, but they're still there. So conceivably, yeah, they could find this out. I'm less worried about it these days. The joke was on my flight here, I connected in Salt Lake City and there was a guy who got on the plane who looked exactly like my old boss and I started to have a panic attack right there on this plane from Salt Lake to Cincinnati and then he was at the conference and I was like wait, no, what is happening? And I talked to him about it and he was like, no, I'm not your old boss. I'm somebody entirely different. People tend to look like each other, it happens. So... That's a good question. Yeah, I started to think about it as I was going to review it. Yes, do you have any advice for stop me if I'm paraphrasing, but preventing these type of failings how I'm kind of reading it is giving assistance if you're the only developer in the company. So that's tricky. It depends on your skill level. I'd say, first of all if a company needs a developer and they hire an entry level developer to do all the work that could belie certain problems like you might want to consider bringing in some consultant to help you for a little bit to get that leverage. You know, you can lean on the community. They help... In Portland we have a Slack channel where people regularly post help and questions to figure things out. Being your own person like the biggest challenge you're going to have I always think I was the sole developer at Life.io for a while and the biggest challenge I always hit with that is knowing how to expand and grow because there was nobody to whom I was answering as I made those mistakes so if I did make them I would just have to say to my partners, guys I messed this up I need to fix this, I need to figure out how to do it correctly. I might need to bring an outside help and then as we grew the team I was... I kept this story in mind, I kept that experience in mind and knew that less experienced people would need a better support structure and I was going to be a big part of that. So I kind of tiptoed around, I don't have an exact answer for only one person. That's a tricky narrative to go being lone wolf is sort of if you live in San Francisco it's not an island I guess. So the question is, do you have any advice that you'd give to management to fix that situation? I can speak for my personal experience, how I've approached it which is I know who I don't want to be and so I try to encourage people to always ask questions first and foremost and I don't want to do it in a manner that's overbearing or saying this is how I want it to be built because I want other opinions and other thoughts on this to naturally emerge and then we can talk about it. Create an environment where if you're the only person that's trickier if there are multiple people look at each other's code, talk about approach and if a mistake is made and no one realizes it but that person make sure it's clear that they can say it and it's safe. You should have regular check-ins outside of that experience, outside of just that work to say okay this is your first check-in and you're fired because this was terrible. You failed at that point. So I would say keep touch points encourage learning, encourage questions. Yeah.