Sean hanson

Seán Hanson

UI Engineer MongoDB

Seán is a queer neurodivergent Brooklyn-based developer with an incredibly underwhelming history of open source contributions. Outside of work, he's likely to be seen playing Javanese Gamelan, helping out in support groups, and baking fancy cakes.

Description

A big part of the developer culture is sharing knowledge, writing blog posts, and posting code. You show your passion for coding by putting your work out there, but how do you show that passion if you can't publish your work? What if your job requires you to keep your work private? What if being quiet is part of being safe online? We talk to Seán Hanson about what it means to be a quiet developer and how passion doesn't always have to be loud.

Show Notes

Transcript

Printer Friendly Version

[00:00:00.00] (Music) Welcome to the CodeNewbie podcast, where we talk to people on their coding journey in hopes of helping you on yours. I'm your host Saron and today we have an awesome guest with us to talk about the quiet developer. (Music) In case you couldn't tell, I am not a quiet developer. I like talking. It's why I host not one but three podcasts. But not everyone likes to talk. It might be because their repos are all private or they just don't feel safe sharing their work. Or they just don't have time to work a regular job and do side projects and build a public profile. So they're quiet. They're quiet developers. So what do you do if, for whatever reason, you're a quiet developer, but you still want to show your passion and your interest?

[00:00:58.00] SH: I'm Seán Hanson, and I'm a UI engineer at MongoDB. And outside of coding, I like to do talks on diversity and inclusion and to go from conference to conference sharing my thoughts. 

[00:01:09.00] SY: Seán coined the term “quiet developer,” and he shares how being quiet has impacted his own career, his job search and his life. After this. 

[00:01:21.00] When I first learned to code, all I wanted was to be a developer. But then I actually learned to code and realized that you don't become a developer, you become a front-end developer or a rails developer or a back-end engineer or the million other job titles that involve coding. So how do you pick? And once you get that first job, how do you turn it into a career? You can use the Dice careers mobile app. This is the tool I wish I had when I first started. You pick the tech skills you either have or hope to have in the future, you type in your desired job title and Dice helps you find other job titles you might also be interested in and maybe didn't know about. But they take it a step further by telling you what skills these job titles require, how much they pay and, based on your profile, they tell you what skills you might want to learn so you can one day apply for those jobs. They simplify a lot of the chaos of job hunting, and it's totally free. So check out the Dice careers mobile app. Go to dice.com/codenewbie for more info. That's dice.com/codenewbie. 

[00:02:21.00] Flatiron School teaches you how to code from anywhere. They've got an awesome community of career-changers and a number of different options for you to pick from to become a software engineer. They've got full-time in-person courses, self-directed introductory courses and a remote online web developer program. They even have a free 75-hour online prep course where you can learn Javascript, Ruby and do some interview prep. Go to flatironschool.com/podcast to learn more. That's flatironschool.com/podcast. Link is in your show notes. 

[00:02:54.00] One of the best parts of being a coder is finally being able to bring your passions to life. You have the skills to design, to code, to create the thing you're excited about and share that passion with the world. And Hover can help you with the first step of sharing your passion with the world: getting your domain name. They've got a really beautiful and easy-to-use interface where you can find and register your new domain name in just a few steps. And to give you full control, they separate your domain name from your hosting so you're never stuck with one service. They keep your domain name safe while giving you the flexibility to use whatever hosting service is best for you. They also give you free WHOIS privacy, so your personal information is safe, too. To get started, go over to hover.com/newbie to save 10% off your first purchase. That's hover.com/newbie. (Music) Link is in the show notes. 

[00:03:43.00] So let's start with I think the obvious question: what is a quiet developer? 

[00:03:49.00] SH: To get to the answer, I want to take a short route through what Scott Hanselman in 2012 called dark matter developers. He wrote (Laughs) this awesome article that basically said hey most engineers don't actually get to work with the latest stacks, libraries or frameworks. In fact, the vast majority of engineers are working with stacks and things that we would normally say are out of date. And that was kind of a huge eye-opener for me because as a Javascript type of person, I'm used to having to pick up the newest thing every five minutes pretty much. 

[00:04:19.00] SY: Yeah. 

