Stories to get you to the next level

>> SPEAKER:  So excited to be here.  MidCamp is one of my favorite conferences, and I was sad to think it wouldn't happen, and then it happened, and, so, this is great.  Welcome to stories to help you level up at the first ever virtual MidCamp.  I'm so excited to have you here.  I got a new webcam just for this, and excited to go on a little storytelling adventure together.  This is a new talk.  It's near and dear to my heart.  It's kind of like an origin story, but it's kind of built in a way that it's to give you, um, ideas and tips on how to achieve the kind of career development that you're looking for.  The experiences kind of come from backgrounds like mine, um, being underrepresented in tech, um, and, so, it's really meant to support you and things you want to be thinking about and/or the struggles that you're currently facing.  So, my name is Fatima.  I'm better known on the Internet as sugar overflow.  I'm a developer and programs engineer at Pantheon.  I give talks like this one, write documentation, and engage with our open source communities.  I like emojis a lot and Pokemon, so you might see both of those things throughout this presentation.  

So, I think this slide is more for me, really, to talk about why I'm giving this talk.  This is, like, very different from the talks I usually give, but I wanted to talk about why a little bit, and this is because I was fortunate enough to go to a university for computer science, but I was pretty miserable for the first couple years, um, especially because I didn't feel like I knew everybody, I wasn't doing really well, and everybody else seemed like they had been programming for years, and I could give a whole talk about being the only girl in math or engineering classes, but fast forwarding a little bit, I ended up doing really well.  The last year, I found things that I was really good at, game programming or, like, understanding algorithms, so some of the stuff started to click, and I was like, okay, maybe, I can be a programmer, maybe, this wasn't a bad idea, but after I left university, I kept getting assigned to front‑end tasks almost at every job that I worked at.  Usually, it was because there was a back‑end developer on the team that was really good at what they did or didn't communicate in plain English and only spoke developer speak, and so I couldn't communicate with these people, and so I couldn't learn how to do tasks or get mentored on the things that I really wanted to do.  That's not to say front‑end development isn't awesome, I think it is. I'm actually, like, a huge consumer of pretty UIs and nice websites, but I started doing a little bit of back‑end development, and it was so thrilling that I was like, that right there is what I want to continue doing, but the hard part was finding, you know, space at jobs and talking to managers and being like, I know you know that I'm good at gaming, but what I really want to do is the back end, and, so, as I kind of struggled to get to that point, um, and then moved from there to developer relations, I learned a lot of things that I want to impart, um, to people who are navigating similar problems or people who are looking for new tools that might add to their tool set in their current adventure.  

Some of these are things that I wish I knew or wish I had thought of, I learned the hard way, and, so, hopefully, something will be of use to you that you can add to what you're thinking about and in your careers.  So, a couple of years ago, when I first started at Drupal, I landed a job at a Drupal agency.  I came into the company with a lot of fanfare, I was one of the few people there who had a degree, I was moving across the country to work for them and had already been working as an intermediate developer, um, but I was new to Drupal, so I did not understand hooks or any of the Drupal things, and, so, when I got added to a project team and I started working on things, I think my team lead gave me the benefit of the doubt, oh, this fancy developer has come to work for us, but whenever he would see my requests, we would head butt a lot, because I was making these small mistakes, I forgot to lynch my code, left debug statements in there, didn't test it properly, didn't check what happens when you, like, log‑out and then look at the node, and, so, like, I was able to build things, but I wasn't able to cast them thoroughly, so we went back and forth a lot on some of the code, and what would happen is, like, let's say that this two‑week sprint is due Friday, um, like, on Thursday, he would be so fed up, and he would be like, look, I've tried to go back and forth with you on this for three or four days, um, and we just can't continue doing this, so I'm just going to take it on, I'm going to fix it up, and I'm going to submit it to the client, and, like, that happened a couple of times, I would say, like, four times before I was so humiliated that I was like, I cannot be responsible for you to stay late, fixing my code, because I can't do it properly myself, and that's just unacceptable for me as a coworker, to not be able to, like, you know, hold my own weight in a way, and, so, being that he was, like, a really patient person and, like, always took the time to be like, hey, like, I fixed your stuff, I know we didn't have time to go over it, but, like, here are the commit messages, you can look it over, if you have questions, let me know, um, and, so, I was like, okay, how can I do better?  

