*APAC Heritage Month* This is What a Technologist Looks Like

Hi there, I'm Gretchen. You're listening to This is What a Technologist Looks Like. We've got a series of talks happening going over six weeks to show you the opportunities that are available in the technology industry. We also take a little look at what the people in the industry are like and how they got to be where they are. So today's guest has taken the long, long, long winding road to technology. It's a fabulous story. It's got a bit of engineering, a little bit of economics, some advertising, and a fabulous trip to Texas. Bianca, good morning. Welcome. Morning, Gretchen. So Bianca is joining us from Perth, which means what? 5.30? 6am here. Yeah. Thanks for getting up. Anything for you, Gretchen. So you're currently working at Atlassian. Can you tell me a little bit about what you do there? What each day looks like? Yeah. So my title is a software engineer. How to put every day into one. I guess like a general sense, you would always have stand up, which is the team gets together, discuss what you did yesterday, what you're doing today. Good opportunity to kind of talk about maybe where you might need a hand. And then for the rest of the day, you might work on that card, you might be discussing with people different solutions to that card. Yeah, you might be. Yeah, there's a lot of... I wanted to ask, when I first started in tech, I couldn't figure out why stand ups were called stand ups when they weren't always standing up. Is there a history that they were standing up and that you had to rush through? It's because it's meant to be quick. And if you're standing up, then you don't want to stand up for too long, which is ironic because everywhere has standing desks now. So that doesn't really fit anymore. It's one of those things you're like, do you still stand up? How does this work remotely? Yeah, remote. You're just sitting at your desk. The thought is it's meant to be quick. I like it. So each day is a little bit different, right? Depends on that piece you're working on right then. But it doesn't sound like you spend the whole day in front of a computer writing code. No, I think that's one of the biggest misconceptions about what software engineers do. Like a lot of what you do is around discussing with people what the best solution might be, what the actual problem is. Because if you don't understand what the problem is, how can you know how to code it? And yes, a lot of discussions are around that. There's discussions around what feature you should build next, what thing you should work on next. So yeah, there's many different aspects to it other than just coding. So when you have those conversations about what feature to build next, who's in the room? Is it software engineers? Who's making those decisions? So every team might work a little bit differently. Generally speaking, you might have a product manager that's been the person between the developers and the customers. They might have gone out, spoken to customers, understood what customers need and come back to you with perhaps a few options. So it's between understanding what customer needs and then also, yeah, the developers do have a bit of input into what they think should be worked on next. That's cool. I like that concept of having more than kind of one type of voice making the decision in that. Yeah. And I think it's important because developers also need to put the customer first and understand what the customer needs. Because you're the ones building it for them. So you need to have them in mind to be able to build it well for them. So you don't just get to build the fun thing you want because that's the fun thing. I mean, sometimes. Sometimes you'll have different weeks where they do it. Like the companies will allow you to build whatever you want for fun as like little experiments. I like that. So let's wind back a couple of years. Maybe five-ish. I don't know. I'm trying to guess your age as I do this. When you were at high school, was your game plan to have a job in technology? Not at all. I didn't even think about tech until after I graduated university. Sorry, what? So you did high school and uni. Yeah. Hold on. A little older than you think. But yeah, no, I didn't. I didn't think of tech until after I finished university. So I did think I was going to be a civil or structural engineer. But after some work experience, I was like, no, thanks. So you did the whole degree, did work experience and went, it's not really my jam. I'm not loving this. Yeah, I did. I did three quarters of an engineering degree, finished off at economics and marketing degree, did a marketing grad program, worked in marketing. Then, yeah. Yeah. So that is indeed a winding, winding road, right? I know we met when you were in Texas. So you went from marketing and then went traveling. Yeah. I just thought this, I don't know what I want to do. Why not go overseas? So I went and lived in Texas for a little while. And I think that's where I was like, I was trying to think, like, what do I want to do? And I realized I wanted it. I wanted a skill. I wanted something that was universal, that I could could travel with or move around with something that I can like potentially if I wanted to create something of my own. And tech was just really fitting to the kind of lifestyle that I wanted. So you were looking for a bit of freedom and the ability to actually create something, which is fabulous because so often, you know, you end up in a job and it's actually, there is no creation of a thing. You're just doing stuff all day. So it's, I like that you were looking to create. It changes how you see the world. So how, so you're in Texas and you go, okay, I think I might look at this kind of thing. What next? I tried to teach myself online. So I was looking into, yeah, yeah. But I didn't know anyone in tech to tell me like what, what languages I should learn, what resources I should use. And because I did know that in tech, everything changes so rapidly that I could learn something, but it may not land me a job because what if that's not what companies are looking for anymore? Like that it's outdated or something like that. So yeah, that's when I was looking into different courses that I could join. I didn't want to go back to university. I'd spend enough time there. Yeah, exactly. So then I was looking into different courses and found myself a little bootcamp in Melbourne for six months. And bootcamp sounds brutal, is it? Yeah, it's, it is a lot of work, but I went in there with the mindset of like, I just have to learn one thing a day and I can't overwhelm myself. Like as long as I'm getting something out of it, then it's, then it's worth it. I wasn't trying to, I think it can be a struggle for a lot of people who put more expectations on themselves. Whereas I just wanted to get out what I could and that was okay. And I mean, I'm looking at your career trajectory. I think you got out what you needed, right? So how did you manage to get lots of people are doing bootcamps, right? There's not two people coming out of bootcamps in your city. So not a lot of competition for junior developers. It's quite a hard road to get your first job. How did you manage that? I, I got quite lucky in hearing about a grad program that was open at MYOB. And I interviewed for that whilst I was at the bootcamp and was fortunate to land that whilst I was studying. So that was really lucky, but I think definitely looking out for those grad programs that are around and talking to different companies. Yeah, networking is really important. Cause I think going through a grad program really set me up, but it's not to say that you have to go through a grad program to, to end up anywhere. You don't have to, but it's definitely a good, good in and it, and it allows you companies who have a grad program. They generally allow a lot of resources to your learning, which is really great. We had a quick conversation back in the green room comparing, you've got someone you went through the course with who went to a startup, whereas you went to a grad program and they had two polar extremes. Could you just talk a little bit about what, like that dichotomy? Yeah, it was really, it was a really cool conversation. So it felt as though in a startup, you were thrown in the deep end and you got to deliver straight away and kind of figure it out or as, as you're going, whereas in, in the grad program at the large tech company that I went to, I, we were learning for months and we had particular curriculum that we were getting out of it. And what it kind of meant was that James in the startup kind of wished he learned a bit more about best practice early on, whereas like, that's what I got straight up, but it meant I didn't deliver too much later. So that was the trade-off of yeah, I kind of got that best practice straight away, whereas he got to deliver and get his hands dirty straight away. In my mind, I'm seeing this fabulous thing that James has built and done the absolute best he could given the skills and resources he had, and then the company growing and someone coming in and going, oh, let's just start again, shall we? Which definitely would happen, I'm sure. But yeah, I think every developer does the best they can at the time. Absolutely. And he would have learned, you know, really wide and broad things that, through a grad program, you wouldn't get a chance to even get your fingers dirty with because they'll be like, oh, don't break that one. Yeah, exactly. The extremes just blow my mind. And both journeys are really powerful and have given you like, I'm going to use the word power again, they're like superpowers are different now you've come out, right? Yeah. And I think you've got to, in either situation, you've got to be open to kind of being aware of like, I had to be aware of things that I needed to learn to grow in terms of, you know, I've got to play around with different technologies to make sure I get that broad experience. And then James had to make sure he was asking questions about best practice to make sure he was getting that. So even though you're in either situation, as long as you're making an effort, like aware of the things that your gaps, then yeah, you'll get. And I guess any organization will have those gaps. It was just the two of you were at such extremes. It's really interesting. Yeah. But we both ended up somewhere great. So that is so true. Yeah. In line with that. So you've had previous education that in appearance has nothing to do with anything. And you've had different life experiences, you know, traveling and being out and about in the world is such a wonderful thing to do. Do you think any of that was a waste of time? Not at all. I think if anything, it has helped me. And the way in which it's helped me is, as I mentioned earlier, when you're developing, you really have to have the customer in mind. And given like my marketing experience I've had or even, yeah, traveling experience, you get to learn and try to understand more about what customers needs, what a customer needs. And yeah, that has definitely helped me in developing because we can we can get so stuck into how to implement. And what I mean is like how to write the code for this thing to work. But there's a difference between just getting the thing to work by coding it up and getting it to work. Well, yeah, there is definitely a big difference. So, yeah, not at all. I think if anything, the experience has helped me be a better developer. Do you think the businesses you've worked at have recognized the transferable skills you've had? A hundred percent. I think that's I think that's kind of my edge and my difference to many others, is that I have had that previous experience and I do have that kind of different look, like different outlook, different. Yeah, have gone through those different experiences to help me work through the problems we go through. I really like hearing that that's something that's valued because I mean, technology is known for having a whole heap of people that look and think the same building the products. So this is a counter to that. And that's great. And that's what they that's what they want. They want people to yeah, they want diversity of thought. So that's something that's really valued in tech. And so you went from Myob to Atlassian and like that's an Australian, I don't even know the word, unicorn. I think they call it the unicorn. Yeah. It's so well known. What made you look to a broader, bigger organization? Was it time for a bit more growth? Yeah, there was definitely that. My main reason was I wanted perspective. I understood how Myob did things, how they solve problem, how they had different practices and processes. But I just wanted perspective on how it's done elsewhere. How is it done? And so I wanted to go to a company that I knew have it set up really well. I want I wanted to see how things could be done really well at the at the extreme scale. Yeah, exactly. And how that works. So I had a few companies in mind. And yeah, the Atlassian one popped up. I think the day I had it sitting the application sitting there for a little while. And one morning, I just went like because I hate writing cover letters. I hate them. And one morning, I just went, you know what, I'm writing dot points. And I wrote three dot points. And yeah, then got a call to go through the interview process. Wow. I'm so impressed with this. It's it's the most fabulous story of, you know, from hating an engineering degree to being a software engineer. Yeah, the difference is buildings don't change. The wind calculation is always going to be the same, whereas in tech, you're going to be using a different language, something new is going to pop up, you'll be building something different. Yeah, very different. Everything you've talked about here has always required you to learn something new and something else and look for knowledge, you know, regardless of whether someone's telling you to or not, you seem to have a sense or a strong desire to keep improving and learning and fixing and changing. Is that just an innate part of you? And is it needed in tech? Oh, it's 100% needed in tech. If you if yeah, you're always even every like yesterday, I started working on a different code base that I'd never seen before, but you've just got to pick it up and go with it. And but that was part of I spoke about like the lifestyle I was looking for. And that was part of the lifestyle I was looking for. I wanted something that was never going to be the same. I was always doing something different, could yet could grow, could learn. And tech is all about that. So yeah, I really enjoy that part of it. And yet, tech offers that for everyone. So tell me a little bit more when you get a new code base, do you sit there and read it like you'd read a book to try and understand? How does that go? Do you just go? It's a bit of fumbling around a bit of just searching for different keywords. I would always one thing I always do when I jump into a new code base is I look at the tests because generally your test should tell you all the logic that exists within the code base. So you start with the tests, read those, and then and then you can look into the code base to try and figure out where something is. Have you ever seen something and gone, I just don't get it? What are you doing? Yeah, almost all the time. And what do you do then? You you I do try fumble around a bit longer because generally if you give yourself a little bit of time, you'll probably figure it out. But always just ask someone. I hassle my team teammates all the time. Hey, can you just jump in a call with me? And everyone's so willing to help. I've never I've not met anyone within the two companies I've been in so far that aren't willing to help. So yeah, which is really good. Is that a recognition that tech is hard? Is it a recognition of that that people are willing to help and encourage and bring you along the journey? Do you think? Yeah, and I think there's just a like a I think people in it love to share their knowledge because there's so many someone could be a senior and I could be a junior, but I could have worked in. So for example, I had worked with Kubernetes before and the senior in one of my old teams had never worked in Kubernetes and wanted to learn about it. So I was I was teaching, sharing him, sharing with him a bit of knowledge I had about Kubernetes. So I think that's what's really cool about tech. There's like a humbleness in that even though someone might be senior, someone might be junior, you know, completely different things and you just are open to sharing that knowledge. That's such a great environment to be in, right? It is. And I think that's how that's how team works. Like you have to share that knowledge in order to build the best feature for a customer, because if you don't share your knowledge with the next person who needs it to build that thing, it's it's not going to be built. It's yeah, it's a very big team collaborative sharing, sharing knowledge culture. So it really isn't the guy in the corner who's a legend doing everything by themselves anymore, is it? No, no. I actually I've started a little podcast wanting to like remove that stereotype. Yeah, exactly. That's saying that a software engineer is someone sitting in the corner and there's like green. Everyone's like, do you just watch green flashing words across the screen all day? Like a hacker? Yeah, exactly. I'm like, yeah, that's that's what I do all day. Hey, tell me, so the motivation for starting a podcast was to dispel the myths and I guess smash some of the stereotypes. How many episodes have you done? Tell me a little bit more. I've so it's called Uncode with Bea and it's on Spotify, Apple Podcasts, whatever you want. But it's I've only done two two episodes so far. So the first one's around how I got into tech. The second one's my conversation with James around a startup versus a large tech company. And the third one, which I'm in the middle of creating, will be around I think everyone always asks what language you should learn first. So that one's around that question there. So, yeah, I kind of started it because I would get a lot of people asking me, how did I go through a career change into tech? How did I get there? What did I do? And as all good software engineers do, we don't like to repeat ourselves. So I thought I'd put it out there once. I love that. That is so well said. But I'm really intrigued. Which language should I learn first? So there is no, I was like, everyone's probably going to hate me for this answer, but there is no one right answer. I kind of went through a few different scenarios around what you're looking to get out of learning coding. And depending on that will depend on sort of what which direction you should go to first. So should I start with C++ ever? I've never even written it. So no, I do not mention C++ at all. Do you think some languages are a lot easier to learn than others? Do you think? It's hard to answer that question because I only started with the one I started with. But I do think, yeah, there is definitely easier languages like Python and Ruby are generally meant to be more human readable. So they're definitely ones that you could kind of follow along a bit easier. And then, yeah, then you've got a few tougher ones. But in the general sense, as long as you start, you just got to start learning like your types and just kind of start playing around with something. And then you can at the end of the day, even though languages are different, they have those commonalities that you can kind of transfer across. So if you start with a kind of gateway language that you find okay and kind of readable, then maybe that's a good way to learn the structures and the systems and the types. And then you can transfer it over. Does that sound reasonable? Yeah, you can transfer. Yeah, exactly. Like types, you can always transfer different things like learning what an if statement is, a for loop, those kind of general concepts will all be transferable. Gosh, is it like I feel like you've gone and learned a language and then you've had to go and learn another language. Does it ever stop? No. And do you want it to stop? I don't know. Someone I so in my grad program after learning, we went into rotations. And in one of my rotations, I said to my mentors, I was almost in tears. And I was like, I am terrible. I can't be a developer. I don't know what I'm doing. It was like a real big lull. And they said to me, Oh, if you ever stop having that feeling, then you should get in a you should go to a different industry and do something else. And that kind of stuck with me because it made me realize like, okay, everyone, all developers, no matter how long you've been in the industry, probably go through this like, oh, this is really hard. I don't get it. Should someone be paying me to do this? Yeah, exactly. But when I've spoken to a lot of other people, a lot of people do go through those. Oh, I'm great. I've, I've learned everything to wait, I know nothing. And then, oh, wait, I know everything again. So I think that's what developing is like you it's a constant up and down, but you've, you've got to go with it and appreciate that that's what this industry gives you. And you get some great wins. Like the wins are unbelievable. Oh, they are. It's so good when you've spent so long trying to figure out a bug or trying to figure out something and then it works like it's yeah, it's a really good feeling. So the highs are definitely worth it. And then someone asks you to present a slide deck and you're like, why can't I do this? Do a good slideshow. Oh, even the best, the thing that I love was back when we were in the office and no one could get the, like the TV screen connected to the meeting. And I'm like, how many software engineers does it take to figure out a meeting room? It's brilliant. I can picture it. Yeah. Some seriously strong opinions on this question, but I'd like to hear your thoughts. Is there a particular skillset that lends itself to career, a career in tech? And I think you've kind of alluded to what you, what you believe here. Yeah. I think I just go back to diversity of thought is so important. So I think the one thing every developer needs is a willingness to, willingness to learn and openness to feedback. To be vulnerable. Oh yeah. As long as you've got those two things, I think you will succeed. But other than that, bring anything to the table. In regards to openness to feedback, is that hard? What if you don't have that innately? You know, what if someone comes up to you and hey Bianca, I'd just like to talk to you and you go, oh, if that's your response, how do you overcome that? It can be really confronting. So the reason I say that that's really important is because, so if you think about like with friends, like someone, you know, can get quite upset if you're giving them feedback, you're often not going to give them feedback. You're just kind of going to let it slide. In tech, in order for you to grow and learn, sometimes the solution you've come up with is not the best solution and you have to be open to hearing other people's ideas and reasons to why that solution might be a bit more suitable. And if someone knows that you don't take feedback very well, they're less likely to give it to you. And that's an opportunity you lose to learn. So that's why I say that's important. I like how you frame that around, you know, if it's your friend and your friend says, hey, you suck at this, it is going to hurt more. But if it's some code you've written and there's a better option, there is a separation between you as an actual human being and the code you wrote. Like it's not, they're not criticizing you, are they? They're just saying, hey, we can do this better. Look at this. And then you don't. Yeah, exactly. That's something I learned very early on and it stuck with me. And it's one of the best lessons I learned is to not be married to your code. So my mentor used to come up to me, sit down, say a bunch of stuff, write a bunch of things, delete my entire code and walk off. And I used to be so scared. I'd be like, but it worked. And I think that goes back to there's a difference between it works and it works well. Oh, it's a feel well, sorry. But so I learned that lesson very early on that you should not be married to your code and to be open to changes. But yeah, that was quite scary. I do always bring it up with him, but he's like, no, I'm glad I did it. And I'm glad he did it too. It seems like you learned a lot from it. Yeah. Oh, I did. I'd sit there scared for the first few times, but then I realized it was fine. It was done with good intent, right? Like, yeah. If you were talking to someone who said, I'm interested in a career in technology and they were, let's say, a 16 year old at school, what would you tell them? Do it. It's fun. No. Okay. So in school, I would kind of want to ask them what they're interested in about it, like what sort of aspects they are interested in it. And then, yeah, maybe assist them with which path they should take. You could point because there's so many, right? It doesn't have to be a compsci degree. No, there's a really good high school score. Yeah. There's so many boot camps available or short courses or online and each different path is suitable to different people for different reasons. So yeah, you definitely have to find which one suits you and they can all get you to the same point in the end. That's true. Such a great point. So many winding roads to get there. I've got one final question for the day. Oh my God, it's gone quick. I know, it goes fast, right? What is the biggest myth about technology? If you had to pick one. That we all wear black hoodies. I'm not doing well because I'm wearing black right now. No, I know. I think my actual biggest one is one we mentioned earlier was that we sit staring at the screen with green words flowing across the screen. And it's not like that at all. It's very collaborative and creative. So you're not a hacker is what I'm hearing. And you're not going to appear in a movie. I mean, if someone asks me why not, but no. Disappointed Bianca. It's like the stereotypes that is so entrenched from movies and partly because it was what it was like no longer exist, which is awesome. And I'm hoping with the podcast, it can, you know, maybe get out there and start teaching people. That's not what it's like. Which is brilliant. Hey, thank you everyone for listening today. Bianca's had the most amazing journey. And like we said, her podcast exists. There's a link in the description on the Cloudflare TV site. So please click on that and follow. Our next episode is on Tuesday, the 8th of June, and we're chatting with Nicholas Smith, who was an engineer from Australia Post. Thanks so much for joining us. Thank you.