[00:04:19.00] SH: And so I just thought hey, let's take this a little bit further. I think a quiet developer is someone who they don't actually get seen as doing a lot of these things. They may be interested in the coolest, latest technologies, but if you look at their work, they're essentially not there. These are people who don't have, you know, a ton of things on their GitHub profile, but they are coders. They code throughout the day. They just work on close-sourced projects for work and then they might not actually have the ability or desire to code outside of work. So they might not have a spiffy profile or great public presence. And that's totally me for one. I love coding at work. It's like one of my favorite things, and I'm so lucky to be an engineer, but I do not code ever outside of work if I can avoid it. There's just too many other things in life I'm interested in. And also like I identify as a disabled person with PTSD, so there's a lot going on there where I need to make sure that my needs are being met. And sometimes coding isn't the best way to do that. 

[00:05:21.00] SY: Yeah. There's so many awesome things to unpack there. So one is just the use of the word quiet because when I first saw that, I assumed that it was a choice, right? I assumed that oh you're quiet because you don't want to talk, right? (Laughs) Like it feels like a very purposeful decision to make, but the first part of your answer when you talked about, you know, sometimes if you have close-sourced projects where you like can't actually share what you're talking about is an interesting maybe like career-developing problem to some degree where you can't share and engage the way maybe you, you want to just because of your job. 

[00:06:06.00] SH: Yeah, absolutely. And I remember being super frustrated when I was a junior engineer because everyone told me, “oh, you don't have a GitHub profile. You're never going to get a job here.” And I kept on saying like but I code. I code all the time. 

[00:06:20.00] SY: I promise. 

[00:06:20.00] SH: You know, I just can't show you what I coded. I can show you screenshots and stuff, but it's not on GitHub. I'm so sorry. And I was really lucky with MongoDB to actually go through an interviewing process where they didn't care about what we had coded on GitHub and our open-sourced contribution. They just cared about how we worked when we pair programmed and worked as a team. 

[00:06:41.00] SY: That's great. 

[00:06:42.00] SH: And those are the things that actually really get me excited... 

[00:06:45.00] SY: Yeah. 

[00:06:46.00] SH: ...in computer science are just like being able to work together on projects. The empathy is so much cooler than like whatever small project I've had to do on the side in order to make a chatbot or whatever. 

[00:06:56.00] SY: So at that point in your career as you were just getting started, you were more junior, how did you navigate that? How did you find ways to show people, show, you know, maybe potential other employers that you are a coder and you are active when you couldn't really build up your profile that way? 

[00:07:16.00] SH: It was hard. I don't know. I—to be honest, I probably interviewed forty-something times before I got my job at MongoDB. 

[00:07:24.00] SY: You think precisely for that reason? 

[00:07:26.00] SH: I think that I was ignored a lot during initial screens for that reason. I know that I was ditched by several recruiters and then eventually the recruiters wound up being people who were going to refer others to MongoDB and they came back to me and were like, “how did you get this job? You don't even have a portfolio.” (Laughs) And I just kind of answered them like I got very serious about the things that I do, and I'm confident in them even if other people weren't confident just having me—met me. 

[00:07:56.00] SY: Yeah. So how, how did you get that MongoDB job? Especially if you kind of, you know, sounds like you may have skipped the recruiter part of things or skipped that department entirely. How did you do that? 

[00:08:06.00] SH: I had a friend of mine who I've known for about five years who referred me, but I still went through the same process as everyone else. They just have a lot more open-minded technical recruiters partially because they're in-house, and so... 

[00:08:19.00] SY: Yeah. 

[00:08:19.00] SH: And also partially because we really care a ton about diversity and inclusion, so we're always looking for people who are coming in from like a boot camp or maybe not from a college that's necessary an Ivy League or anything like that. We're always looking for people who are coming in from a different direction and that happened to work well for me. 

[00:08:37.00] SY: So when your friend—the person you knew—referred you, was it generally a, you know, "I know you're a good guy and you can code so I'll refer you"? Or was there something that they saw or that you did that they felt made you a really good fit for that role? 

[00:08:54.00] SH: They took a huge risk on me honestly. They didn't know much about my code. They just knew that I had been the sole front-end developer for a startup for about two years. 

[00:09:04.00] SY: Oh wow. That's a lot of work. 