So, I sat down with him and my manager, and I was like, this is not working, I am trying my best, but I keep making the same mistakes, and they were like, oh, maybe, you go too fast.  Like, we've noticed that you like complete tickets that are, you know, estimated for four hours and one hour, and, so, you should slow down, take your time, check the things before you check them in, things like that, and I was like, okay, I can try that.  I'm always in a rush, and, so, I sat with that for awhile, I tried working on one ticket and then finishing it and then not submitting it, starting the other one, working on it, and then, like, when the second one was ready, going back to the first one to review it.  I felt like maybe that'll give me fresh eyes, you know, maybe, I might see something that I missed the first time, like, reverse engineering the issues that I was working on to, like, maybe catch something.  This did help with things like leaving debug statements or, like, missing whole pieces of functionality, but, like, it didn't help on the, like, the larger scale, and so I was still doing things quickly and still missing a lot of things, and people still had to kind of, like, fix up my code.  So, I eventually, you know, we still had these head butt moments, and it wasn't, like, a great environment, so I went back to my manager and I was like, it's not that I'm in a rush, I don't think that that's the solution, because I'm not careless, I just don't know what else you want me to do, like, I've looked at it backwards, I looked at it for two hours, I've looked at it line by line, like, what more do you want from me, and, so, I think what we realized, we had this, like, lightbulb moment where I was like, I need more strategy, like, I need more pools or, like, tell me what you do, and, so, my team lead and I sat down, and he took, like, a pool request and walked me through, like, here's what I do first, I look through the dif, then I go line by line, if I see something that doesn't make sense, I leave a comment for you, and then I, you know, pull your branch down, I test it, here's how I test it, like, if it's something that's changing permissions, I test it with different users, if it's something that's, like, on the front end, I look at it from incognito, from all these other browsers, and, so, just sitting with him and seeing, like, his entire process for testing my code review kind of told me, like, all of the things that I could do myself before it went to him, so that by the time he did it, it would be, like, super clean, and, so, for me, that was really valuable.  

So, I took all of that, that helped, and then I think someone recommended to me, like, why don't you ask, you know, your coworkers or your friends who are developers, like, what their process is like, like how they take a ticket, and just because client work was new to me and so, like, how do people take a ticket, do they first, like, plan out what they're going to build, and when they're planning that out, do they prototype it, so, like, getting advice from everybody and trying to understand the different ways in which they worked, um, was really valuable to me, especially because before that job, I had been working in government all by myself, and before that, I was in school, and, so, I didn't really have good, um, examples of how people work, and I really appreciated that people were open about their strategies and their processes, and, like, nowadays, we have all these Slacks for different groups and people share their work and they blog about it, and, so, I think a great thing to do is to just kind of open yourself up to maybe there are things you can add to your work flows and things like that.  So, that was, like, a great success for me.  I learned a lot of good best practices and was able to kind of apply them in future jobs as well and work on more complex projects, um, and become, like, an asset for that company, but if we were to, like, really breakdown the things that I learned, um, more succinctly, I would say one was, like, feedback mechanisms, like learning to communicate and get and receive feedback, and the other was, like, um, figuring out how I can improve myself.  

