Transcript
Christian Espinoza:
When you pick up your phone and call your friends or your family, or a client, you're making a connection. When you open up your favorite messaging app or check your feed to see what everyone else is up to you experience a sensation, which maybe feels good, or maybe it doesn't. But these emotional responses are a by-product of the apps you use and the way that they make you feel. But behind these apps are lines and lines of code written by computer programmers who can write in multiple computer languages and they develop the front end displays that you become so familiar with that you see sometimes every day and even multiple times a day. Today, my guest is Sigourney Juno, also known as Siggy. She is a software engineer at Voyager working in the voice tribe. Siggy has the uncanny ability to see the logic in almost everything, not just lines of code, but real, tangible things like coffee machines and even drones. She is able to pull something apart, figure out what it does or what it should do, and put it all together in a way that is practical for someone to use. Despite being buried under machinery parts or lines of code, she very clearly understands the need that customers have as we'll find out the job is not without its challenges, but every day Siggy does what few others can do. And today I find out her story.
Christian Espinoza:
I wanted To start off with really just a day in the life of a developer. Give us an insight into what a day in your life looks like?
Siggy:
So normally in the morning I come into work and then I check my teams and make I'll check my messenger and make sure that there's nothing really important that I need to deal with before the first meeting of the day. And then we have what's called a 'standup', which is where all the sort of development focused people are now try like the scrum master, engineers, sometimes product owner and all the developers. And if there's any testers in them too, we all have a meeting where we just go around and basically say what we did yesterday, what we're going to do today. And we talk about any problems we may have, and then we arrange meetings to happen after the standup to address those problems with specific people. After the meeting, either I normally continue on with the task I was doing the previous day or I will, I'll take a task off the board if it would be a defect or a feature, or if sun, not sure I'll talk to Logan, my scrum master or John the architect. And I'll ask them what is the highest priority? Because more often than not, it's not the thing, that's at the top of the log.
Christian Espinoza:
Right so you might be dealing with quite a few tasks or quite a few work items, right?
Siggy:
Yeah, yeah. I often have to pause halfway through something, then drop something because something's happened somewhere else in the company, or there's an issue that needs dealing with right away. You always have to re-evaluate what's the highest priority because it's constantly changing. You know, like with a specific task normally after checking the requirements with the appropriate people, I write the code, write any testing that's appropriate. And then I'll recruit another software developer either from my tribe or from another tribe. I often try to get developers from other tribes so that more people are aware of the work that's happening around.
Christian Espinoza:
And why is that? Sorry to stop you. What, why would you want that? Why would you want other members from other tribes to be aware of what's going on?
Siggy:
So that we don't end up with silos between tribes where there's like a set of say, if there's a project and I'm the only person that knows any finger about it, that's probably a bad thing because I could get hit by a bus. And that did actually happen once. So...
Christian Espinoza:
Oh really? My God. What, what happened there?
Siggy:
About eight years ago I was tour biking. In a rural area outside of Christchurch, coming from towards the Southern Alps in the middle of the night and a bus knocked me out from behind at 80 kilometers [per hour],
Christian Espinoza:
Oh my God!
Siggy:
I broke so many bones that they decided not to bother checking if I had broken anymore. And so it was like a month, I think, a month in hospital and then six months getting better, but everything's fine now I just have some metal in places.
Christian Espinoza:
I'm glad to hear. Everything's fine.
Siggy:
So you don't want developers to get hit by a bus so it's important to make sure other people know what you work on and how you fix it.
Christian Espinoza:
So then you, you involve other members from the other developers from other tribes with the work. Tell me then as you're writing the code, you mentioned also testing. Can you talk a little bit about the importance of testing or, or is it important and what, what does that entail?
Siggy:
It's is very important. Well, because, you know, if you put it out, depending on the system, it may affect a lot of may just affect people in the office or it may affect like customers and I've, I work with voice and I often work with infrastructure that support that stuff. So, you know, something we know will Affect customers that a lot of testing goes into it.
Siggy:
And yeah, when we have different steps of environment site, we have a testing environment, then we have staging environments and then we only then would we go to production and we have to pick an appropriate time, like depending on the system that time, maybe, say a Saturday when less people are likely to be using the thing that will be upgraded.
Christian Espinoza:
Right so it's got the least impact?
Siggy:
Yeah. The time when there's the least impact. And when we know people are available to make sure it's still working.
Christian Espinoza:
And so tell me what you know, what are some of the best practices that you've found when you're writing code, I mean, I know nothing about, you know, code or programming, but what, what would you say is, you know, some of what you try and achieve and strive for when you're writing code?
Siggy:
Most of all, normally trying to make, ensure things are clear. You can make something really fancy, but if you'd come back in a few weeks and you can't remember what it did, that's not very helpful to anybody. And as soon as going to be worse for someone else. So now they have to put in comments and if I'm not sure of the approach, I've taken to something I'll ask another develop, I'll give them the details of the problem. And then I'll ask them, how would you fix this? Do you think this is good? What would you change? Oh, and comments. Sorry.
Christian Espinoza:
So it feels like it's a very collaborative process.
Siggy:
Yeah. Once it gets complicated, it is, you know, if it's simple, I mean, not, not necessarily much point, but once certainly goes beyond something relatively basic then it is definitely important to have other people across it. Because what seems clear to me doesn't necessarily seem clear to someone else and the same with other people, what seems clear to them doesn't necessarily seem clear to me.
Christian Espinoza:
Exactly, and how easy is it to slip into something that can become very complicated?
Siggy:
Yeah, at the point where you have to stop and think about what you're doing [laughs]. A developer would understand. If you have more than two loops inside each other, then you probably need to start asking questions. Cause that may be the right thing to do, often there's ways around it that would make the code clearer. And that's where it's important or worse, three loops. And at that point, you really need to talk to another developer and say, 'am I doing this well?' Or 'is there a way you think we could make this simpler?' And there often is.
Christian Espinoza:
Right. So the more loops the more, potentially the more complicated it can be.
Siggy:
Yeah. For example, we have a thing called 'IF' statements, which is do this or that if you have many of those and your code, each one of those normally comes with an indent. So the code gets one more tab away from the side of the page. There's also a good measure. Once you've got a few levels deep in the actual visual look of the code, when you know it, it's probably something needs to change.
Christian Espinoza:
So from a complete layman uh, over here, that's me. What computer languages do you write in?
Siggy:
Too many and work often using PHP C-sharp and the frontend, we use JavaScript. We have some old projects that run node, different things. And my own time for example, I've never really used PHP in my own time. I like to work with C and C++ and embedded systems development and recently, I've been working on a website just for myself and that's been a C sharp and have a JavaScript front end.
Christian Espinoza:
And so what kind of things do you like to do when you're just working on your own personal projects?
Siggy:
It has to be something interesting that I actually want to do. I don't normally code just for the sake of coding, like it has to be interesting.
Christian Espinoza:
So what kind of, I mean, I, I know from your, your avatar you have a big purple pony. Tell me about that. What are you, I mean, your love of ponies, I guess?
Siggy:
I don't know, horses are my favorite animal. I've never basically never watched 'my little pony'.
Christian Espinoza:
No?
Siggy:
I can't deal with it
Christian Espinoza:
Wait, wait, wait. You have so many ponies, but you don't, you can't deal with watching 'my little pony'?
Siggy:
So it's like they have narratives where they're basically teaching children values and it's cringy. And I just can't deal with it. I mean, I've watched some, maybe I've watched one or two episodes, but often devolves into some message of how you should be nice to other people and you should, but it just gets cringey,
Christian Espinoza:
But you definitely love the animal, the pony, but yeah, but also there's a bit of fantasy there.
Siggy:
Cows are nice too.
Christian Espinoza:
Cows?
Siggy:
Yeah. Well, they're cute. But yeah, so I have a big collection of like horse figurines and like my little ponies, I was at one point I was buying them from Hong Kong because in Hong Kong they have more different types.
Christian Espinoza:
And which is your favorite type if you had to choose one?
Siggy:
I don't know. I've never actually thought about that. Well, I obviously liked the purple one. That's my picture.
Christian Espinoza:
So I want to talk about something else that you that you kind of have an interest in, and that seems to be fixing stuff. Maybe more specifically, I've seen you fix some coffee machines maybe tell me about at what, what sort of got you into that? Are you into the electronic side of it or the, you know?
Siggy:
Hmm. I guess I, I just find it interesting, like figuring out how things work and I enjoy taking, yeah. Basically taking things apart and fixing them is say, taking apart something like a coffee machine, if you just take it apart, you're never going to put it back together. I basically take like 30 or 40 photos of every single step. And you basically document where every single screw came from and label everything. And often inside those machines all the wires are the same color, even though if you put the wrong ones in the wrong place, it probably will blow up.
Christian Espinoza:
Have you, have you found that out the hard way?
Siggy:
Not with electricity or once I accidentally connected some steam hoses and an espresso machine and reverse, but obviously there's safe ways to test these things, which involve being, not near them and nothing bad happened when I turned the switch and what I didn't expect to happen, but it's specifically nothing happened, well then I obviously cut the power and from a safe distance, turns the valve the other way, which unlocked the system which basically made a massive roar of steam come out of the valve in a way that It would have probably certainly burnt someone if they were right next to it. But that is why you have to be careful working with espresso machines. Cause hot steam is dangerous
Christian Espinoza:
And just said, what, what made you decide to, you know, break one open and, and have a look under the hood.
Siggy:
I basically will take apart and fix anything.
Christian Espinoza:
Anything?
Siggy:
Anything interesting, I don't know. I don’t know, one day I was walking through a secondhand shop, and I saw an espresso machine for $10. I don't even really like coffee that much.
Christian Espinoza:
How do you find when you're working on these things, these machines or whatever it may be because you're, you're also dealing with software in your day-to-day job. How do you balance it to marry the two or does one inform the other?
Siggy:
Well, I guess some problem solving process probably informs itself, but specific day you're right. It takes a lot of time to rebuild an espresso machines safely while taking the appropriate measures, like there's a reason people throw them out and buy new machines. Because even if you paid someone at minimum wage like it's not cost effective to repair those machines at all. But basically it was over the last Christmas. So I had a few weeks off and my first one, I worked on it for about five days with little sleep, just, yeah. Basically just focusing on that the whole time. And then I went back and got another one and then another one. And by the time I came back to work, I had fixed five.
Christian Espinoza:
And what do you do with them after you fix them?
Siggy:
One of them I sold, but not so much sold. I definitely made didn't make money, but I did sell one to my scrum master. He got a very good deal. One 10th, the original price, So...
Christian Espinoza:
Wow. That is a good deal. These machines there, I think that the products that are coming out with the now they're so closed in once it stops working. You're right. It's more cost-effective to buy a whole new one than to fix it. So do you, this is a passion project. I guess you're more excited about pulling it apart, understanding it, problem solving and putting it back together. Then you are trying to turn a profit?
Siggy:
You wouldn't you and become rich fixing espresso machines.
Christian Espinoza:
You mentioned just before the, we started taping that you had, you had a drone that you found on the side of the road. Can you Tell me, can you tell me about that?
Siggy:
Yeah so I like to pick up things just off the side of a road when people put them like in a free bin, that includes things like coffee machines, toaster ovens, all sorts of stuff at the months ago, on my way, home from work, I found a drone, not a, not like an expensive one, well I think it was like $80 off AliExpress, so I got it, took it home, took it apart. Didn't find anything wrong with it. Put it back together, found out that it works, not very well. It was very hard to control. And after about 15 seconds, it just loses it. And one of its rotors goes full bore and it just cartwheels and smacks into the ground. So I obviously brought it to work, to fly around the office.
Christian Espinoza:
Well of course!
Siggy:
Yeah. You know, give people's hair a bit of a haircut when they're not expecting it.
Christian Espinoza:
And maybe freak some people out.
Siggy:
Basically just flying it around me office, when I'm not working, obviously, you know, when you're meant to be working, you're meant to be working, but there's always Friday afternoons.
Christian Espinoza:
Drone Fridays! What do you find that really works well? You know, working within the tribe?
Siggy:
Yeah. So, so my tribe is the voice tribe. So we support Voyager's voice infrastructure. The reason I like working in the tribe is my before tribes I would only ever work with developers really, but now with tribes every day, like, obviously I have my scrum master, but I work really closely with John who is the voice architect and the team of voice engineers. We have, I work closely with them. And I think in a way it is like, we are, the tribe is almost like a family.
Christian Espinoza:
That's nice.
Siggy:
We have in jokes, which won't be cited here, but
Christian Espinoza:
What stays in the tribe...?
Siggy:
Yeah, what Happens in the standup stays in the standup. No, but yeah, but no, I think it's good because, you know, often when you're trying to get someone outside of the tribe, depending, they might you to wait and say two weeks or longer to get something from them. But in the tribe, you know, everybody has the same objective. And so if you need help with something, unless it's critical, people can generally stop what they're doing and help you. And the same, like in a day, I'll be working on one of my tasks, one of the few different bits of code I'm working on. And, you know, like when you contacted me to ask me to do it interview, but you're not in the tribes. So, you know, I almost didn't respond. I'm just kidding.
Christian Espinoza:
I'm so glad you did though.
Siggy:
You know, they'll just send me a message and you know, like, 'hello', then I'll be like, 'what do you want?'
Christian Espinoza:
You just anticipate that question coming, don't you?
Siggy:
You get the 'Hello' and then You can see dot, dot, dot [ellipsis] on the end of it. But it's fun because, you know, people come to you when you have a problem and you help them with the problem. And when I have a problem, obviously I can send them hello, whatever. It's always nice when someone tells you what they want in the first sentence though, but like, to be fair, I don't actually get angry with people for just saying hello, because they all said hello, and I'll send them a 'what do you want?' GIF, and they will send me 'something' GIF. And then eventually, depending on how important it is that won't happen. But yeah, it is, it help and collaborate with other people and I can help them solve their problems quickly and can help me solve my problems quickly. And if we need to, we can pull multiple people into one meeting or have a video call
Christian Espinoza:
Given that sense of collaboration working within the tribe, with other members like engineers, that you know, outside of the software development team, how do you see the future of development given where we are today?
Siggy:
The future will definitely be interesting.
Siggy:
We are in the process of moving away from kind of like, I guess what you would call sort of like legacy or every company has legacy things. But more recently there's been more of a sort of like drawing a line in the sand and kind of like, this is the way things were the legacy systems. And then we have where we want to be, which is for example, changing technologies from PHP to the Microsoft world, C-sharp, dot net. That's something that's currently happening. I mean, it doesn't happen terribly fast because you can't just, you know, you still have to support your customers. So you can't just make that shift and drop everything because we don't have infinite people and we don't have infinite time. So like, you know, a lot of my time has been spent supporting the oldest systems and making sure that the customers get what they need now. And then there's still time that's spent on the stuff that we know they're going to want, but they may not know they want it yet. You know, there's, the future.
Siggy:
People want new things, but more of a new things they want and the things they have to work. So no, no one wants a new car. Well, okay. That's not a good thing. If your car is broken, you want a new car. But like, I guess maybe if someone's car is broken and they want a new car, they don't want a rocket ship. The rocket ship may be the future, but they don't care. They need their car fixed or fixing versus a new car. People may not want a new car. They want the car, they have to work. That sort of thing. And in the future, when we have something really good, but we've been working on doing that balancing, then that is really good for the customer because suddenly they have something that they didn't necessarily know it was coming, but might, how do you say, revolutionize how the way they do something. And then everyone's very happy
Christian Espinoza:
Just to wrap up here. If there was anyone out there listening who wanted to get into becoming a developer and start programming, themselves, what advice would you have for them?
Siggy:
Complicated question, because different people like different things. I would tell them that, you know, you can, you can start small. It doesn't like, you know, you don't have to start big or want to do like something massive. I think that the first code I ever wrote, I think I was probably 13 or 14 and I wrote it on a piece of paper because I didn't own a computer. And we found a book at a junk shop that told you how to code. And probably for the first year, I was just writing code on paper. It wasn't until I found out that I could run it on my dad's work computer, that I actually got to run my code and find out none of it worked, but so long, it's a learning process. But yeah, to make sure you're doing things that interest you and that are fun, because if it's not fun and not interesting, there's really no point in doing it. Starting small and working up
Christian Espinoza:
Siggy. Thank you so much. I've had a lot of fun with you today on the podcast, and I really appreciate you being here.
Siggy:
It was Nice talking to you.
Christian Espinoza:
That's it. For another episode in our agile series, the Growth podcast is a production from Voyager Internet. The show was produced, edited and mixed by me, transcription by Josh Yeats. Special. Thanks to my guest Siggy. If you enjoyed this episode and would like to hear more, follow us on your podcast, that we released new episodes weekly. If you want to see Siggy's work, just talk to our sales team for a demo of any of our voice products, Siggy has helped to develop some really cool apps that will probably leave you hooked. If you'd rather get an incredible deal on a refurbished coffee machine from Siggy, just drop us a line at podcasts at Voyager.nz Until next time. Peace.