[00:09:06.00] SH: Yeah, it was way too much work. (Laughs) In fact, I...

[00:09:08.00] SY: I believe it. 

[00:09:09.00] SH: ...unfortunately, the start-up kind of fell apart so we all lost our jobs on the same time. But it was right when I was about to tell them “look I need a break because you're working me twelve hours a day.” 

[00:09:18.00] SY: Yeah. Wow. 

[00:09:20.00] SH: And the bright side of that was that I learned my first framework really fast from that job because I had no choice. I had to do that otherwise I just didn't have anything that I could do. But it happened to be the legacy framework that MongoDB uses for the cloud product, so I got a ton of luck because I was able to spearhead a project that actually was of interest to the people that I now work with. 

[00:09:46.00] SY: So I know you've given this quiet developer talk at a few conferences, and I'm wondering what are other examples that maybe people have shared with you of things they've done to navigate around their dilemma of not being able to speak about the work that they do? What advice would you give to people who might be in that same situation? 

[00:10:09.00] SH: That's a tough one. I—because I would say look for people who are actually going to listen to you, honestly. A lot of my talk is directed more towards hiring developers and to recruiters as to why you shouldn't ignore quiet developers, but to be honest, everything's stacked against you right now for most companies. I'm trying out there trying to tell hiring managers, "hey it's illegal to ask about all of these different things” like age, for example, or religious practices or like marriage status, you know, prescription drug usage, health-related things. But you totally are getting around that and trying to game the system by saying, “hey this person doesn't code outside of work, therefore, they might be thirty-five or forty instead of in their early twenties.” 

[00:10:57.00] SY: Is that a real thing? 

[00:10:58.00] SH: Yeah, absolutely. I mean why... 

[00:11:00.00] SY: Oh, wow. 

[00:11:01.00] SH: My coworker Jalpa is in her mid-thirties, and she's a mother of one and so she absolutely doesn't have the ability to be able to code out of work. And it would be illegal to ask her if she has kids or what her family situation is, but it would not be illegal for a recruiter to say, “hey why is your GitHub profile empty? Why aren't you coding outside of work?”

[00:11:21.00] SY: And then you kind of, you go backwards and figure out that they have a kid. 

[00:11:24.00] SH: Exactly. And that's totally eth--like it's completely unethical, but it's currently legal. And so it's used as this way to get around that. And so I'm going ahead and saying, “hey, recruiters, you're going about this entirely the wrong way. Like this is not only unethical, but you're cutting out really important people who could be the lifeblood of your company.” To go back to your answer on ways that quiet developers can be heard, I think that managers need to recognize that quiet developers might not have the footprint that everyone else does but still deserve to be—that managers believe that they deserve the same career progressions. And like I am a big fan of anonymous feedback so for example, I ask people like why do you feel safe going to this conference? Why don't you feel safe going to this conference? And get anonymous feedback from that. And that way I can say like oh it's probably best that we go to conferences with a code of conduct that will protect all of our employees. And also we can do that at large conferences so that we can find out what types of spaces we can be supporting. I think that it's important for large conferences to create spaces for minorities. And in doing that, we're making spaces for quiet developers because typically people who are in an oppressed minority also are facing a lot of different things and fall into that bucket. And I think that like another really big thing is if you care so much about open source, then why don't we create open source repos inside of our own company and then empower people of all backgrounds to contribute to those open-source repos because then every time you put in a pool request, your coworker who you trust and know really well is there evaluating you whereas, for example, every time I put a pool request up for a random public one, there's someone who doesn't know me, doesn't know where I'm coming from who then is going to have to comment on all of my code. And I've just been flamed by people who had a lot of ego involved in that process—far too much—whereas the idea of saying, “hey, you know, Dennis, can you take a look at this?” And then merging some things and that give me an open-source footprint for my job and show what I'm doing. That, to me, is a much healthier way to start out. 

[00:13:39.00] SY: Yeah. That's a really good idea. I really like that. So I think one of the other issues with quiet developers—being a quiet developer—is that there are certain expectations our community has. I think the community has a particular definition of what it means to be—I'm not sure what the opposite of a quiet developer is... I guess a loud developer? 

[00:14:03.00] SH: Yeah. 