So, when thinking about feedback, um, I've always found it's very, um, it's much easier to think about these things when you formulate and ask questions, so how can I best receive and give feedback, how do I like to receive feedback, you know, people have different ways that they like to receive feedback.  I once worked with a coworker who insisted she wanted to receive feedback with positive reinforcement, so we'd say, hey, I think what you did was really great, I think section A was particularly awesome, but section B, I think you could have done better, here's how, and then end it with, like, but you're doing great work and reinforcing that she was really awesome, and she needed to be reminded that, and that was, like, totally cool, but I've also worked with people that are like, please leave out all of the fluff and tell me exactly what you want me to change, and I will change it, and I've slowly become that person, where even when I'm driving and I'm, like, with a friend and I'm like, look, I'm a new driver, if I'm doing something wrong, just tell me, and I will fix it, and, so, know how you like to receive feedback, and then, you know, if you're lucky and you have a good mentor, you can talk with them about it, you can figure out different ways of it over time, but not everyone is lucky enough to have a great mentor, so you might have to figure it out on your own and then figure out how you can communicate that to your team and kind of figure out ways for your team to share and give that feedback.  Maybe, you like it in one‑on‑ones, maybe, that feedback should be, um, in a video call, face‑to‑face, or, maybe, you don't want that kind of, you know, face‑to‑face interaction, maybe, you just want it in an e‑mail that you can take with and sit on and kind of process over a couple days, and, so, check‑in with yourself and figure out what that is, and then, you know, as a team, I think one of the things that I've used at a previous job to figure out how we can work well together better, um, is something called a user manual, and so I learned about this when I was working for government in Canada.  

It's like a, you know, there's a lot of methods to build teams and collaborations, but I think this is a simple way to add new teams, or when you add a new teammate, maybe it's good to check in on everyone's norms, so this also includes the ways you like to receive feedback, but also, you know, the hours and times I like to work, best ways to communicate with me.  There should be a caveat that, like, not all your needs and preferences can always be met with this, but it's important for your team to kind of know what your preferences are, and there's value in making them explicit, so that people you work with, you know, have a sort of way or a measurement for, um, you know, to be on your good side, to kind of release some of that pressure that comes with, like, interactions and communications, and we can just, you know, talk about it.  Then the other thing that I considered from that job was, like, how can I get better at what I do, are there parts of my process that I can improve, things that I can learn from other developers or include in my tool set.  I ask myself this question very often, and as my coworkers know, I'm, like, super into connecting with folks together or using a new app and testing strategies, and, so, I have a couple of apps today that I think are always going to be part of my work flow that I want to share with you.  

The first one is kaleidoscope.  Kaleidoscope is an app that allows you to see a visual dif.  I actually wanted to show you a demo, so let me see if I can pull my terminal over here.  So, Alex is here on the call too, so I'm going to use the docs as an example.  So, the other day, I was working on our doc site at Pantheon, I was working on writing documentation for build tools, so let's say that I'm working on this branch, and I would like to see, like, okay, I'm almost done working, I want to see how many things I've changed and how they differ from master, so I would do get dif tool master, you have to kind of configure kaleidoscope to do that for you, but what's great about this app is it will put up all of the changes that I've made compared to the branch that I've specified, so I'm able to jump through and see, oh, here's some edits, here's removal, here's where I added a lot of text.  In this particular example, most of this is all language, because it is a docs repo, but when you're working with really complex projects and code and multi‑sites, it's great to kind of visually see that before you push anything or commit anything.  I know some people can be nervous about committing code that's not great, so this is a great way to check yourself and kind of test through as you go and kind of give yourself a little bit of confidence as well, and this is actually how I started figuring out that I was leaving debug statements in files, because, sometimes, when you're debugging, you're, like, jumping around all these different, um, parts of a project, but then when you've found the thing that you need, you forget that you left it somewhere, so this is great to find those sneaky little pieces that sometimes escape you.  So, kaleidoscope, really recommend that tool.  

