Whether you're new to React Native or a seasoned veteran, you'll love this episode! Today, Jamon and Robin talk about what a day in the life of a React Native developer looks like. They discuss tricks of the trade that they've learned along the way, and surprise surprise, Jamon somehow works in another tractor story.
Whether you're new to React Native or a seasoned veteran, you'll love this episode! Today, Jamon and Robin talk about what a day in the life of a React Native developer looks like. They discuss tricks of the trade that they've learned along the way, and surprise surprise, Jamon somehow works in another tractor story.
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Todd Werth:
It's another episode of React Native Radio podcast, brought to you by Vim. You can find it in my cold, dead hands. Episode 192, A Day in the Life of React Native Developer.
Jamon Holmgren:
Hey everyone, welcome to the React Native Radio podcast, where we explore React Native together. I'm your host, founder and CTO of Infinite Red, Jamon Holmgren. Coming to you live, well not really live, but recorded a couple weeks ago probably, if you're listening to this, from snowy Vancouver in southwest Washington state. I'm on the React Native core team and also a primary maintainer of MobX-State-Tree, and I'm joined today by my phenomenal co-host, Robin Heinze. Adhithi and Harris couldn't make it today. Robin is a senior software engineer located in Portland, Oregon. She works at Infinite Red. She specializes in React Native and podcasting, of course. What's up Robin, do you have any snow left over there in west of Portland, where you live?
Robin Heinze:
Yeah, we live sort of southwest Portland. We only have the piles of snow next to our driveway left from shoveling, but otherwise it's all gone. It's a balmy 45 degrees out. Probably the warmest in the country right now.
Jamon Holmgren:
Probably. Yeah, it turned pretty mild. We still have snow on the ground, but I got to tell you a tractor story, of course.
Robin Heinze:
Of course.
Jamon Holmgren:
Of course, it wouldn't be a React Native Radio without it. So we got our first load of snow, when was it, was it like a week ago? Something like that?
Robin Heinze:
Thursday, Friday.
Jamon Holmgren:
Yeah, and immediately I had to grab my tractor and go out there and clear the driveway because that's part of the reason I got it was to have it for stuff like that. So I was having lots of fun, I was pushing snow around. And I got the driveway clear and pushed stuff off to the side and whatnot. It did a pretty good job. And then I put the tractor away, got up the next morning and it was completely stocked in with snow again. So it was like I didn't do anything at all.
Robin Heinze:
You just have to look at it like a gift. They gave you the gift of getting to do it again, spending more time with your tractor.
Jamon Holmgren:
That's exactly what happened, yeah. I went out there and I pushed snow around again and I got it all cleared again. And then I managed to actually get my tractor stuck. So my tractor is four wheel drive, but it has turf tires, which are basically like lawnmower tires. Doesn't have the big knobby tires that a lot of tractors have. So I was messing around in the woods with it and I got it a little bit buried in dirt. I'll tell you what, my dad, who owned an excavation company, he always said, "A tractor, or a backhoe, you can't really get them stuck because they have too many ways to get out." And it's true, because all I had to do was stick the bucket down and push myself back a couple inches and keep doing that until I got myself out of the swamp.
Robin Heinze:
I've seen some crazy videos of the stuff that loaders and excavators and stuff can do by using their bucket as leverage.
Jamon Holmgren:
Yeah. Yeah.
Robin Heinze:
Pretty wild.
Jamon Holmgren:
It's like they have appendages. And backhoes especially, they have basically things on every side. Because they have the loader at the front, they have the backhoe out the back, and then they have these stabilizers on the side, and they're four wheel drive. They pretty much have everything.
Robin Heinze:
Invincible.
Jamon Holmgren:
Invincible. Just ask my dad. He's never gotten stuck in one.
Robin Heinze:
So he says.
Jamon Holmgren:
This episode is sponsored by Infinite Red. Infinite Red is a premier React Native design and development agency located fully remote in the USA and Canada. We have years of React Native experience, we host Chain React when it does happen, and we publish the React Native newsletter, we also obviously host this podcast and do lots of other cool things like open source with Ignite, Reactotron, you name it. We are the best choice for your next React Native app, hit us up, hello@infinite.red, or just email me directly, jamon@infinite.red. You can learn more on our website, infinite.red/reactnative. Don't forget to mention that you heard about us through the React Native Radio podcast. And also we are hiring, so go to our fancy new form, careers.infinite.red. We are hiring senior level React Native engineers who are located in the USA or Canada at this time.
Jamon Holmgren:
Now that's very topical actually, for the topic that we have, we're going to be describing what a day in the life of a React Native engineer is. And so this is going to be, I think, kind of fun to go through if you're someone who is new to React Native and just exploring it. I'll probably send this episode to people, email the link to people, and say, "Hey, listen to this." If they're interested in knowing what it's like. Also, if you're considering switching from maybe another type of business toward consulting, we're going to be talking about it from a consulting standpoint, obviously, since that's what both of us do. If you're looking at switching technologies, what kind of challenges do you run into doing React Native. So we're going to talk about a day in the life of a React Native developer.
Robin Heinze:
Specifically one who works at Infinite Red, but I imagine it'll apply pretty generally.
Jamon Holmgren:
Yeah, that's the hope. Obviously we're speaking from our own perspective, we can't really say what it's like to work at Facebook as a React Native engineer, but we can talk about our perspective, for sure. With that in mind, obviously we're React Native consultancy so we don't make our own React Native apps, we help other companies build theirs. So everybody has their own process. If you're working at a company, they're probably going to be using something like Jira, or Trello, or Asana. I don't know, what are some other ones, Robin?
Robin Heinze:
Basecamp?
Jamon Holmgren:
Basecamp, yeah, I don't know. We've used quite a few in the past. But let's talk about how we approach a new feature and what the day might look like. And I'm going to be asking you a lot of questions, Robin, if that's okay, because my day looks a little different as CTO at Infinite Red.
Robin Heinze:
Yes, it definitely does. Yeah, that sounds good.
Jamon Holmgren:
Let's start off with just some basics. Like what computer do you use?
Robin Heinze:
I have a pretty much fully-loaded Macbook Pro 2019 16-inch.
Jamon Holmgren:
Yeah, that's what I have as well. It's a great computer. It's not an M1, would've been nice to know that was coming.
Robin Heinze:
It's not an M1. It has its little quirks. It's a huge step up from my 2016 Macbook Pro, which is what I upgraded from, and the keyboard is much better.
Jamon Holmgren:
Yeah, totally. Do you have other devices around you? What else do you have?
Robin Heinze:
I do have a lot of devices. I wouldn't say that I test with them on a daily basis, but I usually rely pretty heavily on the simulator and emulator, but I do have my regular iPhone, is what I use for iOS testing a lot. I also have a slightly older iPhone, and iPhone 6 to test older, slower phones. I have a Pixel 2 for testing Android, I have some Samsung devices, I have a couple tablets.
Jamon Holmgren:
Yep.
Robin Heinze:
Mostly for breaking out for when there's specific bugs or when I'm sort of doing overall testing passes to make sure everything looks good on real devices. But yeah, day to day I mostly spend my time in the simulator and emulator.
Jamon Holmgren:
This is sort of a challenge of being a remote company, and I know people are running into this now. But we can't just have a big bank of devices, kind of a common communal pool of devices that you can just grab and say, "Hey, I need a Moto G or something."
Robin Heinze:
That's true, that is true. My previous company, it was an office, we had basically a server rack, like full size server rack, full of every flavor of device, and you could go check them out and do your testing and put them back. And it was a really slick system. So doing this remotely has been a bit of a challenge. A lot of duplication. Everyone kind of has to have their own set.
Jamon Holmgren:
Yeah, which is a positive and a negative at the same time. Positive because obviously it's all your stuff and you can kind of keep it how you want it. Negative because, well, everybody has to have duplication all over.
Robin Heinze:
I do take advantage of finding refurbished devices on Amazon. Most of my devices are refurbished or open box.
Jamon Holmgren:
That honestly is better anyway, because most people aren't using things on brand new devices, so it's better to have stuff that's a few years old. I have a bunch of devices as well, and when I broke them out and I was putting them in my office, my nine year old came up to me, and her 12 year old sister just got a phone, because sometimes she'll babysit or whatever. And she picks up one of the iPhones, she's like, "Dad, here's an iPhone." I'm like, "Yeah." She's like, "Could I have it?" I'm like, "You're nine, you don't need a phone. You don't need to start that addiction right now. It's bad enough."
Robin Heinze:
Plenty of time in your life for that later.
Jamon Holmgren:
Plenty of time. Yeah, go be a kid for a while. And enjoy it. But yeah, don't get into that. Dad has plenty of phones laying around, but that's not what they're for.
Robin Heinze:
Yup.
Jamon Holmgren:
So beyond hardware, what just basic tools do you use? Are you a Vim person, do you use VS Code, what do you use?
Robin Heinze:
I use VS Code. I was a Vim person in a former life, and at one point I just decided that the value wasn't worth the downsides.
Jamon Holmgren:
So you quit Vim?
Robin Heinze:
I quit Vim.
Jamon Holmgren:
I didn't even think that was possible.
Robin Heinze:
Yes, I quit Vim. Partly because I got into the React Native world and the Java Script world, and it was much more common for people to use IDEs and specifically VS Code was really common. And I found that if I was using Vim, it was really difficult if I needed to pair with someone or show someone something. Like they would have trouble figuring out what was going on and how to do things on my machine.
Jamon Holmgren:
That's true.
Robin Heinze:
I wanted more in common with the community and my colleagues. And I finally admitted that I really liked having a traditional user interface.
Jamon Holmgren:
Do you Vim keybindings?
Robin Heinze:
No, not at all. I think I did for maybe a week.
Jamon Holmgren:
Yeah.
Robin Heinze:
No. It's just easier just to use the VS Code shortcuts.
Jamon Holmgren:
Yeah, I'm more of a traditional. I started with Dreamweaver but then I went to Sublime Text 2, for a little while I used Atom. And for a while I actually had two computers and one computer had Atom, and the other had VS Code, I think. And so I was switching between the two. But Atom was just so slow, I don't know what it was about it. It was just so slow, hard to keep up with. So VS Code, something about the way that it's built, it just seems to perform so much better.
Robin Heinze:
Yeah it does, it really does. It kind of rules the space now.
Jamon Holmgren:
So I know you use other software and stuff but we probably won't dig into that right now. I want to talk more about what a typical day looks like. You're working on a project, you're probably working with what, one or two other people most likely.
Robin Heinze:
Yeah.
Jamon Holmgren:
Yep?
Robin Heinze:
Yeah.
Jamon Holmgren:
You might be in the middle of a project. You're in the middle of a project and there's a new feature that you need to now take on. You've just shipped something, and now you're moving onto the next thing. What happens first?
Robin Heinze:
Well I'd say first, if I'm sort of warming up into the day, roll in, you check slack, somebody posted a PR at the end of the day yesterday.
Jamon Holmgren:
A pull request?
Robin Heinze:
A pull request. So I'll go look at that, give some feedback, maybe some examples of stuff I might say, maybe a colleague is using a utility function in a couple different places and I suggest moving it into a shared hook. I noticed they were using a timestamp in some mock data that was in seconds instead of milliseconds.
Jamon Holmgren:
That'll ruin your day.
Robin Heinze:
That'll ruin your day. That kind of stuff.
Jamon Holmgren:
Are these real examples?
Robin Heinze:
These are real examples, yeah.
Jamon Holmgren:
Oh, okay. Yeah.
Robin Heinze:
Yeah. I'll notice things like pulling data from a navigation param and not persisting it in some other more permanent way.
Jamon Holmgren:
Mm-hmm.
Robin Heinze:
I'll maybe suggest storing it in MobX-State-Tree so that it'll persist between refreshes. That kind of thing. Typos.
Jamon Holmgren:
So you're scanning down. Do you just start at the top and just review straight from the top all the way down, like a diff. I guess for people maybe that are new to programming, pull request you'll actually see a diff, which is like we modified this line, we deleted this line, we added this line, we added this file. And you can kind of see it all the way down. So do you just kind of start at the top and work your way down? Do you have a certain process around that?
Robin Heinze:
Yeah, I'll usually go by the file hierarchy and I'll just go file by file.
Jamon Holmgren:
Mm-hmm..
Robin Heinze:
I'll usually skip over files that just seem like they have a lot of white space changes or packaged like yarn.lock or snapshot differences. Yeah, I'll usually go file by file and just see what jumps out at me.
Jamon Holmgren:
Yup.
Robin Heinze:
Sometimes if it's a particularly complex feature, I'll actually pull the branch down and run it and check the features. If it's a more simple feature, I'll usually rely on the screenshots and the videos or GIFs that were included with the PR. I always recommend including, if it's a visual feature, or some kind of functionality that you could see, including screenshots or GIFs or a video if it's really long.
Jamon Holmgren:
Yeah, totally. Having those types of things on a pull request are really helpful to people that are reviewing. Another thing I like to do, which I don't know if everybody likes doing this, but I like to actually go down and comment on my own PR and say, "Hey, this is why I did this, this is why I did that." Just give some context around the changes. Sometimes that's better in code comments actually in the code, but not always. Sometimes it's like, "I changed this from this." We don't need that to live in there forever, it just needs to be in the PR.
Robin Heinze:
Yeah. I'll do that as well. Sometimes I'll have to make a decision between putting it in the PR description where it's more sort of historical and permanent, versus putting it in line in the code. Because sometimes if it's in line in the code and there's changes, those comments can sometimes disappear if the code gets outdated. So if it's something that I want as a permanent record, I'll usually put it in the PR description or in the commit message, or like you said, in comment in the code itself.
Jamon Holmgren:
It's kind of interesting just in a little aside, Git really isn't everything about the history of a code base. GitHub is, or Bitbucket or whatever you're using. Those two things working together are the full history. Because Git itself holds a history of changes, but it doesn't hold a history of conversations and explanations and whatnot. That's kind of an interesting piece of this.
Robin Heinze:
Now you have me curious. If you rebase your code and rewrite Git history, does GitHub or Bitbucket have any kind of memory or log of what it was before you rebased?
Jamon Holmgren:
You know, I haven't tested this. I feel like they do. Like they hang on to more stuff than you would think, but I could be wrong about that. I'd have to test that.
Robin Heinze:
That's a different can of worms there, but.
Jamon Holmgren:
So the big thing here, though, is you're reviewing a teammate's code.
Robin Heinze:
Right.
Jamon Holmgren:
And you're looking through it, and you have context around it because you've probably seen this code before, and you've maybe even worked on it. And then after you're done kind of providing your feedback, you then, what do you do next?
Robin Heinze:
If it's significant enough feedback that I want them to make changes, I'll indicate that. If they're not significant enough, they're just suggestions, then I'll go ahead and approve it and move on.
Jamon Holmgren:
And they can choose to...
Robin Heinze:
They can either choose to address it and make changes or merge it and move on with their lives, yeah. So yeah.
Jamon Holmgren:
Yeah, yeah that's very cool. Now you might have a pull request that's out there as well. Is this also gathering comments and whatnot?
Robin Heinze:
Yeah, usually at the beginning of the day, my ideal workflow cadence is getting finished with a feature at the end of the day and opening a PR and closing my computer and being on my merry way. It doesn't happen, actually, all that often.
Jamon Holmgren:
I was going to say, is that every single day you do that?
Robin Heinze:
Not every single day, definitely. I love it when it works out that way.
Jamon Holmgren:
Mm-hmm.
Robin Heinze:
So if I've had a PR open from the previous day, I'll go check it and there's usually comments and I'll maybe push up a commit or two, fixing small things. If it's good after that, I'll merge it or have our QA team test it and merge it, depends on what your particular team workflow is.
Jamon Holmgren:
I have to say, my particular workflow, like if I was working with you everyday committing code, you would notice this. And you probably have noticed this anyway. I have a hard time encapsulating things into small bite-sized chunks. I love big, sprawling changes. That's how I love to work.
Robin Heinze:
Jamon lives for, what is it? Git commit dash A, or something. Where you just add everything.
Jamon Holmgren:
Exactly.
Robin Heinze:
Unstaged in your workspace. You don't even look at what you're adding. You're just like, "Add everything."
Jamon Holmgren:
It's all good. It's all getting out there, it's shipping. Yeah, I have a command GAC, git, add, and commit.
Robin Heinze:
Right. That's what it is.
Jamon Holmgren:
I should do GACD, it should be git, add, commit, deploy. And then Y for yolo. I don't know.
Robin Heinze:
Which is so different from what I do, where I use git add dash P every single time, where it steps me through every single change that I made so I can confirm that yes I want to add this, yes I want to add this.
Jamon Holmgren:
I definitely don't recommend my way of working for working within a team, and it's something that when I do work within a team, I have to modulate that. I have to really, really work hard to... Honestly, I'm working on an internal project right now, and at first we were working together on stuff, and it got to be where it was kind of just me because everybody got busy. I feel myself moving back into those old habits. There's literally a Jamon branch that is just accruing stuff, and I have a PR out called Tons of Updates.
Robin Heinze:
Oh, I need to review that. That reminds me.
Jamon Holmgren:
Good luck. 14 commits.
Robin Heinze:
Approve, I think?
Jamon Holmgren:
I did put comments on things, but there have been five commits on it since. I don't know. I mean, I don't even know what to say except for I'm sorry. And things are getting done, I'll tell you that. Things are getting done. It is taking shape. And sometimes, sorry to take this whole aside here, but sometimes I feel like this internal project, we just need sort of the basic thing hacked out with an ax here. And after it's up, maybe we can start using more fine grain tools to shape it. That's kind of where I'm at right now. You're quite different in that, and I definitely would recommend people follow Robin's example here.
Robin Heinze:
Yeah, Jamon's a really great manager.
Jamon Holmgren:
Wow, yes. I'll take that as a positive. It didn't sound like one. Anyway, so you might have a PR out there, and then you'll address comments that have come in on your own pull request as well.
Robin Heinze:
Yeah, this is like me doing my paperwork for the morning.
Jamon Holmgren:
Mm-hmm, yeah. And now it's time to move into the new feature, where are you at there?
Robin Heinze:
Right, so, and this is assuming I'm sort of in between features. And so I'll go to our sprint backlog, which is the features that we've chosen for this particular sprint. And if you're not familiar with Agile, sprint is a chunk of time, usually one or two weeks, where you pick up a predefined collection of work that you're committing to complete within the sprint. And usually, depending on the team, you'll assign things to team members at the beginning, and sort of so everyone kind of knows what they're going to work on. Some teams do that, some teams, you just have a backlog for the team, for the sprint, and people pick up whatever's available when they have time. We generally tend to assign things out ahead of time so that maybe there's areas that particular people are more familiar with, or have been working on and have context for.
Robin Heinze:
So I'll usually go and pick up the next thing that's assigned to me. For the sake of this day in the life example, this is going to be a new component, a new visual component in the app. It's a component that is basically the backside of a card and it has a bunch of text in various sections. Like there's a title section, and a description, and a subtitle and then sort of a table with value pairs, like label and value pairs. So it's a pretty straightforward visual component. So I'll pick up the card, if it's in Jira, I'll do the workflow changes. Like I'll say, "Oh, it's in progress." So I'm like officially starting work on it. I'll do some of the Git busy work. Make a branch, make sure my Git workspace is clean.
Jamon Holmgren:
Mm-hmm.
Robin Heinze:
That I've pulled in the latest master and everything's up to date. And I'll usually make sure the app is running on my clean branch before I've made any changes so that I know I'm sort of starting in a good place.
Jamon Holmgren:
That sounds like, to me, I'm hearing pain that has been caused by not doing that in the past.
Robin Heinze:
Yeah.
Jamon Holmgren:
Because I've been in situations where I started working on something and then I'm like, "Hey, this old bug is popping up." Then I'm like, "Oh, I didn't pull master."
Robin Heinze:
Yeah. And then if you've already made work, then you have to stash it.
Jamon Holmgren:
Stash it.
Robin Heinze:
And maybe there's conflicts now when you try and merge.
Jamon Holmgren:
Oh, conflicts.
Robin Heinze:
Making sure that you're working with a clean slate and that everything's good to go. And it also helps if you sort of have peace of mind that you know kind of where things started. So if issues arise while you're working, you kind of have a sense whether you created them or whether they existed before.
Jamon Holmgren:
Right. That's really important. Knowing kind of where you're starting. You got to have kind of an anchor point, like, "Where are we starting here?" Yeah. Totally makes sense to me. So now you're moving on into the component, you want to create the first component, you just create the file, start typing, what do you do?
Robin Heinze:
Most of the time we're working on projects that are Ignite projects.
Jamon Holmgren:
Ignite, of course, being our project boilerplate generator that we... It's an open source project, you can go check it out. We'll put it in the show notes.
Robin Heinze:
Now, Ignite Flame does not have generators anymore, is that right?
Jamon Holmgren:
It does have generators, actually. It has really cool ones.
Robin Heinze:
Oh that's right, they're more configurable.
Jamon Holmgren:
Yeah, they're more configurable, but they're also less flexible.
Robin Heinze:
Almost all of our projects are Ignite projects, so when I start a new component, I use Ignite generators. I just run Ignite, generate, component, with the name that I'm choosing for my component, and it gives me a generic component file, story file.
Jamon Holmgren:
In a folder, yeah.
Robin Heinze:
In a folder. Ready to go.
Jamon Holmgren:
Mm-hmm.
Robin Heinze:
At this point, what I usually do is get the app running in storybook mode, and just have it running the generic generated component.
Jamon Holmgren:
Okay, talk about storybook for a second.
Robin Heinze:
Storybook, yeah, that's a good point. So storybook is a library that lets you, it sort of serves multiple purposes. It lets you build components sort of in a vacuum, and then also gives you a way to sort of create a library of all your components. So you're displaying, "Here's my button, here's my card." All of your various, quote unquote, components. Lets you sort of display them in a list. And I use it when I'm developing components so that the other context of my app layout and everything is irrelevant. What goes into the component and what does it look like, sort of in a vacuum. But that involves running the app in storybook mode, so you'll see the storybook interface, which has sort of a navigator so you can select between your various components, and then it has a main screen which lets you display your component in various states. So you can do, "Oh, here's my component if this value is passed in props, and here it is if this other value is passed in props." Or you can do various different states that your component can exist in.
Jamon Holmgren:
Right. That's kind of the big value, right? Because a lot of times when you build a component, it's like, "Oh, hey, it works really well for this one state." But then what happens when there's no data? Or what happens when you're in a loading state, or if there's an error state. You need to have all those different states, and so storybook kind of gives you tools to, and actually almost like pushes you to provide those states. It's kind of almost nudging you in that direction, right?
Robin Heinze:
Right, so I'll usually have a use case for just normal happy path expected values, and then I'll have something like, "Oh a really long title, or a missing title." Or, you know, the various things that might happen if you're missing data or if your data is various different shapes, or whatever can happen to it.
Jamon Holmgren:
I think the idea of breaking things down into sub components is a really key part of being an effective, well a developer of any sort, to be honest. You could be doing this as a desktop app developer, or whatever. But being able to break things down into their sub components and really think about them in terms of atomic units is really big. But certainly in React Native that's big, because everything is a component. Every view is a component, everything is, even screens, full screens, are components. And so you're composing from different elements and pieces and configuring those things in order to make them work. And obviously, you're also styling them. We had a previous episode about styling, so that's part of this as well. Do you do the styling early, or do you kind of do that toward the end after you rough it in?
Robin Heinze:
I generally do. I lay things out and then I style aftwards. And styling is a pretty broad term, so like, layout includes things like padding and margins and things like that, which is included in style, but I tend to do it first. Anyway, yeah. Storybook is really great. It helps with a lot of different parts of component development. It helps keep components dumb, for lack of a better word.
Jamon Holmgren:
Yeah.
Robin Heinze:
It helps keep you from making them know too much about the greater context, so that you have to pass in everything that it's going to need to know as a prop.
Jamon Holmgren:
Yeah.
Robin Heinze:
So yeah, once I get the app running in storybook mode with my sort of default generated component, and then usually what I'll do next is define the props for the component. Figure out what data it's going to need to be passed in.
Jamon Holmgren:
Yeah.
Robin Heinze:
And get that defined. I'll make the TypSecript, type for that in the component itself.
Jamon Holmgren:
I was going to say, TypeScript comes into play here because that is obviously very helpful for interfaces, and what you're talking about with props is an interface.
Robin Heinze:
Mm-hmm.. And TypeScript is obviously what we use as sort of our replacement for other systems like Flow or PropTypes.
Jamon Holmgren:
Right.
Robin Heinze:
But yeah, we use TypeScript so that we know exactly what types our props will be. Also, I'll define that in the component itself, and then in the story, I will create some mock data, and just sort of data that's going to look like what the actual data that'll be passed into this component will look like.
Jamon Holmgren:
Yup.
Robin Heinze:
And then I'll modify the story so it's passing in all of those things as props, and then I'll re-render. And at this point I'll start putting in sort of rough layout hierarchy, just sort of views with the data from props just sort of put on the screen without any fanciness, any styling. And just to make sure it all renders and the data's coming through the way I expect.
Jamon Holmgren:
At what point do you start finding value in adding tests? Obviously there's just snapshot tests that we've used in the past, or story shots, I think. Storybook has a feature called story shots. So are those helpful at this point, or do they kind of not really add a lot of value there?
Robin Heinze:
So for building components like this, the snapshot tests don't really come into play while you're building it. The value of the snapshots comes in when you're already done and you're trying to make sure down the line when you're building something else, that you're not breaking what you've already built. Those tests don't really come into play when I'm building components like this. I'll bring in sort of TDD, test driven development strategies more when I'm building models or API functions, or utility files, or services, or other things that aren't really UI components.
Jamon Holmgren:
And obviously later you also have integration and end tests with Detox, or APPIUM, along those lines. Those things will come in. But that's more after the integration's happened.
Robin Heinze:
Mm-hmm.
Jamon Holmgren:
Yeah.
Robin Heinze:
Like I said, I'll create sort of a rough hierarchy of views, I'll usually put in empty styles at this point. Like I kind of use styles as labels for things, in a way. To sort of get my bearings about where I am and what the component looks like in my mental model of it. So I'll put empty styles of things, like title wrapper, or description wrapper. Views that'll be around the text components that will be the content. And I'll leave them empty for now, but just sort of so that it's not just a bunch of generic views. It's like, "Okay, I'm defining. Okay, this is going to be the title, and this is going to be the description." And sort of laying things out.
Jamon Holmgren:
Yeah.
Robin Heinze:
And then once I have content and I'm sure that the content is rendering on the screen, then I'll start adding padding and margins and sort of pushing things around and figuring out what needs flex, what alignment to give things, what justification to give things. And I sort of just keep tweaking until it looks right.
Jamon Holmgren:
What design tools are you using at this point to kind of... We use a variety of different design tools. If our designers are working, you're probably working in Sketch. You probably have Invision, as well, as another tool. What design tools do you tend to be in and how are you using these? Are you measuring things and finding pixel numbers and font sizes and stuff like that?
Robin Heinze:
That's a really good question. Yeah, so if our designers have designed it, or other designers, a lot of them also use the same tools. But usually there'll be a Sketch file or an Invision mockup, and both of those will give the ability to measure and see what spacing is exactly. I also use a tool called X-Scope. I don't know if you're familiar with it.
Jamon Holmgren:
I actually am not.
Robin Heinze:
It's something that one of our old developers at IR turned me on to.
Jamon Holmgren:
Okay.
Robin Heinze:
It's basically a set of rulers and other measuring tools for your machine. So you can measure things on your screen compared to other things. So I'll measure and make sure things are straight up and down and in a line. Like, aligned with each other. And then comparing them to the, like I'll put the mocks in the simulator side by side and make sure they're the same scale, and then use rulers to sort of like make sure things are the same alignment and they look right.
Jamon Holmgren:
I am going to put X-Scope in the show notes, and then I'm going to check it out later, that looks really cool.
Robin Heinze:
Yeah, so I'll usually have the designs up and right next to my simulator while I work.
Jamon Holmgren:
Yeah. By the way, do you have multiple monitors or one?
Robin Heinze:
I have one monitor but I also have my laptop screen as a second monitor.
Jamon Holmgren:
Oh I see. Okay.
Robin Heinze:
Yeah. So I have a big monitor and that's usually where I'll have VS Code, and sometimes I'll have the simulator on top of VS Code.
Jamon Holmgren:
Mm-hmm, yeah.
Robin Heinze:
And Reactotron. So I'll either be in simulator and Reactotron together mode, or I'll be in editor mode. And then on my laptop screen is usually where I have Slack and Trello and sort of the other more administrative tools.
Jamon Holmgren:
Yeah, I kind of do the same. I have two monitors. Well, I have one monitor and my laptop. But I use my, actually, use my laptop display as my primary monitor even though it's smaller. And I use the other one. But I don't know, things move around a lot on my screen, it's just how I want to work. A lot of times I use the Mac OS spaces as individual projects, because I'm often working on different projects. And so one space might have Terminal and VS Code and a Chrome instance, the next space might have Terminal and VS Code and an iOS simulator.
Robin Heinze:
Oh.
Jamon Holmgren:
You know, so I'm jumping between spaces and then they're all there. I don't go full screen, I overlap a little bit so that I can like, click over to the other view and it pops on top pretty easily. But I've noticed one of our developers, Yulian, he has one whole space is a full screen VS Code, and then he's got a whole other space for something else, and he's switching spaces all the time in order to do that.
Robin Heinze:
I never have gotten into Mac OS spaces, I don't know why they just don't work with my brain.
Jamon Holmgren:
Mm-hmm, yeah.
Robin Heinze:
It's more easy for me to keep track of sort of the layers on my one space, and I utilize Alt-Tab a lot.
Jamon Holmgren:
Oh, yeah. Okay. Yeah, because of that I guess I don't really use Alt-Tab very often because I'm swiping or I'm clicking on a partially. A lot of times I'll have the terminal on the left side, and it's peeking out a little bit, so I can see output. But it's not showing the whole terminal, and so when I want to jump over there, I can see the first line of something. I'll click on it and it pops up, and then I go to the right and click on VS Code and I'm back to that. And then on the far right, I've got the simulator. Everybody has different ways of laying out their workspace, but yeah. That's interesting.
Robin Heinze:
I think I also stopped using spaces because I switched away from the magic mouse to a regular scroll wheel mouse. So I can't use any of the swipe gestures anymore. Which kind of limits what I can do with certain features.
Jamon Holmgren:
I use a track pad, like a separate track pad. Is it the magic track pad?
Robin Heinze:
I should do that. I should do what Ken used to do and have a track pad on one side and a mouse on the other side.
Jamon Holmgren:
Your brother Ken, yes, he uses the track pad on the left and the mouse on the right and that allows him to kind of get the best of both worlds.
Robin Heinze:
Big brain time.
Jamon Holmgren:
I did have a vertical anchor mouse for a while and I would find myself reaching up and using the track pad on my laptop. So I would switch between them that way, reaching up on the stand where my laptop is. Anyway, yeah. Developer micro, what is it, micro...
Robin Heinze:
Ergonomics?
Jamon Holmgren:
Ergonomics, yeah, little things, yeah. But yeah, so you have it kind of wired up with fake data and stuff. Now you really need to integrate it into your actual app so that it shows up. How do you do that?
Robin Heinze:
So once I'm pretty satisfied with how it looks in Storybook, I'll turn off storybook mode and I'll go into wherever this component is actually going to be rendered in my app layout, is usually on a screen, or maybe it's inside of a parent component. I'll go to wherever it's being rendered and I'll add it there, and I'll gather the actual data that's going to go into it, which is usually managed by... If it's going straight into a screen, like the screen is managing it from MobX-State-Tree, like calling an API to get it. I'm at this point assuming that that's already happening. That I've already set that up. I'll render it and pass in the real data, and then I'll load the screen up and mess with layouts, however they need to change in order to get it to look right. It may mean adding some kind of wrapper around it, or some padding to the parent component, or whatever.
Jamon Holmgren:
Do you find yourself going back to Storybook, and being like, "I didn't actually get that right."
Robin Heinze:
Sometimes, sometimes. Usually, there's some things that you shouldn't do within a component itself, that a parent should be responsible for managing.
Jamon Holmgren:
Hmm, okay.
Robin Heinze:
Like if you ever find yourself putting a line self on your component, or putting margins on the root wrapper of your component.
Jamon Holmgren:
Mm-hmm.
Robin Heinze:
That's when you should take a step back, because your component should manage what's inside of it. But anything about your component about where it is in space, or where it's rendering in the context of its parent should be determined by the parent.
Jamon Holmgren:
Got you. Stay in your lane.
Robin Heinze:
Exactly, stay in your lane. Because you want to make sure that your component manages its own business, and if you're using it multiple places, that it's not doing something unexpected. You want to be able to control where it lives in space from the outside, and not from the inside.
Jamon Holmgren:
That makes sense to me. So then it probably starts getting kind of exciting at that point because you actually are seeing it in context, it's like the screen that had a blank spot before now has something functioning there. It's a button, or it's a list view, or it's an image, or really anything. Any sort of component. It's now coming to life. That's pretty cool.
Robin Heinze:
Yeah, that's one of the really satisfying parts of UI development, and one of the reasons I've really enjoyed being in React Native after having been a platform server back end developer for a long time. I find it really satisfying to see something you just wrote come to life visually.
Jamon Holmgren:
Yeah.
Robin Heinze:
Yeah, it's really cool. And then this is probably the point where if I haven't been testing on both devices, or both platforms, which you probably should be testing on both platforms. But if I haven't been, I'll pull up usually Android, because iOS is my default, generally.
Jamon Holmgren:
Yeah.
Robin Heinze:
I don't know why, I think that's true for a lot of people, I'm not sure why.
Jamon Holmgren:
The emulator can be kind of a resource hog and that, I think, slows a lot of people down. I think if the emulator worked better than the iOS simulator, it would be reversed.
Robin Heinze:
The iOS simulator is very easy to use and it's very smooth. So I'll pop open Android, make sure things still work. For things like this, which are pretty straightforward, UI elements, it's pretty rare for Android to do something different.
Jamon Holmgren:
Lately, you've been having to do this on web, too. So you actually have to pull it open in web, as well.
Robin Heinze:
That's true, for this particular project there would be a web.
Jamon Holmgren:
A third platform.
Robin Heinze:
Yeah, a third platform to check.
Jamon Holmgren:
And then you could add many different TV platforms, you could add desktop, you could add Windows, you could add Mac OS, Linx, I guess. You could add all kinds of other platforms if you really wanted to, and then you'd be testing it in all those.
Robin Heinze:
So depending on how many platforms you're developing for, make sure to account for all of the time that you're going to spend testing on different platforms when you estimate how long a feature's going to take.
Jamon Holmgren:
Yes.
Robin Heinze:
It could be at least half of your time spent.
Jamon Holmgren:
Yes. Not only that, but within a particular platform, you might have different screen sizes.
Robin Heinze:
Yes, exactly. So in addition to pulling open Android, I'll maybe pull open an iPhone SE.
Jamon Holmgren:
Mm-hmm, the small one.
Robin Heinze:
Yeah, that's the smallest. I think it's discontinued now, what is it now? It's the iPhone 12.
Jamon Holmgren:
I don't know.
Robin Heinze:
I'm not sure, I think the SE is discontinued now, but the simulators are still there. But really small screens, or I'll pull open an 11 plus max or something. The really, really big one.
Jamon Holmgren:
Max plus extra.
Robin Heinze:
Yeah. The really huge ones.
Jamon Holmgren:
They just keep adding modifiers to it.
Robin Heinze:
And make sure that I've used Flexbox in the appropriate way so that things expand and shrink appropriately. Usually when I bring out the small screens is when I realize I haven't put text wrapping on, or I haven't constrained widths properly, and so I'll go in and fix those to make sure that things wrap and shrink and truncate the way they should.
Jamon Holmgren:
This will also come into play when you're testing with large font sizes for accessibility, things like that. You really need to be thinking about all these things when you're building. That can be a fair amount of work, but it's all worthwhile to go through all this and make sure that it's working. I think this is actually where a lot of maybe more new to the industry developers run into problems, is they finally get it working on the device that they're testing.
Jamon Holmgren:
They're so relieved that they finally got it going that they just push it up and are like, "Okay, hey it's done." And then someone tests it on a slightly different size of screen, or they check it on Android, and it breaks, and they have to send it back and say, "Hey, this isn't done." And so knowing that, "Hey, okay, I got this working there, but now I need to go check all these other dusty corners and different states and whatnot." That's actually, I think the mark of a senior engineer is one that won't rest until they know that it works in all those different places, and then they will feel like, "Okay, that's ready to go."
Robin Heinze:
Even seniors, I'll say, this is usually the point where if there's some kind of really stressful deadline, or you're being rushed by the powers that be, or people are getting impatient. This is generally when even seniors will fall into, "Okay, well it's good enough."
Jamon Holmgren:
Yeah.
Robin Heinze:
Call it done. And not go through the due diligence of testing all the edge cases.
Jamon Holmgren:
You can, as a developer, you can make a decision, "This is good enough, we're going to move on." If it's done intentionally with good communication. So you can say, "I did not test this on Android, I did not test this on small screens, I did not do these things because you all told me I need to have this done today."
Robin Heinze:
Exactly. You can have that conversation with your stakeholders, and if they're aware of the trade offs, you could say, "Okay, it's good enough."
Jamon Holmgren:
Here's what you're getting for the time that you're willing to invest, and I'm more than willing to go back and do those things later if and when they fall over. But you know, I mean, there have been situations where we're building apps for literally one device, one type of device. It's a situation maybe where the app will be used in a trade show, and every booth that is going to be using it is going to be using an Apple iPad Air of a certain vintage. And we know what it's going to go for, there's no point in testing it on an Android device or anything like that, and that can be fine. That's a good trade off to make, as long as it's not intentionally. It's when it's like, "Hey, everything is working." But then you didn't really think of the other things, or you just ignored those things. That can get everybody into trouble. I mean honestly, as people are listening to this, they're probably hearing a lot of communication happening as well. It's not just about writing code.
Robin Heinze:
Mm-hmm, yeah. That's very true.
Jamon Holmgren:
So you're at a point where it's working well on all these different devices, different screen sizes, things like that. Is it time to ship now? What do you do now?
Robin Heinze:
Usually, I'll be pretty satisfied at this point if it's working on a lot of devices. So I'll go ahead and while I have all my devices open, I'll go ahead and take screenshots of various different states, maybe reopen Storybook and take screenshots of my various use cases in Storybook, because I think that's a pretty good demo of what the component can do under various constraints. And then I'll commit everything using Git add dash P.
Jamon Holmgren:
Mm-hmm.
Robin Heinze:
Which Jamon doesn't use. Making sure that I haven't added...
Jamon Holmgren:
Git YOLO.
Robin Heinze:
Yeah, which lets me go through and make sure I haven't left any console logs in.
Jamon Holmgren:
By the way, I do use Git add dash P, by the way. And I'll often also, when I push up a PR, I always go through the diff and look at it and make sure nothing got in that wasn't supposed to. But yes.
Robin Heinze:
Yeah.
Jamon Holmgren:
I am known for my YOLO tactics.
Robin Heinze:
YOLO. Yeah, so I'll make sure there's nothing too unexpected in there. Commit, push it up, I'll open a PR with a pretty detailed description of what I did, maybe any caveats or gotchas, or "Hey, take note of this. This is why I made this decision." I'll make sure to include those in the PR description. And then add any screenshots or GIFs, I love making GIFs if it's an interactive feature. This is sort of a one-off component, but if I'm making a feature where I'm adding functionality where the user can interact with the app, I'll usually take a GIF.
Jamon Holmgren:
What tool do you use for that?
Robin Heinze:
I use a tool called GIPHY Capture. So, you know the GIF site GIPHY?
Jamon Holmgren:
Right.
Robin Heinze:
It's like the server. So they have a capture tool.
Jamon Holmgren:
Okay.
Robin Heinze:
Which is intended for you to capture stuff and then upload it to GIPHY, but I just don't do the upload step. But it's basically a sort of transparent overlay and you can move it anywhere on your screen and just press record and it'll record what's on your screen, and then let you save it as a GIF, and you can change the configuration if the file is going to be too big, you can decrease the pixel size or the frame rate to get it as small as you need. And it's super easy. You don't have to take a video and convert it, it's just snap, click, save.
Jamon Holmgren:
Making it easier on your code reviewers will mean that you'll get better quality reviews.
Robin Heinze:
Yes.
Jamon Holmgren:
And so that's what you're really looking for there.
Robin Heinze:
Very true.
Jamon Holmgren:
You're trying to give them a lot of context around what you did and why you did things the way you did. And then hopefully they will give you a good review.
Robin Heinze:
Yeah. I always appreciate it when my colleagues give me A, reasonably sized PRs, Jamon.
Jamon Holmgren:
What was that tone all about?
Robin Heinze:
Reasonably sized. Because if it's so huge that I can't digest it in 15 or 20 minutes, I'm just going to be like, "Well, I'm just going to approve it because I have no idea what's going on."
Jamon Holmgren:
My latest PR, tons of updates, that only has 34 files changed and 730 lines of code changed.
Robin Heinze:
Only.
Jamon Holmgren:
Added, actually. I did subtract 37 lines of code. This one's particularly bad, and I have no excuses.
Robin Heinze:
You're building something new, so of course there's going to be a lot of lines added.
Jamon Holmgren:
Yeah. If I was working with other people in the project, I would definitely be doing things differently. Honestly, at this point, it's probably better for me to just push it to master and then be like, "Hey everybody, I'm going to show you what I did."
Robin Heinze:
That's probably true.
Jamon Holmgren:
Reasonably sized PRs, though. That's a very good point.
Robin Heinze:
Reasonably sized, well annotated.
Jamon Holmgren:
Mm-hmm.
Robin Heinze:
With visuals.
Jamon Holmgren:
The thing that gets me I think, a lot of times, is when I'm working on something, I'll notice stuff that needs to be improved and it bugs me, and it's like, why don't I just improve it right now? Improve this little thing over here, or do this little thing over here. Refactor this, or rename this. It's very hard for me to put a PR out there that I know is going to have at least a day turnaround time before I get it back. And then have to work within the other one, might end up with conflicts, you know what I mean. That can be problematic. I know you can fork off of your, you can branch off of your PR and do that as well, but. There's also a lot of project teams have meetings, stand ups, things like that. And when do those kind of come into play?
Robin Heinze:
Totally depends on the team. Our team, personally, has stand up right after lunch.
Jamon Holmgren:
Mm-hmm.
Robin Heinze:
It's a pretty neutral time because we have people in different time zones.
Jamon Holmgren:
Mm-hmm. Yeah.
Robin Heinze:
So you can be pretty sure that most everyone's going to be online around that time. So we'll have a quick stand up, it's usually ten minutes.
Jamon Holmgren:
That's pretty good. A lot of times stand ups can stretch on, and on, and on if you're not careful. That's something that project teams have to really pay attention to. So that's with your project team, now what about Infinite Red, for example. We're at Infinite Red here. We have other meetings, I know this because I'm usually the one calling them.
Robin Heinze:
You're in them.
Jamon Holmgren:
You fit those in as well.
Robin Heinze:
Being a consultancy, I consider myself part of my client's team, but I'm also part of my Infinite Red team, and so I'll have meetings that are completely unrelated to my client's project that I'll make time for. So we have bi-weekly Infinite Red all-team meetings. Sometimes we'll have specific engineering team meetings.
Jamon Holmgren:
Yeah, we just had one yesterday that was about VS Code tips and tricks. And this is one thing that, as a consultancy, and I think even in other development environments, it can be similar, where people get siloed. Especially in remote work, you don't get a chance to see, I'm not standing next to you like, "Whoa, what did you just do there? That's pretty cool." Or, "What's that app that you're using, that's cool." I'm not seeing that. I'm seeing the results of your work, which is actually really cool for some reasons, results oriented rather than just “how you work oriented.”
Jamon Holmgren:
But we also miss out on the good parts of that, so a couple weeks ago, one of my engineers asked me to help them get up to speed better on VS Code. They were still struggling with optimizing their workflow, so we did a one on one where I kind of taught them some keyboard shortcuts with VS Code and whatnot. And then after, I was like, "Why don't I just do this with the whole engineering team?" I feel like there's a lot of people that could benefit from this. It was an optional thing, you didn't have to come, but I scheduled that and we did that yesterday where we all got together and shared, "Hey, this is how I use multi cursor support. This is a keyboard shortcut that I use all the time." And it was a 45-minute meeting and it was just packed with all kinds of cool stuff, and I learned some things, for sure, and I've been using VS Code for a very long time.
Robin Heinze:
Yeah, I definitely learned some things too. Usually, that kind of workflow optimization, I learn from other people. If I spend a lot of time pairing with someone, I'll be like, "Oh, wow, you just did that really fast."
Jamon Holmgren:
Yeah.
Robin Heinze:
"What did you use for that?"
Jamon Holmgren:
Yeah.
Robin Heinze:
And so if we don't make the time for that kind of sharing, it's not going to happen.
Jamon Holmgren:
Exactly. Those meetings are done, you're kind of getting toward the end of your day. How do you wrap things up?
Robin Heinze:
Usually I'll check the Slack channels again, see if anything has really happened during the day while I was more heads down. Maybe I have to prep for the podcast that day or do some other sort of “me specific” work.
Jamon Holmgren:
Yeah.
Robin Heinze:
And then usually I'll sign off and go get my daughter from daycare.
Jamon Holmgren:
Yeah. What about breaks during this? You're not just working straight through, you're taking small breaks.
Robin Heinze:
I do eat occasionally.
Jamon Holmgren:
You do eat, you're not a robot.
Robin Heinze:
One of the lovely things about working from home or working remote is that if I reach sort of a natural pause in what I'm doing, I can go down and get a snack or a cup of coffee or switch the laundry or whatever I need to do. So I really love that I can sort of integrate breaks throughout my day and integrate little pieces of my home life.
Jamon Holmgren:
Yeah.
Robin Heinze:
Throughout my day without it needing to be a big, "Okay, I'm going to take an hour off to go home and do something." I can just sort of weave those in throughout the day.
Jamon Holmgren:
My daughters don't do this really very often anymore, but I think you remember when you first started working at Infinite Red, we'd be on a Zoom call, just like we are here, and my daughters would come in and want me to help them with a toy, maybe put some clothes on a Barbie or something like that as we're working. That was just a constant thing with me and I thought it was very cool. Now they're much too big for that, they don't do that anymore. But yeah, I love the little interruptions, the little kind of, "Hey Dad, come check this out." And I'll go look at it or whatever. I actually find those things very cool. Obviously the context shifting can be a little jarring and hard to stay focused on what you're doing. So you have to have some separation. I have a lock on my door I can use, for example, if I'm in a podcast or something like that. They're pretty well-trained about don't just bust in in those situations. We've been working from home for six plus years or something like that and it's been fantastic.
Robin Heinze:
I can't imagine going back to an office at this point. And even now ever since COVID, my husband's been working from home a lot more and I've actually really gotten used to being able to like, hey, I can go downstairs and eat lunch with him.
Jamon Holmgren:
Yeah, it's been great. And I love this sort of flexibility. At Infinite Red, we try to set it up where the expectations are totally normal. Where Todd, my business partner and our CEO, he will say, "Hey, I'm taking a siesta this afternoon." And he'll be gone for two hours just taking a nap. And anybody can do that. It's fine. As long as you're not missing a meeting or something, go ahead, take a nap. There's nothing wrong with that. If you work a little different rhythm, there's some people that work better at night, better in the early mornings, they can kind of choose their own path in that. So from that standpoint, the flexibility is really nice. And just even things like, "Hey, let's all hang out in Kitchen Table." Which is our Zoom room that we use specifically for hanging out. There's different ways to kind of take breaks and step away from it for a little while.
Robin Heinze:
Yep.
Jamon Holmgren:
I think we've pretty well handled that topic. A day in the life of a React Native developer. If you have any thoughts about this, please do tweet at us, we read all the tweets. So you can find me @JamonHolmgren. You can find Robin @Robin_Heinze with an E. And you can also tweet @ReactNativeRDIO, which is our main Twitter account for this show. Robin, do you have any weird bugs that you want to talk about in this episode?
Robin Heinze:
I don't have any this week.
Jamon Holmgren:
As always, thanks to our producer and editor, Todd Werth, our transcript and release coordinator Jed Bartausky, and our social media coordinator, Missy Warren. Thanks to our sponsor, Infinite Red. Check us out infinite.red/reactnative. Special thanks to all of you listening today. Tell people about this podcast, especially if they're new, they're considering React Native. Have them check out this podcast. We would really appreciate it. Reminder, we are hiring senior level React Native engineers. Actually, you don't need to necessarily be a React Native engineer, but senior level engineer that has some interest in React Native. US or Canada. And just go to careers.infinite.red and fill it out, I will read your application, I promise. And I will reach out and let you know whether we're interested in moving forward or not. Either way, see you next time.
Robin Heinze:
Bye.