[00:14:04.00] SY: Where it's, you know, someone who tweets a lot, someone who blogs a lot, someone who, you know, literally speaks and talks a lot, someone who's always coding. Are there other ways that maybe aren't so public, so social that are still indicative of passion and interest that may not fall into one of those buckets?

[00:14:25.00] SH: I totally think so. And I think that that's like the most exciting part of pair programming is that to me, your passion comes out in what you do in everything that you do as long as it's something that you're passionate about. Yeah, I really feel like quiet developers—everything that we do is actually filled with passion even if it's not something that's heard or seen. I think it's best when we're given tools that we can leverage in order to make those things more known. So for example, I'm a really big fan of how our Javascript group at MongoDB has a monthly meeting about learning the next, like the next great thing and bringing up a subject that we want to know more about, but I'm particularly happy when they allow junior developers and people who are quieter and don't actually do this regularly to say, “hey this is what interests me” rather than the person who's gone to fifteen talks and has heard this over and over again because I like the idea of people who are the least visible guiding everyone. And then for people who are loud and rambunctious—rambunctious is probably, you know, a little too much—but for people with these types of backgrounds where they are going to go home and immediately learn what's new about the next version of React that instead of them guiding the trajectory for everyone, they can be helping serve as a guide instead and say oh so like the our junior devs really want to learn about a particular subject. Let me learn as much as I can about that and then create some like training materials so that way people who don't do as well in a live meeting setting can have something that they can do on their own time, you know, maybe during their lunch period or something like that. 

[00:16:07.00] SY: Yeah, so it sounds like there are some activities that show passion and interest that are very public. There are some that are very social. But there are others that are maybe a little more intimate, a little more, you know, with small groups or one-on-one that still demonstrate the same thing but, you know, just aren't aren't as visible. 

[00:16:25.00] SH: Yeah, exactly. 

[00:16:27.00] SY: So I want to talk about the other aspect of being a quiet developer which is when you just kind of want to be quiet, right? Like you mention yourself especially at this point in your career that you just don't want to code on the side, you know? You're fine doing other activities, other hobbies, you know, on your weekends instead of spending them coding, which is perfectly legitimate. Were you always comfortable not having a coding side project? 

[00:16:52.00] SH: To be honest, yeah. I've always been uncomfortable when I try to force myself to have one of those. 

[00:16:57.00] SY: Interesting. Yeah. 

[00:16:58.00] SH: And I think the reason why is because when I think of my community, I don't think of a community of engineers, I think of a community of like folk dancers and queer people (Laughs) instead. 

[00:17:09.00] SY: Literal folk dancers? 

[00:17:11.00] SH: Literal folk dancers, yeah. 

[00:17:12.00] SY: Your community's awesome. 

[00:17:13.00] SH: We contra dance. Yeah, I'm very happy with them. They're all over the U.S. at this point, unfortunately.

[00:17:17.00] SY: That's so cool. 

[00:17:18.00] SH: We used to all go to college together. But I think that a lot of times we're talking about like invisible communities like things that we or groups that we don't necessarily recognize immediately. And so when people look at what I'm doing code-wise, they're looking at me through the like auspices of a larger engineering community instead of asking me what communities do you value. And then that way I can say well let me tell you about contra dancing and like let me tell you about (Laughs) these people that I just baked a loaf of bread with last night. It was so good, you know? (Laughs) And you're not opening yourself up to that relationship with that person. You're looking at them only through the lens of your own community rather than what they do, and that's like one of the biggest things that I really wanted to push for managers (Music) and for every—actually, honestly everyone to do is to approach someone, and when you don't recognize them as being part of your community, think of yourself as the outsider because there's just so much that you have to learn from other people if you open yourself up to learning. 

[00:18:20.00] SY: Coming up, Seán gives us advice on how to navigate the loud world of tech. We also talk about his role as UI engineer at MongoDB and what helped him get his job even as a quiet developer. After this. 

[00:18:36.00] When I learned to code, I was so excited to finally bring my passions to life. I could build things that I really cared about and share them with the world. And the first step in sharing is getting a great domain name. That's where Hover comes in. They've got a really slick easy-to-use interface. They've got awesome domain names to pick from and they separate your domain from your hosting so you have full control and flexibility over your online identity. So go to hover.com/newbie to save 10% off your first purchase. That's hover.com/newbie. Link is in the show notes. 