Another one that I learned while I was doing front‑end development is screen float, so what screen float lets you do, um, here's what I'll do, I'll show you a screen‑shot of my notes, is take these floating screen‑shots and drag them around with you wherever you go, and, so, what's really cool about that is, like, if you're working on a ticket that's on Jeera, you can take a screen‑shot of that, take it with you, you know, if you've got some markup that you want to keep on the screen while you're working, um, it's really awesome for little pieces of things.  I call this, like, a convenient solving app, because I don't think that it's, like, mission‑critical, but it definitely makes my life easier sometimes.  So, I linked these on the slides, and I think the slides, I'll upload them to, um, the page, but thank you, David.  Always on point.  Um, both of those apps, I think are paid.  I think screen float might have, like, a free trial that you can test out, but you can always look at the dif on GitHub as well, and it's gotten better over the years, now you can sort by type of file, you can sort by language, you can have discussions here.  When I started working in government, they had never used GitHub before in Canada, so a lot of the things we did here were really useful for them to, like, share and collaborate on code in different ways.  Snippets lab is another really cool one that I haven't setup on this laptop yet, but what it does is you can save different snippets, um, different languages, different things that you write repetitively, like a really cool function that you wrote, maybe it was a hook alter for something that you think is neat, and, maybe, you don't want to share that with the rest of your team, but you can share that with yourself, and you can keep it there, and then it's also got some integrations with things like  Alfred, which is kind of like a spotlight replacement, so you can have it down into things.  

I was working at Transport Canada, and I think everyone was really nervous about working in branches and, like, how can we all work on the same code together, and, so, GitHub was great for us to get familiar with that.  Another thing that I learned from my very great, supportive mentor back in the day, um, was the git add‑patch command, and this lets you add pieces of your code, so let's say you've changed, like, 15 different files, if you do git add‑P, it'll show you each chunk at a time, and you can be like, yes, I want to commit that, or, no, I don't want to commit that, or I'll take a look at that one later, and it's really great, because it's interactive, and it's really fun to, um, it's fun, and it's also really useful, because you can kind of parse through all of the changes you've made, so if you're not looking at them visually, like kaleidoscope, you can also do it this way.  I usually did get add‑patch first, and I say yes, no, yes, no, and then when I'm done, I take a look at it in kaleidoscope again, just to make sure, because I think looking at code in a terminal window versus looking at code in, like, a visual window, it can look different, and that can help you catch changes.  What I also like is it'll be like do you want to commit this, and I'm like, yes.  All of this to say that you should totally build your own work flows.  When I was working with client sites, I learned a lot about, like, Drupal and all the different things that you should do in order to make sure the thing that you did is working, and, so, I started creating checklists, and at first, it felt really silly, I was like, oh, I'm creating checklists for things that I'm going to learn how to do, and then, maybe, I'll never use them again, but, actually, they were really useful, because the more you repeat tasks in this way, the more you'll start to remember it, and, so, you know, if you're someone, like me, who likes to make lists, lists of things, like, create a checklist, and then, eventually, you'll just, it'll just become your habit.  

So, there's a lot of blog posts around, people talk all the time about how they do development, and, so, what I do is I read them and then I take what I like and then I put together my own work flow.  We are at 20 minutes.  Oops.  I have another story, and then I have more stuff.  I'll just keep going, and then I'll try to leave some time for questions.  So, the second story that I had to share with you today was about getting promoted.  So, I started working at a job where I was told, in six months, I would get promoted from, like, a junior intermediate level developer to, like, a leadership level developer, but six months in, they were like, hey, we can't really promote you just yet, we don't think you're ready, you need to work on a bigger project, you need to work on a more public project, it's not really fair to the other junior developers, and I was like, okay, but, like, other junior developers and I are not at the same level, like, this isn't really fair, like, what are the metrics that you want me to meet, what's this, like, hypothetical you're not ready yet, and, so, there were really no clear guidelines at that job.  I was told things like you should do 15 percent more mentoring or 5 percent leadership, and, like, that wasn't really clear to me, like what that meant, and it was a really hard metric to, like, reach, and, so, I asked the person that I was mentoring, I started mentoring someone at work, and, so, I asked them, like, hey, am I a good mentor, and he was like, yeah, yeah, you're great, like, I'm learning so much, and I was like, please mention that to your manager to mention that to my manager, because I'm having a hard time getting a promotion, and he did that, and that, you know, my manager was like I kind of heard from so and so that you're doing a great job, and I was like, success, but that still wasn't enough.  I really had to fight for it, and, so, we had a client that really loved me, working as a back‑end developer for them, but my company would take me off that project and put somebody else on it, and then the client would be like, nope, we want her back, and I was like, this is a great opportunity for me to use, and so the next time the client was like, hey, like, we saw that they took you off again, but we really want you back on this project, I was like, when you ask, can you also, like, put in a slight recommendation, um, and I was like, I'm taking you into confidence, I'm trying to get this promotion, it's been six months, they're delaying it, and, like, your word means a lot to the company, so if you could do that for me, that would be really awesome, and they were like, absolutely, yes, we want to support women in tech, and they did that, and my manager, I think she, at that point, realized what I was doing and that I was getting a little bit sneaky with it, but, you know, it worked for me, but, sadly, it turned out that, like, that promotion was just a lot of burn‑out and a lot of work that I didn't really like, and, so, it was, like, I thought it was the job I wanted, but I eventually left after that, because it was just not great management and not a great position, and it was just, like, a lot of overtime, but I did learn a lot from the experience, and I wanted to share some of the things with you.  