[00:19:07.00] You want to get serious about learning to code, but where do you start? Flatiron School's got the perfect thing. They're offering their free 75-hour online prep course, where you dig into Javascript, Ruby and more. If you're not sure where to start, start there. And when you're done, you can keep learning with their self-directed introductory courses, remote online web developer program or full-time in-person courses. Whatever your schedule, they've got options to help you reach your coding goals. To learn more, go to flatironschool.com/podcast. That's flatironschool.com/podcast. Link is in your show notes. 

[00:19:45.00] Getting a job is one thing. Building a career is another. With Dice, you can do both. They've been helping tech professionals advance their careers for over twenty years, which means they have a ton of data and tools to help you navigate yours. Looking for a job right now? They've got thousands of positions available from top companies like AT&T, Dreamworks, Adobe, IBM and Dell. Wondering what's next in your career? Use their career pathing tool to find new roles based on your profile and see how much more money you can make. Not sure if you're getting paid what you're worth? Use the Dice salary predictor to see real numbers on what your skills are worth. Don't just look for a job. Manage your career with Dice. (Music) For more info go to dice.com/codenewbie. 

[00:20:28.00] So I think that especially in the early stages of your career when you're trying to make a name for yourself, trying to get that first job, trying to keep that first job, there's definitely a lot of pressure to do side projects and really just, you know, use every minute that you can to look good and to show your skills and hopefully get opportunities. Did you ever personally feel that pressure? 

[00:20:52.00] SH: Absolutely. I mean, one of the first things that I tried to do when I was trying to learn the basics of Node was create an app that would help people call contra dances. I was like “oh, I've got to find the greatest way to merge engineering with everything else that I love in my life.” And what I quickly found was for me personally, it just diluted all of the things I was interested in. All of a sudden here I am, you know, instead of listening to all of this music that I find to be wonderful, I'm stuck on this Node problem that I've never run into in my life (Laughs) and all of a sudden now I'm starting to like hate the fact that I'm working with something that I love. To be honest, instead, a lot of my software projects have come from necessity instead. So I worked before I worked as an engineer, I worked doing basic IT work. And I was kind of the type of person who decided that I was going to code everything I could so that my day job would go by quickly. (Laughs) And so that type of necessity brought me into Python, which was my first language and like really cemented me there scripting. And that was honestly how I got my first coding job, but it came more from a world of necessity than it did from me really wanting to make a mark and leave some pattern of who I was. 

[00:22:09.00] SY: Yeah. So do you feel like because you, you aren't interested in doing coding side projects, do you feel like you've ever been punished for that or judged for that in any way? 

[00:22:25.00] SH: Yeah, absolutely. I feel like that basically, almost every job that I've interviewed with saw that as a red flag and then used that as an excuse.

[00:2:34.00] SY: Even now like at your stage now?

[00:22:36.00] SH: Even at my stage now, yeah. When I was going for MongoDB, and I interviewed there, I ran into countless startups where they just because there's that startup attitude of “oh, if you're not working twelve hours a day, seven days a week, then why are you here?” (Laughs) And it's just so toxic, you know? 

[00:22:54.00] SY: Yeah. 

[00:22:54.00] SH: So immediately when they see, “oh, you do other things in your free time,” that's a red flag. You'll never make it here at a startup. And I started eventually viewing it—even though I was unemployed, I viewed it as a way of me recognizing I would never be happy here. If that is the attitude that people are coming in and judging me from, so be it. Let them do that because I want a place where I can build a career and feel safe and actually work with my coworkers rather than having to live and breathe code the entire time. 

[00:23:25.00] 23:25 SY: It also makes me wonder where that comes from or where those expectations are set because when, in your example for example, with the startups, it makes sense because at a startup well, you know, you're rushing. You have limited funds. You probably don't have a real business model yet. And, you know, you have to kind of throw yourself a hundred percent into this thing in order for you to maximize your chances of being around next year, right? So it's, it sucks for the employees—well it sucks for kind of everyone involved, but I understand where that, that feeling comes from, right? For a place like MongoDB or just a place that's generally more established and especially if a person is a more experienced developer, do you feel like that culture that pressure of you should always have a side project, does that go away at all? Or at least like decrease or lessen in different contexts? 