So, what do I think about when I'm thinking about different roles?  It's like, what do I want to gain from this job, where do I want to be a year from now, maybe three years from now, does this role help me get there.  If you're already in a job, what are your organization's policies for promotions, what's that career ladder, where can you grow, and then, you know, think about things like is this role fulfilling for you.  I think a lot of people forget, um, women especially that, like, the job is not just for the company, the job is also for you, it's not just about what the company is giving you, but it's also about what you're giving the company, and, sometimes, the thing you want isn't what's right for you as a person, so be kind to yourself and try to figure out, you know, what the things that are important to you are.  For me, some of that is, like, what's the feedback mechanism, like what kind of performance reviews happen, when do they happen, who do they happen with, and those are the kinds of questions that I ask when I'm starting a new job.  From being sneaky, I've learned a couple of things.  Track your own time.  If your organization doesn't track time, just do it yourself.  I do this, because then I can export, you know, the things that I work on, and that gives me kind of fuel for having conversations, like, maybe, I'm doing too much of this project, even though our priorities is this project, um, and, so, I've learned that, like, if you don't have the data, people just talk about, you know, their feelings, often, like, if a manager ever came to me and was like, I feel like you didn't do enough mentoring, I'd get really frustrated, because I'd be like, A, that's probably your bias, but also, like, you scheduled me for too much other stuff, so I can't do any, so to avoid some of those conversations, I've learned that, like, just have your data and, like, use your data, and I used to, like, look at my harvest at an agency and make sure that it was matching up to the promotion harvest, so I was still, like, 15 percent mentoring, so I was making sure that the hours I had logged for the quarter were around 15 percent, so that I could go into my review and be like, there, I did what you asked, now give me the title.  So, check your time.  

Some of the ideas that I thought about to explore, things that I've, some of these things, I've done, like being really clear about your goals, I've been really honest when I've joined some companies where I would just say, hey, I left my last company because they promised things, and then they didn't do it, and then they just used me as a diversity token.  I don't want that to happen here, so I'm putting that upfront, so just be really clear.  Sometimes, people appreciate it, sometimes, they don't.  You're better off at the places that do.  Sometimes, if your team's really toxic, um, I had a pretty rough experience in my fellowship project, where my teammates didn't really get along, so we did all our meetings and conversations in a team Slack channel, and we had somebody from, like, upper management as a mediator to kind of help some of those conversations when they got a little bit too heated.  It was honestly the most difficult team that I worked on, but having conversations in the open helped everyone be accountable, that people were watching, and so that was helpful.  Stuff to think about, know what's important to you, you know, um, some of the things that I think about when I'm looking at jobs are kind of like, um, what's the benefits, but also things like who are my teammates, who leads this company, what are their values, are those values in alignment with mine.  So, I have this, like, list of 35 questions that I ask myself when I'm looking at a job or a role, and then I kind of rank them, like, this meets the expectation, this doesn't, this company does it really well, this doesn't, and it's not the data that's important or the weighted scores that's important, but it's the process of kind of going through, like, what's important to me, what's important to this company, do these things line up, and then the other thing I do is research people that I think are cool, I just, like, go to their Linked In's, read their blogs, see what their career trajectories are, see what they studied or what kinds of things they're working on, because those are the people that I think are awesome, and by looking at what they're doing, I can kind of figure out the things that I would like to do.  