[00:24:21.00] SH: I don't think it does, honestly. The only thing that's made that go away for me was just asserting these are the things that are important to me, and I'm going to keep doing them. 

[00:24:32.00]  SY: Yeah. 

[00:24:33.00] SH: And to be honest, it's kind of funny because by giving this talk at conferences, I've gotten the respect of people who want to see me going out and going to conferences, but they’re respecting me without listening to the actual talk that I'm giving (Laughs) which is like here's why I don't need to be going from place to place saying this. But I did that because I just identified it as something that made me really uncomfortable. And generally I feel like some of the better advice that I've ever heard was Michelle Obama saying run towards the noise, and that's like the thing that I live my life by. If something scares you like find out why it scares you. Run up to it. Really engage with it. And so that's actually the thing that got me started was just being angry that people were judging me for not having a side project and feeling like I was terrified of public speaking, and so I was just like oh let me deal with both of these. I'll tell people why I don't care, and I will actually go to my first conference ever. 

[00:25:32.00] SY: Yeah. To tell people that I don't need to be there. 

[00:25:36.00] SH: Exactly. (Laughs) But the funny thing is like I say that and then you get a room full of people who say oh my God me, too. I just haven't had words to talk about it. Because a lot of people are there doing these awesome things and my first talk was at AlterConf, which is a now unfortunately is no longer with us but was a series of conferences about really challenging what diversity inclusion actually means and working for like a lot bigger goals than just, you know, hiring and promotion but actually empowering minorities across the world. And what a great environment for a first talk because then I got to speak to so many other people who felt like they also didn't show up on the public footprint of their companies, but they love what they do and they want to be respected for it. And it just made me feel like oh this is worth all of that extra energy and discomfort that comes along with running toward the noise. 

[00:26:28.00] SY: Yeah. Absolutely. So it sounds like overall we really like noisy developers like really like people who are loud and prominent and out there and really excited to share their ideas in a very vocal, very public way. Do you feel like as an industry that has any negative side effects? 

[00:26:50.00] SH: I do. And I think it's because when we're listening to the loudest person, we're often listening to the person with the most privilege. I mean you get to be loud because that's what you feel that you deserve. 

[00:27:03.00] SY: And it's safe for you. 

[00:27:05.00]SH: Exactly. Exactly. Yeah, I think that you become loud because like you said, it's safe for you. You have this background of privilege that says hey when I talk, people are going to listen. And so I think the danger of that is then you don't actually have feedback coming in from, for example, your female employees or your employees of color or your disabled employees or people who are junior and still feel uncomfortable sharing their opinions. And then, as a result, you're looking at like a culture that's going to be pushed by the loudest people rather than pushed by the most engaged people. 

[00:27:40.00] SY: Yeah. So what advice do you have for people listening who might want to be quiet developers—they really want to embrace it, they're feeling all this pressure, they don't want it to, you know, negatively affect their career or their goals, ambitions—what advice do you have for them on how they can best navigate this industry? 

[00:28:00.00] SH: Honestly, keep doing what you love. Absolutely. And remind people of what you love. Bring that passion with you in everything that you do. And so when I'm coding, I'm treating people during our one-on-ones and retros with the same compassion and kindness that I've learned through dancing with people and through writing music and playing music with people. Bring your whole authentic self to the table and recognize that that means you're bringing a whole authentic self that might not necessarily be obsessed with the twelve lines of Javascript you've got to discuss right now. 

[00:28:33.00] SY: And that's ok. 

[00:28:34.00] SH: And that's ok. That's perfect—like when you're pairing, it's not about technical skill, it's about empathy. And...

[00:28:42.00] SY: Yeah. 

[00:28:43.00] SH: ...anything that gets in the way of you being empathetic, to me, is a disaster waiting to happen. By living as a full, authentic person at your job, you're going to be able to increase the way that you connect with other people. And so that means that as a junior developer, you're going to be able to learn faster because you're having a real, true connection with your more senior coworkers so that way you feel safe actually being able to ask any question that comes up or more importantly being able to say, “hey you know, this is something I don't understand. Can you help me out with that?” Or “can we repeat that” instead of getting caught up in this world of you are what you produce and therefore I need to be asking only the brightest possible questions, and I've got to stay ahead of the game, and I can't show weakness. Instead, I think by being yourself and opening up lines of compassion like that, you can show weakness and then grow from it and see that as just a part of your everyday life. 

[00:29:40.00] SY: Yeah. I like that. So I want to switch gears a bit and talk a little bit about your job. You are a UI engineer. And I don't know if I've heard of that before. I've heard of a UI designer, UI developer, but not UI engineer. What is that? What do you do? 

[00:29:56.00] SH: I always expected that they would call it just a front-end developer to be honest because that's kind of what I thought I was getting into, but they like to say UI engineer because if you look at line for line what I write every day, I would say 98% of the code is Javascript. And then you've got two percent of styling and templating, but almost everything that I do is Javascript. But it's all front-end. And so that's what they ultimately said UI was, was the Javascript portion, and UX would be like the templating portion. But I really do think that UI and UX have completely different meanings depending on where you go. And so usually I just tell people I'm a Javascript engineer. And then I get a lot of questions like, “oh, how can you be a Javascript engineer at MongoDB?” And then I have to actually explain that not only do we do this awesome database, but we also do the cloud services that help you monitor and run all of your databases and we also do database as a service. And so I work on monitoring tools that work for both of those. 

[00:30:53.00] SY: So did you have to know a lot about databases and specifically like Mongo to do that job well? 

[00:31:00.00] SH: It didn't actually come up that much in my interview, but the funny thing was that I had actually wanted to be a technical writer for MongoDB five years prior. 

[00:31:07.00] SY: Really? 

[00:31:09.00] SH: Yeah. Not five years, maybe three or four years prior. But I had devoured everything of their documentation as a result of that, and I never took a database class in my undergraduate. I had never even seen a database really before I saw MongoDB, which is a weird way of coming about to it. But I was totally into it because it's the document model so everything is a JSON or an extended JSON object. And coming as someone who knew JSON and was a Javascript person, I instantly was like yes this is great. Now this database thing that I'm scared of is something I can approach. And I had so much inane random things just from having read the docs over and over again wanting to be a technical writer. I came in there and just was like I am so excited by this thing called zone charting. I don't know if my job will ever have anything to do with it, (Laughs) but can we talk about it, you know? And I've never used that at all, but it's good to know, and I've worked on UI for people who do use that, so it's… I kind of walked in with the knowledge and interests of some of our users and then figured out, “oh what I actually need to know is completely different.” 

[00:32:17.00] SY: I feel like that's a really great way to interview though, you know? A lot of people who are just getting started or trying to figure out, you know, what's the best way that I can stand out as a junior, as an entry-level developer? And I think that if you can really appreciate the users' problems and contexts and issues and speak to that in the interview process, that can be a real asset. 

[00:32:38.00] SH: Yeah, find a way that you can become that user even if it's just surreptitiously for a little bit. At a job before that, it was a job posting site that I happened to work with that did like a unified application to apply to a lot of jobs in retail. And so, of course, the first thing that I did was create a fake account and look through all of the jobs

[00:32:57.00] SY: Yeah. Nice. 

[00:32:58.00] SH: And go in there. That way, when I went into my interview and I talked about it, I had questions as to where they were going from there. And I think the most exciting part for me in an interview is always the talk about where the product is going to go in the next few years. That strategy talk is just so exciting, and it also lets me show that I have passion about the product that I'm delivering and that I actually really care about how it grows and what I'm going to be able to do in order to make this company a better place basically. 

[00:33:28.00] SY: Very nice. So now let's move into some fill in the blanks. Are you ready? 

[00:33:32.00] SH: Yeah. 

[00:33:32.00] SY: Number one. Worst advice I've ever received is... 

[00:33:35.00] SH: Hide the things you get excited about. 

[00:33:38.00] SY: Interesting. Who gave you that advice? Why would someone tell you to hide the things you're... 

[00:33:42.00] SH: I've heard that I was—I was the type of kid who could not shut up about what I was excited about. And so in high school, it was like I had no filter. I would immediately be like look talk about music. This is the coolest music thing that I've ever run into, and people were always saying that I was kind of weird. And so I had definitely gotten the advice that I needed to hide the things that I was passionate about. And what I've learned as an adult is that it's just the opposite. Be super open about your passions no matter what they are because if someone judges you off of them, you probably don't want to hang around them anyway. 