The most terrifying advice that I've always gotten, that I've always, like, been really scared to use is ask for the job you want.  Don't be afraid to just e‑mail someone you've met at a conference, maybe you had a good interaction and be like, hey, I know you work, I did this, I was like, I know you work here, and there's a cool person who writes really cool blog posts and is part of community initiatives, like, I want that job, and it turned out that, like, it wasn't a great team to work on, and that's okay, but it was a good practice to just go and ask for the thing that I wanted.  Finally, um, continuously reevaluate your job and the environment that you work in.  Just because it's really important to remember that there is a balance, so things that the organization provides me, things that I bring to the organization, there are a lot of times where I felt that this balance would get skewed.  When I was working for my first job out of college, so, like, what the organization provided me was, oh my god, this is civic tech, I'm working for the people and running all the systems for the city of Boston, oh my god, my hours are awful, but that's okay, because I'm doing this amazing work that is civic, and, so, for me, it was like, the balance was like this, where the organization was, you know, it was cool work, and I didn't feel, you know, that great about it, but I was willing to do it because it was worth it, and, for me, it was like, it's okay that I'm suffering, because I'm doing something really cool, but as I got older, and I'm still pretty young, so it's funny to talk to veterans and tell them that, but, um, as you get older, you start to kind of not want that work‑life balance to be really awful, so please continue to evaluate, you know, what your balance is, what you're bringing and what the organization is giving to you, and if the organization stops giving you the things, um, or the things that you came there for, like, it's okay to leave.  

I had a really, um, eye‑to‑eye conversation with a manager once where I was like, there's things I came here for, and you're not doing any of them anymore, and she was like, wow, okay, let's try for the next three months and see what happens, and three months later, we checked in, and she was like, I'm sorry, like, we either don't have the resources or we just can't support you in those ways anymore, and I was like, well, I guess that's goodbye, and that was, like, the nicest way that I left a job, because we kind of just realized that, like, it wasn't working out anymore, and, so, yeah, evaluate your balances.  And finally, have friends in your life that think you're awesome, because at the end of the day, we live in a really, really tough world and tough times, and, sometimes, we forget to be kind to the most important person, and that's ourselves, so check‑in with yourselves and your family, and when you feel like things are going rough, trust your instincts and talk to your friends.  I forgot to put the feedback link in here, but, maybe, we can put it in the chat. 

>> SPEAKER:  It's also on the session note on the MidCamp site as well.  There you go.

>> SPEAKER:  Awesome.  Thank you.  I think we have, like, 2 minutes, but I'm also on the Slack and on Discord and am happy to have one‑on‑one conversations with anyone, if you want to reach out to me.

>> SPEAKER:  Yep, and another thing that, um, that other, um, talks and rooms have been doing, there are rooms for each channels, the MidCamp Slack for each of the rooms, so, sometimes, Q & A has been going there.

>> SPEAKER:  Okay, sure.  I can create a Slack channel.

>> SPEAKER:  It should already be there, so you can just join it.

>> SPEAKER:  Oh.  What should I search for?  Oh, it's like, it's the room number.

>> SPEAKER:  314B.

>> SPEAKER:  Yes, we're 314B.  So, I'll be in 314B, because I didn't leave much time for questions.

>> SPEAKER:  Great.  Thank you so much.

>> SPEAKER:  Thank you for coming. 

>> SPEAKER:  Everybody can un‑mute and, like, actually clap.

(Applause.)