[00:34:17.00] SY: Absolutely. 

[00:34:18.00] SH: Yeah, life is just too short. 

[00:34:20.00] SY: Way too short. Number two: my first coding project was about... 

[00:34:24.00] SH: So outside of school it was automating the creation of counts in this really old ad-buying software. 

[00:34:30.00] SY: Interesting. 

[00:34:32.00] SH: Yeah. It was just this process that was taking me sixteen hours every week of manual data entry and I was just like there's got to be a better way to do this. What is this thing that I've heard of called Python (Laughs) because I want to be able to script stuff from an excel document right into this program. And that was my first ever coding project outside of, you know, the standard Java things that I did in school. 

[00:34:55.00] SY: Very cool. Number three: one thing I wish I knew when I first started to code is...

[00:35:01.00] SH: Pair programming is awesome. 

[00:35:03.00] SY: It's so good. 

[00:35:04.00] SH: No, I didn't even know pair programming was a thing for the first like... and I was the only UI engineer, so I never got to work with someone else, and everyone was always too busy for me. 

[00:35:12.00] SY: Yeah. Yeah, yeah yeah.

[00:35:14.00] SH: But pair programming is great. And it's also great no matter who you are in the relationship for that. 

[00:35:19.00] SY: That is very true. Yeah. 

[00:35:21.00] SH: I'm finding myself at a mid-level right now where I can pair program with our interns and incoming new grads, and I learn so much from having to teach them. Then also I feel no shame in like pulling a lead engineer and then saying like ok I really can't figure out the architecture for this. Let's work on it. But it really is great. I wish that someone had told me that before my first job because I probably would have gone to a completely different startup and grown three times as fast. There's no shame in saying what you don't know. In fact, it's, to me, really super admirable, and I would much rather work with people who are vocal about what they don't know rather than pretending that that doesn't exist. 

[00:36:01.00] SY: Yeah, I love what you said about it working no matter who the person is. It's so true because when I work with senior developers now I get to learn a bunch of stuff. And I'm figuring out like what are their habits, what are their strategies what's in their toolkit,  but then when I'm working with someone who's more junior than me, then I get to teach and learn in a different way, you know, a different strategy, so yeah. It's really... 

[00:36:24.00] SH: Exactly. 

[00:36:25.00] SY: I don't think I've—yeah, I'm trying to think of like a downside to pair programming. I guess it could be a little tiring sometimes, you know? Like if you, if you're just kind of talking for a long time. 

[00:36:34.00] SH: Yeah, and I think also we have a rule on my team where we don't pair program unless you've spent more than half an hour on the issue because if you can teach yourself something, that's gonna be really super empowering. 

[00:36:46.00] SY: Yeah. 

[00:36:47.00] SH: And you can't really rely on someone else to give you all of the answers the entire time. But we also have the attitude that hey if you spent a half an hour on something and you're still stuck, chances are it's probably a good idea to drop what you're doing and help like work with someone else on it. And even if it only takes five minutes, (Music) you know, that's five minutes where both of you may have learned something. And at least you're not spending hours working on something that's frustrating. 

[00:37:09.00] SY: Yeah. Absolutely. Well, thank you so much Seán for telling us all about the quiet developer. You want to say goodbye? 

[00:37:17.00] SH: Yeah. So goodbye all y'all. Keep programming. 

[00:37:20.00] SY: And that's the end of the episode. Let me know what you think. Tweet me @CodeNewbies or sent me an email hello@codenewbie.org. If you're in D.C. or Philly, check out or local CodeNewbie meetup groups. We've got community coding sessions and awesome events each month. So if you're looking for real-life human coding interaction, look us up on meetup.com. For more info on the podcast, check out www.codenewbie.org/podcast. And join us for our weekly Twitter chats—we've got our Wednesday chats at 9PM EST and our weekly coding check-in every Sunday at 2 PM EST. Thanks for listening. See you next week.

Thank you to these sponsors for supporting the show!

Thank you to these sponsors for supporting the show!