250: Yolo Snarf
Transcript from 250: Yolo Snarf with Chris Svec, Elecia White, and Christopher White.
EW (00:00:06):
Welcome to Embedded. I am Elecia White, here with Christopher White and Chris Svec. This is one of those loved-and-hated basics episodes about a loved-and-hated topic: version control!
CW (00:00:19):
Who loves it?
EW (00:00:21):
Well, I love version control.
CW (00:00:24):
But you don't love talking about version control.
EW (00:00:26):
No, not so much.
CS (00:00:27):
When it saves you from -
EW (00:00:29):
When it saves you.
CS (00:00:30):
Yeah. When it saves you, you love it.
EW (00:00:34):
Before we start digging in to version control, we have an announcement. T-shirts. T-shirts are going to go on sale pretty much when this episode goes up. They will only be on sale for three weeks.
EW (00:00:48):
So...if you haven't ordered them by mid-July, you may not be getting them. Just go and do it immediately. If it's long after that now, then I'm sorry.
EW (00:01:02):
You can send me a nice email, such as what Stephanie sent because of Eric's shirt. And maybe we will start another t-shirt sale.
CW (00:01:15):
You're not going to elaborate on that? I'm not sure she authorized you to elaborate on any of that.
EW (00:01:21):
I didn't elaborate on any of it.
CW (00:01:23):
You said her name.
EW (00:01:25):
That's true.
CW (00:01:26):
Practically doxxed her.
CS (00:01:28):
And her significant other's name, so, I mean, right there.
EW (00:01:32):
Yeah. Okay. So version control. Maybe we should revert this and go back to an earlier version?
CW (00:01:39):
No.
EW (00:01:39):
Too bad we don't have any.
EW (00:01:45):
Okay. I have this idea, where we're going to talk about version control, but we're not going to talk about version control, like what is Git, what did you say? Bisect? Bison? Buffalo? I don't know. We're not going to talk about specific things.
EW (00:02:02):
We're going to talk about how you convince other people to use version control. And we're going to talk about what the importance is. And we, of course, are going to have to touch on what some of these things are.
EW (00:02:16):
Like "What is a branch?" And some of the more advanced topics in version control. But I kind of want to pretend that we are each going to startup X, individually, not together. Together we'd take over.
EW (00:02:32):
And at startup X, they have a small hardware/software widget, but they have no version control when we walk in the door. There's a EE, who's been an EE for as long as we've been alive. And he doesn't see the need for version control.
EW (00:02:50):
There's a college intern in software, or something, who doesn't know what version control is, and hasn't been alive for long as we've been working. And we have a manager who doesn't care.
EW (00:03:04):
Doesn't care about anything but getting things done. "You have to ship it right now, oh my God finish, finish, finish." You've met this manager, I'm sure.
EW (00:03:13):
And maybe there's another software engineer, just because you need somebody to talk to at lunch.
CW (00:03:19):
I quit.
EW (00:03:20):
You can't quit. Startup X has the bestest thing. They make the super finest widgets.
CW (00:03:28):
Alright.
EW (00:03:28):
Is the explanation for why we need version control the same for all of these people?
CW (00:03:33):
It should be. Because otherwise you don't have a consistent story, right?
EW (00:03:38):
Well, no.
CW (00:03:38):
Or are you saying the EE should be using version control?
EW (00:03:44):
This is kind of where I want to go.
CW (00:03:45):
Okay. Alright. It's the explanation for why all these individual people should be using version control in their particular areas.
CS (00:03:52):
So are we talking to all of them at once kind of thing? Are we coming in and saying, "Look, you just hired me. You're paying me money. One of the things I know is that version control is a good thing." How do we sort of evangelize this to get them on board with using it?
EW (00:04:04):
Yeah. Except the words we'll use for the very experienced engineers, who are not using it for a reason, are going to be very different from the words we use for the college intern -
New Speaker (00:04:18):
Sure.
EW (00:04:18):
-who just...isn't aware of it. And the reasons we give are going to be in terms of time for the intern and the EE, but it's going to be in terms of money for the manager.
EW (00:04:34):
So, I mean,...I have this group of people because their needs are different, and version control can help each one. I don't think the manager is going to be checking in his PowerPoints, although I have done that.
EW (00:04:49):
But the manager needs to be aware of version control and needs to give us the time to implement it.
CW (00:04:57):
Okay.
EW (00:04:58):
Okay. So now let us begin. The world's most boring D and D session. Roll for initiative.
CW (00:05:05):
I got a 20.
EW (00:05:07):
Good, you get to go first. How would you explain version control? And which one would you choose to go after?
CW (00:05:14):
I would talk to the intern first, because they're most impressionable, -
CS (00:05:19):
Nice.
CW (00:05:19):
- leave the rest to you guys. And I would say, "Imagine, you have code, and you've got a file. But you have this magic dial that you can turn, and it will take you back in time through everything you've done to that file."
CW (00:05:36):
"So let's say you made a mistake on Wednesday, but you didn't notice it until Friday. But you're not sure what the mistake was. You could look and see everything you'd done between Wednesday and Friday and find the mistake. Wouldn't that be great?"
EW (00:05:56):
Isn't that what Time Machine does on your laptop? It's just a backup program.
CW (00:05:59):
Nobody uses that.
EW (00:06:01):
Oh, okay. Fair enough.
CW (00:06:04):
I mean, yes. And you could say, "Oh, well I should just use Time Machine." But Time Machine doesn't tell you intent of anything, right? It's just a list of historical stuff...You don't have any notes about what you were doing.
CW (00:06:19):
You don't have really a timestamp for when things happened, and you didn't do anything manually. So you don't have any control over what's going on. It just does it whenever.
CW (00:06:31):
And if you don't have control of what's going on, it might miss something. Or it might have two pieces of code that you worked on that really didn't have anything to do with each other as a change.
CW (00:06:43):
And so it's difficult to separate those out, for example. But if you have something that gives you a complete history of everything you've done intentionally, that's a huge win, right?
EW (00:06:56):
That is.
CW (00:06:57):
Also, you might make a mistake. You might have your code, and you typity, typity, typity, and then you hit control K control X, I don't know. Some Emacs thing I'm probably butchering.
CW (00:07:10):
And you blow away a bunch of stuff, and then you save it, and it's gone. You can just revert to what your version control system, your magic thing, has.
EW (00:07:23):
Okay. So -
CW (00:07:24):
And it brings back your code the way it was just before you nuked it.
EW (00:07:28):
It's a magic backup that will have documentation about what changed over the last period of time and -
CW (00:07:37):
Forever.
EW (00:07:38):
It's an immediate going back to the last known good.
CW (00:07:45):
At least. That's the very least description of what it does.
EW (00:07:50):
Okay.
CW (00:07:50):
I think I won the college intern over...You want to roll for me to see if that worked?
EW (00:07:57):
Yeah. Roll for damage.
CW (00:07:59):
I have a plus five horn of persuasion.
EW (00:08:02):
It's the voice, man. It's when he gets in that voice. Okay, Svec. Who do you want to take on?
CS (00:08:07):
I'm going to take on the manager.
EW (00:08:09):
Aw, that's easy. Okay.
CS (00:08:11):
Is it? Is it?
EW (00:08:13):
I don't know. Okay. The manager. The manager's tough. The manager's kind of mean.
CS (00:08:17):
Okay. Okay. I mean, the EE who's been working longer than I'm alive is probably tougher than the manager. You're right, but -
CW (00:08:22):
Yeah, we'll take that one together.
CS (00:08:26):
That's right. That's right. We'll just take him out maybe. So the manager, the manager's thing with revision control is that, "Look, your people are going to make mistakes, and revision control helps them roll back and fix those mistakes when they happen."
CS (00:08:43):
"And it also, if a developer leaves, if one of your people leaves, which I know will never happen, but it will happen. Then you will have this documentation of what people have changed over time."
CS (00:08:57):
"And you can sort of see what they were thinking. See what approaches were tried in the past, perhaps, and you will lose less of the context, less of the institutional knowledge, that person has when they left if some of that is in version control."
CS (00:09:11):
Additionally, when you are shipping software, you're shipping software for your products. Maybe you just have one product today, because you're a startup and you just have a small hardware/software widget.
CS (00:09:21):
At some point you are going to have either more than one product or more than one release. You're going to have an alpha release and a beta release.
CS (00:09:27):
And then you're going to have your 1.0 release. And then you're going to have...whatever other releases you do as you go along. Version control allows you to sort of make make "branches," is what they're typically called.
CS (00:09:44):
Make a note that this is the software release for alpha. This is the software release for beta. Then we made these changes and we released this for 1.0. And then we made this bug fixed and called it 1.1. And so you can go all the way through all of your products.
CS (00:09:58):
You can kind of keep them separate and see which code is shipping on which device on which day, and with the documentation to say what changed, and what didn't change. The other thing is you have a copy of the code, which Elecia has just told me to say, but I don't know what she means by that.
EW (00:10:16):
No, I didn't, I'm sorry. This is why we don't usually let guests have the outlines.
CS (00:10:22):
You put my name in there.
EW (00:10:23):
You're right, because I was thinking, sorry. Okay. So one of the things you said sort of, but I thought you might've glossed over too much is, somebody leaves. And you mentioned about knowing the history.
EW (00:10:38):
There have been companies I've been at where people leave, and they kill their notebook, because they're angry. And no one else has a copy of the current code or the current schematics.
EW (00:10:50):
So when we talk about version control systems, that centralized repository, where we share things, and where nobody has the final copy of the code, everybody has some version of the code. And the server, or the central repository, is what contains the stuff.
EW (00:11:10):
But I think when you talk to the manager, you should also say, "Look, if EE leaves, do you have any idea where that code exists or where his schematics live?
CS (00:11:23):
Yeah. That's great. That's the pain the managers are going to feel. And you can point to today, Tesla, right? Tesla had some rogue engineer who apparently, reportedly, went off, sabotaged their code, and maybe left the company?
CS (00:11:37):
If they have it under version control, they can go and see what this manufacturing software changes were, when it was made, maybe even who it was made by. And at the very least they can roll back to the stuff that was before it was sabotaged.
EW (00:11:49):
And I guess that means I get to go after the EE? No, I'm the DM. You guys have to go for the EE yourselves.
CW (00:11:57):
Wait, since when are you the DM?
EW (00:12:00):
My little world.
CS (00:12:03):
It's her show, man.
CW (00:12:05):
Alright, we can attempt to go after the EE. I can make an attempt, but I don't know.
CS (00:12:09):
What about the other software engineer, the more senior software engineer?
CW (00:12:11):
Yeah, yeah.
CS (00:12:11):
Let's go after him first.
EW (00:12:12):
Okay.
CW (00:12:13):
Why aren't you using version control, you moron? What the hell is this? You call yourself an engineer? How long have you been doing this? What is this file that says "I2C driver, underscore C, final, final, final version 3, version 8 dot C?"
CS (00:12:32):
And he'll say, "Well, that's the one that came after the final, final." And you'll say, "Look, there's a saner way to do this. Just put it in version control. You've got to learn a little bit more to learn how to check your files in and out."
CS (00:12:45):
"You've got to write a little bit as you check it in and out, but haven't you been burned by not having a backup?"
CS (00:12:51):
"Haven't you wanted to be able to roll back the code you checked in last night at midnight, when your brain was so addled, you know that the stuff you did doesn't work? Haven't you wanted to be able to go back and figure out exactly what did we ship to that customer?" [inaudible]
CW (00:13:04):
"I don't want everybody seeing all my work changes. I don't want them to see it. Maybe they'll see something they don't like."
CS (00:13:14):
Oh, you got the whole insecurity thing.
EW (00:13:18):
Yeah. "Or my code doesn't compile right now so I can't commit it. It hasn't ever compiled."
CW (00:13:24):
"I don't like Perforce."
EW (00:13:26):
That too.
CS (00:13:27):
Oh.
EW (00:13:27):
Or "I tried to put in SVN and nobody else would use it. And then I had some error, and I could never figure it out. So I just gave up."
CW (00:13:36):
"The intern just commits for me."
CS (00:13:39):
So the interesting thing in software engineering is I found that in many companies that engineers don't want to be dictators, and even managers don't want to be dictators. And sometimes I think you just need a dictator at a company to say, "Listen, we're using version control right now."
CS (00:13:52):
You will use version control. We will use Perforce, or SVN, or Git, or Mercurial or whatever you want. And if you don't like it, I'm sorry, at-will employment, go for it, maybe not in your jurisdiction.
CS (00:14:03):
But...we're not going to have this conversation anymore, and we're going to do it this way. This is not the way to convince the software engineer. This is perhaps the way to get him to quit. So maybe we don't want to do that, but -
EW (00:14:13):
Well, if he's been working here this long without version control. Yeah. Well, Chris's original rant was good because I expect better.
EW (00:14:25):
If you're doing professional software development, I expect you to sit down with a book and do version control. And it will hurt for the first three weeks, and then it will start to save you a lot of time, and pain, and suffering.
CW (00:14:42):
It's like a surgeon who says "I don't like wearing gloves."
EW (00:14:44):
Yeah. Yeah.
CS (00:14:49):
Another way you could sell is that, "Look, as the company gets bigger, coordination is necessarily going to have to increase. Because we're adding people, and therefore we're adding communication paths, and you're gonna have to talk to more and more people.
CS (00:14:59):
And version control is one way to coordinate the "who has done what when." Especially as we have more and more software, and more and more people working on more and more software, we need to keep track of things better.
CS (00:15:10):
And version control is a way to do that so that we make fewer mistakes. We step on each other's toes less often, and things just go smoother."
EW (00:15:19):
That's a good one, too. I mean, the company is growing. We need to start having a little bit better communication, and version control as a way to communicate.
CW (00:15:30):
Now, one of the things that none of us mentioned about version control is its ability to aid in having several people work on the same code at once. If you just have random files everywhere, you can't have two people, very easily, making changes at the same time.
CW (00:15:52):
Most version control systems are pretty good at at least helping you figure out, if simultaneous changes are made to a file, how to resolve those differences. But if it's just a text file, on the server, you're pretty much doomed.
EW (00:16:08):
Well, it depends on the version control system. I mean, you'd think about SVN and Word documents. You're locking them to make sure that they're protected. Or even when you think about the older version control systems, CVS, you could lock files and merging was harder then.
CS (00:16:25):
But at least they would tell you -
CW (00:16:26):
Yeah.
CS (00:16:26):
- "Hey, Elecia's working on this file right now."
EW (00:16:30):
Right.
CS (00:16:30):
"So you might want to either hold off your changes or," yeah. Whereas now SVN, and Git, and these other ones, are actually quite good at merging in changes that might even be conflicting.
CS (00:16:42):
And they ask for help when there's a merge that can't be handled easily, then they kick it up, back to the human and say, "Hey, there's a merge commit or sorry, there's a merge conflict."
CS (00:16:52):
"So you changed something, and Chris changed something, and Elecia changed something, and you changed the same things. So I don't know what to do. So you figure it out, human."
EW (00:17:05):
Okay. And how about this EE?
CW (00:17:05):
Oh, I don't know. It depends on what we think, the trouble with EEs is, well.
EW (00:17:17):
[Laughter]. Title suggestion.
CS (00:17:17):
Is that another basics episode?
CW (00:17:19):
You ever meet of these EEs? These EEs, you hear about these guys? These EEs? Let me tell you about these EEs. No...So software engineers work on text files, right? And what we were just talking about, merging, and showing differences in things is a reasonably simple problem to write software for, right?
CW (00:17:39):
To compare differences in text files, and show you this one changed here, and this will change here. Or note that two lines were simultaneously changed, and do the thing that Chris was mentioning, and call out a conflict.
CW (00:17:52):
EEs tend to work on graphical things, right? Schematics, Gerber files, all that stuff.
EW (00:18:00):
Binaries.
CW (00:18:01):
Sometimes binaries, although the newer packages I think tend to be XML descriptors for the whole thing.
EW (00:18:07):
Yeah. But how do you merge that when you've been looking at the screen?
CW (00:18:11):
Well, you could if the software was nice, and didn't randomly rearrange things. Because the problem with auto-generated things in XML is the code that generates it...can do whatever it wants and rearrange things.
CW (00:18:23):
So if you've used a traditional version control system, you might have a change that's trivial to you, but is actually a change in every line in the file, and that's not helpful.
EW (00:18:31):
Change the cap value and suddenly all of your file lines are changed.
CW (00:18:34):
So, there's a lot of problems, because the version control systems we as software engineers use are not super well-suited to the kinds of files the EEs use: binary files, auto-generated files. So it can be done, but you kind of have to understand the limitations.
CW (00:18:54):
And if you do it with something like Git, or SVN, and you put binary files in, pretty soon, since it can't do diffs with binary files, any time you put in a new revision, it just puts the whole thing in as a new blob.
CW (00:19:10):
And so your repository, the server, the big file that holds everything, all the old files, and all the changes, that tends to get really, really big. So I don't know. What do you suggest?
EW (00:19:24):
I have some suggestions, but I'm not ready for that yet.
CW (00:19:27):
Okay.
EW (00:19:27):
I wanted to go down a slightly different path, with the same people, and ask you what kinds of version control do you think they already use?
CW (00:19:39):
Same people?
EW (00:19:40):
Well, I mean, like the EE.
CW (00:19:43):
The EE -
EW (00:19:43):
The EE almost certainly has a folder, maybe on Dropbox, which is nice for backing up.
CW (00:19:48):
If they're aware it keeps versions.
EW (00:19:50):
And probably has a file, has one folder labeled version 1.0 -
CW (00:19:57):
Yeah.
EW (00:19:57):
- and another folder labeled version 1.1.
CW (00:20:02):
If they're doing a good job.
EW (00:20:03):
If they're doing a good job, and they're labeling it with nice clean versions. They're copying the whole folder and making changes. And that is a form of version control. When we talk about that, there are versions. If there was a README file, you get almost all of the benefits of having things tagged and labeled.
EW (00:20:25):
And you still can't compare anything though. And that's because electrical engineering files are different. And that should be acknowledged. When you go in to say, we need version control, I still think there's a place for it in electrical engineering schematics.
EW (00:20:41):
But before we convince everyone that we need it, we do kind of have to identify what they're doing, because shifting everybody's world too fast is kind of bad.
CW (00:20:54):
[Mmm]. I mean, you don't have a choice. It's either or. You can't be halfsies.
EW (00:21:00):
No, but you could leave the EE alone.
CW (00:21:02):
Right.
EW (00:21:03):
If he's already got something that shows the releases, that shows good naming, that is centrally located. So that should he win the lottery and go to Tahiti, everybody still has access to the raw files, as well as the published schematics.
CW (00:21:21):
I'm going to take back what I said. You could go halfsies. You could let the EE do that. And then periodically check in when he says, "Okay, I'm done with this folder." And you check that in. And then you check in the next one.
CW (00:21:35):
So you'd have somebody help him, or you'd tell him how to do a simple check-in. But you could manage both systems in parallel, so he wasn't having to deal with it all the time.
CS (00:21:46):
So I've actually worked at places that do exactly that for, maybe not for electrical engineers, but the version control system used for some subset of control documents -
EW (00:21:56):
Yeah.
CS (00:21:56):
- was a Byzantine piece of software from 1973, I think. And there's a few people who know how to use it, and their full-time job is doing that. And so when I finish a document that needs to go into the system, I write in the document basically a change list in the document.
CS (00:22:12):
I say, "Okay, I made version 1.9, and here's what I changed. Chris Svec changed it on June 20th," whatever. And then I email it to the person, and they say, "Hello, can you please check this in?"
CS (00:22:24):
And they put it into this Byzantine system, because only they have right access and blah, blah, blah. And then at least it is there and backed up. It is horribly inefficient and painful, but it is a halfway solution.
EW (00:22:36):
Well, and that brings up the point that there is a thing called document control that is often different from version control.
CS (00:22:43):
What is document control?
EW (00:22:44):
Document control, at LeapFrog, for example, where we made consumer toys and we made a lot of them. So when I wanted to release firmware, similar to you, I would mail it to someone with release notes, and then usually I'd have to run around and get signatures.
EW (00:23:01):
...So that everybody said, the QA person said, "Yes, we tested this version." My boss said, "Yes, we approved this." Content development said, "Yes, we want this." And then that goes into the system with the sign-offs and with my code, and that goes to the factory where it gets put on the line.
EW (00:23:26):
And I can release my code into version control 97,000 times. But until it gets into document control, which like yours was pretty Byzantine and very controlled by only a few people, it doesn't get from my computer to the factory without these levels.
EW (00:23:43):
And that makes sense for software. It also makes sense for electrical changes, mechanical changes.
EW (00:23:50):
All of the engineering change orders go through the same process of, "Oh, you're done now. Okay. Now that you're finally done, and that everybody agrees that you are done, I will finally get around to telling somebody who can actually build it for you."
CW (00:24:05):
Yeah. And if you work on medical,...you're going to encounter that all the time, right?
EW (00:24:10):
Yes. Because your document control process then also includes your certification officer, who will say, "Oh, yes. I checked to make sure that this change is traceable through all of our documents and is documented everywhere it needs to be. And it's in the testing file as well." So, yeah.
CS (00:24:28):
Whether you're in medical or not, I mean, I think a lot of this comes back to some of the first arguments we were making...Version control is a great way to, you think you've done something. You check it in. You label it in some way that says this is the thing for 1.0.
CS (00:24:44):
And then later you can come back and see everything about it, and...remember what you did for 1.0, because it's in version control. And whether that's for auditing purposes, or for your sanity purposes, or making changes later, the revision control's there to save you.
EW (00:25:02):
Okay. Back to, how does version control work for some of these other people. I wanted to talk about the EE when I put that question in, but I also wanted to talk about the other software engineer, who may be doing a similar thing, where they've got it on some backed up system and version 97.3, 97.3_final.
EW (00:25:23):
But a lot of times I see the software engineers commenting code out.
CW (00:25:30):
Oh, God.
EW (00:25:30):
Huge blocks of code, because they're so afraid they're going to lose it.
CW (00:25:34):
Yes.
CS (00:25:35):
They might need it later.
CW (00:25:36):
But that happens even with people with version control.
EW (00:25:40):
I think that once you get over the mental hurdle of version control, you start trusting it -
CW (00:25:47):
You'd like to think that, wouldn't you?
EW (00:25:47):
- to be able to find that code again.
CS (00:25:50):
Well,...I mean, I find myself doing the same thing where I'll comment some code out, because I think maybe I'll forget that this existed. Maybe someone else will need this, and it's right here.
CS (00:26:02):
And if they're editing this code, they might need this little bit of debug code that I don't want to have in the actual checked-in product, but might help someone later.
CS (00:26:11):
They're not going to know to go look for it, because there's no breadcrumb there that says, "Oh yeah, six months ago, Chris Svec had some debug code here that would really help you right now." They're not going to go look through log files for that.
CS (00:26:21):
So I understand the motivation and kind of the fear of like, "Well, what's the harm if I just kind of leave it in here."
EW (00:26:30):
Yeah. And the versioning in the code. This works for a hardware version 1 that only went to one customer. This works for a hardware version 3 that went to a thousand customers.
EW (00:26:44):
This one works here, and you keep commenting them out, because you're only shipping the latest hardware. And things like that build up cruft in the code. And that cruft leads to bugs. And confusion. It leads to huge confusion for the new people.
CW (00:27:00):
It's even worse if you use #ifdefs...to comment stuff out, because then it's sometimes not clear if you can nest them and all kinds of things...Comments are bad, but blocking off stuff with ifdefs I find even more bad a lot of the time. Badder.
EW (00:27:15):
That's kind of better with some of the -
CW (00:27:18):
Some of the editors will mark it -
EW (00:27:18):
Editors are starting to show it -
CW (00:27:20):
- but it depends on if they can find the define, and -
EW (00:27:20):
- but they aren't always right, yeah.
CW (00:27:21):
Yeah.
CS (00:27:21):
So let's just agree. Clean code is good, and you should remove old stuff. Because it leads to cruft, and bugs, and confusion.
CW (00:27:31):
If you want to save it, make a note somewhere else.
EW (00:27:34):
Okay. So, we've talked everyone but the EE into using version control, and maybe we're occasionally, secretly, checking in the EEs things when things are released.
CW (00:27:48):
With some little modifications that he didn't know.
CS (00:27:52):
Another question I think I would ask, especially sort of day one, is, "Alright. Show me the canonical thing that you are shipping right now."
CW (00:28:00):
Yes.
CS (00:28:01):
Right?
CW (00:28:02):
All the artifacts.
CS (00:28:04):
All the artifacts. And when they come up with a three-and-a-half inch floppy disk, some Zip drive, and three laptops, and then they don't have the fourth laptop, because the intern forgot it at home. Then you can say, "Hmm, this seems like we could put this in one place and organize it a little better."
EW (00:28:23):
Yeah. I mean, that goes back to my note to you that you it's a copy of the code. It's a copy of the complete system. And back to the document control system, that was always what that was supposed to be for FDA and big manufacturing projects.
EW (00:28:39):
That it is a checkpoint in time of everything that would allow you to rebuild it all. Okay. So once again, we have the EE checking in sometimes, and we've all decided on a version control. What version control system did we decide on?
CW (00:28:59):
I'm inventing my own.
EW (00:29:01):
Nooo.
CW (00:29:02):
That's always better.
EW (00:29:04):
Nooooo.
CS (00:29:04):
I'd actually hoped to avoid a particular one for this, because then we're just going to get hate mail from people. Well, you're going to get, I'm not going to get any hate mail. I'm going to get, what's the opposite -
CW (00:29:14):
Well, let's just use an imaginary one. We'll call it Yolo. And it allows you to check files in. It allows you to make branches. It allows you to see who checked things in, and it provides authentication.
CS (00:29:28):
Fantastic. We're using Yolo. I love it.
EW (00:29:32):
He only said that because my shirt says, "You obviously love owls."
CS (00:29:37):
It's my favorite version control system.
EW (00:29:38):
Okay. Yolo.
CW (00:29:40):
So we'll just talk about it in abstract, and we don't even have to get into implementation details.
EW (00:29:46):
We should note where things go really off the rails for some of the popular ones.
CW (00:29:51):
Sure.
EW (00:29:51):
But I don't think we're going to talk much about Mercury?
CS (00:29:54):
Mercurial.
EW (00:29:54):
Mercurio.
CW (00:29:56):
No.
EW (00:29:58):
Mercurial.
CW (00:29:58):
There you go.
EW (00:30:00):
Mercushio. Romeo.
CS (00:30:02):
I think SVN and Git are the two more popular ones. And Git, I think, is much more popular. SVN was the new hotness back in what, 2002, 2005, something like that. It was hot until Git became a thing.
CS (00:30:15):
And now Git is...sort of the standard, and GitHub is a frequent interface to it. So I feel like most shops probably use SVN or Git, and I've used Perforce as well. They're all basically the same. They do very similar things. They work very similar ways.
CS (00:30:35):
There are tons of details. You will burn yourself on each version, sorry, on each different system. You will hate some part of it. You will love some part of it. And that's basically any piece of technology, isn't it?
EW (00:30:48):
Yeah. And that's a good introduction to it. So, okay. We're going to go with our own created system, although we would not recommend anybody actually do this. Choose SVN or Git. And Git is the version control system. GitHub, GitLabs, Bitbucket... Those are all places that you can have your Git repository hosted. So if we say, GitHub by accident and we mean Git, please forgive us, but it just starts to run -
CW (00:31:24):
Together.
EW (00:31:24):
- together.
CW (00:31:25):
Alright.
EW (00:31:25):
Or apart.
CW (00:31:26):
Alright.
EW (00:31:27):
Okay. So you go to the intern, and the intern is willing to use your version control system.
CW (00:31:35):
Okay. So there's no version control at this company.
EW (00:31:40):
Right.
CW (00:31:40):
Somebody has a directory that they can build out of. So we need to find that person.
EW (00:31:46):
The software engineer has one you can do build out of.
CW (00:31:50):
So the first thing we need to do is take that directory in its current state and put it into the version control system.
EW (00:31:57):
Okay. Is that checking it in?
CW (00:32:00):
No. Because you don't have a repository yet. You don't have the database portion set up. So somebody sets up the Yolo database.
EW (00:32:10):
Okay. And this could be -
CW (00:32:11):
You.
EW (00:32:11):
We set it up in GitHub, or we set up our own local SVN repository, or -
CW (00:32:20):
We're using Yolo.
EW (00:32:21):
Or we're using Yolo where magical fairies come and -
CS (00:32:23):
"Yolo init"
EW (00:32:25):
Right.
CS (00:32:25):
Enter. And then you do "Yolo add building_software_directory", recursively.
EW (00:32:34):
Okay.
CW (00:32:34):
And so Yolo looks at all those files. And through whatever mechanism the backend works with, whether it's over the network, or just copying it to a database file on the server you're choosing to use, it creates a snapshot of all those files, as they are now, as the first revision.
EW (00:32:55):
Okay. Do I have to type anything in? Do I have to have a message? It's just the first one. So we don't care if there's a message.
CW (00:33:05):
It might ask you for a commit message for the initial commit, but you would just say "initial import of widget thing."
EW (00:33:12):
Okay. So the intern comes back from lunch, and now wants it on their computer.
CW (00:33:18):
Okay. So Yolo is going to have to provide a way for people to get a copy of the source tree in the repository.
EW (00:33:29):
Okay. And this may be a link to the site where the repository exists.
CW (00:33:34):
Right.
EW (00:33:36):
Okay. So Yolo.
CW (00:33:41):
Let's say clone.
EW (00:33:42):
Let's say clone. "Yolo clone". Some random string of letters that probably starts with HTTPS.
CW (00:33:51):
Sure. Or SSH.
EW (00:33:52):
Or SSH. And we neglected to make the intern an account, but of course, somebody in Yolo power (admin) has to make an account.
CW (00:34:03):
Right. We didn't really talk about that aspect.
EW (00:34:07):
That's actually a good one. We should go back and think about how we explain to the manager security permissions and accessing...the code.
CW (00:34:21):
I was going to let the other Chris do that.
EW (00:34:23):
That's why you were pointing at yourself?
CW (00:34:25):
I was pointing actually to the West, so that's not the right direction. Which way are you?
CS (00:34:29):
Well, I'm the West, very, very far. On the East, closer. I'm over here. So the manager probably doesn't care about permissions right now, because he had nothing before this. Which means whoever's laptop the code was on, he had no idea.
CS (00:34:44):
So I would actually say this is a, we start off with everyone has full permissions for everything. And we worry about clamping down later.
CW (00:34:53):
I'd slightly disagree.
CS (00:34:54):
Okay.
CW (00:34:54):
I think you should have full permissions, but everyone should still have an account with credentials.
CS (00:35:00):
Oh sure. Yes, yes, yes. Everyone should have an account. That's one way you figure out what the intern did versus what -
CW (00:35:05):
Exactly.
CS (00:35:05):
- you did versus what did I do a month ago -
CW (00:35:07):
And you don't have people impersonating somebody else doing a check-in. "Oh, the intern, look what the intern did!"
EW (00:35:15):
"They deleted all the code."
CW (00:35:16):
"Look at this, they changed this whole thing to a Bitcoin miner. We're not making a Bitcoin miner."
CS (00:35:20):
I'm pretty sure the way that I ended up on this episode is actually because someone was impersonating me a couple of weeks ago. But, it's all good. It's all good. Oh, by the way, in case you ever need it, my voice is my passport. Verify me.
CW (00:35:32):
Thank you. I have that saved for now.
CS (00:35:35):
That's for you.
EW (00:35:37):
Okay. So we made the intern an account.
CW (00:35:40):
Yeah.
EW (00:35:42):
And they have a password, and they have full permissions. Although it could be that next summer's intern doesn't get to look at the algorithm, only has partial permissions.
CW (00:35:50):
...One thing to do is to make it so that they can't nuke the repository.
CS (00:35:56):
Yeah. Remove delete permissions or whatever.
CW (00:36:00):
Yeah.
EW (00:36:00):
Or add other users.
CW (00:36:01):
Right. But they have full access to all the files.
EW (00:36:03):
Read, write.
CW (00:36:03):
They can check out whatever.
EW (00:36:05):
Yeah. Create. Okay.
CS (00:36:07):
So they've cloned it, I guess. So they've cloned it. So what happens then?
CW (00:36:11):
They've snarfed it. They've snarfed it.
CS (00:36:12):
They've snarfed it.
EW (00:36:12):
Yolo snarf.
CS (00:36:12):
I do like Yolo snarf.
CS (00:36:16):
So that means the entire repository comes down to their local laptop hard drive.
EW (00:36:23):
That's a good thing to talk to the EE about. If we want to go back to them having version control, or the other software engineer, you don't have to carry your computer back and forth. If you can get remote access, you can sync your work computer and your home computer whenever you need them to be synced.
EW (00:36:44):
And that's a powerful thing for some people, not that they necessarily work from home all the time, but to know that they have access to whatever their latest data is, is kind of a nice thing. So yeah, we've just snarfed our data to the intern's laptop, but that matches with the software engineer hat.
EW (00:37:07):
And if the intern gets a new laptop, if this laptop goes up in a fiery ball, as they pour soda, and then try to solder on top of it. That's fine as far as the code is concerned. The code was not destroyed in any way...They can make a whole new copy.
CW (00:37:25):
So I'm going to break character for a second. And I know weren't going to talk about details of Git and SVN, but there's a fundamental difference between some of these with respect to getting a copy of the repository.
CW (00:37:39):
With SVN, when you check out a copy of the tree, you get the files at that point that you check it out at. Whether it's the tip of the latest version, or you specify a particular version, those are the files that you get on your computer. Because SVN is centralized.
CW (00:37:59):
So all of the revision stuff is stored on the server, and that's where it stays. With Git, and Mer, Mercu, you've made it so I can't say it.
EW (00:38:13):
Mercurshio.
CW (00:38:13):
With Git and Mercurial, that's not how they work. They're distributed, which means even though there's a central server that has a copy of the repository, any time you check out the repository or clone it, you get an entire copy of the entire history of the world.
CW (00:38:31):
That's great, because you can do all kinds of things without having to connect to the network again. Complicated things we won't probably talk about.
CW (00:38:40):
But it's also great, because you've got a backup copy on everybody's development machine of the entire thing. So you were saying, it doesn't matter if their computer lights on fire, somebody else has it. With -
EW (00:38:53):
Git, it really doesn't matter.
CW (00:38:53):
With Git, you really have everything. You have the history going back to day one. Now, there's some downsides to that because -
EW (00:38:59):
We were talking about the EE -
CW (00:39:01):
- if they get very large -
EW (00:39:01):
- bloating with binaries will make that whole process slower.
CW (00:39:04):
But that's a fundamental difference. And I just want to make sure people are aware of that when they're choosing something, that that's an aspect.
CS (00:39:13):
I think especially if you're not familiar with Git and with how type of system works. Typically there is one sort of central repository.
CW (00:39:23):
Yeah.
CS (00:39:23):
Because you want to have one. The company wants to have one. This is the truth. This is where the final shipping code comes from. This is the one that's hooked up to our Jenkins server that runs tests. This is the one good copy.
CS (00:39:37):
And so, frequently GitHub is the place where that might, or GitLab, or Bitbucket, those will host the one central copy that is the gospel truth copy.
CS (00:39:49):
And then, because the way Git works, or Mercurial works, you can then check out the full database, the full repository, onto your local machine too.
CS (00:39:57):
That's great, but you still have got to put it back up on the central one...when you're kind of done with your little piece of work, so that everyone else can see it.
EW (00:40:06):
Okay. That sounds like a good segue to "the intern has changed this file and has made something that needs" -
CW (00:40:14):
Well, first we've got to code review that puppy.
EW (00:40:17):
How are you going to get a copy of it to everybody?
CS (00:40:20):
Well.
EW (00:40:21):
Are we going to go branching already?
CW (00:40:23):
Gosh.
EW (00:40:23):
Should we skip branching for a second?
CW (00:40:24):
Gosh, this is -
CS (00:40:25):
I think he should print the code out -
CW (00:40:27):
I think -
CS (00:40:27):
- and we should get together in a dark room.
CW (00:40:29):
I think I'm going to go, I think I'm going to -
EW (00:40:31):
After lunch.
CW (00:40:31):
I'm going to go back to 1995. And what you do is you take a diff and you attach it to the bug. And then everybody looks at it. That's what we used to do.
EW (00:40:44):
That's not a bad way to do it.
CW (00:40:47):
But let's say, there's some method that they look at it, and everybody says it's okay.
EW (00:40:51):
Okay.
CW (00:40:51):
"You can check this in."
EW (00:40:53):
And that what we're going to call it. We're going to Yolo -
CW (00:40:57):
It's like putting a folder in a drawer.
EW (00:40:58):
- check in. And, in addition to checking in, at this point, you should always write a message. Even if the message is -
CW (00:41:09):
It should be required that you write a message.
EW (00:41:11):
"This no longer compiles. I just want to cry, but I need to save it in case there is something here. I doubt it. Please don't look at this monstrosity." That's a fine message.
CW (00:41:23):
Well, is it?
EW (00:41:24):
It's not a great message.
CW (00:41:25):
It's a terrible message, because the next person...to check out the code is going to get a broken file.
EW (00:41:31):
Well, I mean, that's sort of a team thing and a process thing we should touch on, but there have been times where I wanted to revert to a previous version in order to puzzle back.
CW (00:41:43):
[Affirmative].
EW (00:41:43):
But I needed that commit, or branch, or whatever. But I needed a commit, at least a temporary commit, that had what I had now, because I half wrote the driver I needed, and now everything was broken.
CS (00:41:57):
Now, unfortunately we get into the implementation details. This is an easier thing to do to leave yourself local bread crumbs. You need your local commit. "It is midnight. I am crying, and tired, and this is broken, but I'm going home. And so I'm checking in." In a tool like Git, no one else has to see that.
CW (00:42:14):
Right.
CS (00:42:15):
And...you will have it in the morning. On a centralized system like SVN, if you wanted to actually put back into the SVN repo, then everyone else has to see that. Unless you use a branch, and then we get into branching. And I don't know how in the weeds we want to go there.
EW (00:42:33):
I think we're going to get into the weeds there, but basically you should always, always commit with a message. And the message doesn't have to be written for the intern. The message doesn't have to be written for the manager.
EW (00:42:47):
The message is written for you and the other software engineers who are in the position you are in. And the goal is to remind them why and how you did this. What was the intent of this code modification?
EW (00:43:04):
And if there's a bug it's related to, you should absolutely refer to the bug. But if it's just, "I added a SPI driver and it mostly works, but not when you're in high-speed mode," in a week when I try to remember what I did, that's going to help me.
CW (00:43:24):
And you can standardize these things. I mean, we have one -
EW (00:43:27):
And that's a good idea.
CW (00:43:27):
We have one where you have to enter the bug ID and...there's a issues addressed section. You have to fill that out. Changes made, and you have fill that out.
CW (00:43:37):
So issues addressed might be, it doesn't work right, because of this and that. Changes made, "Well, I looked at the loop, and I modified this," and then how you tested it, and whether you did regression testing.
CW (00:43:49):
And you can get pretty formal with that, and it gets annoying. But it's nice to have like, "Okay, this is what we expect in a message from most people."
EW (00:43:57):
It is. And what you listed, what was wrong, what you did to fix it, how you tested it, that's a pretty good commit message. Svec, do you want to add anything?
CS (00:44:09):
No. I'm nodding along over here. This is, yeah. I mean, I'm thinking in terms of this as a small shop that has never done this before, keep the process to a minimum, so I wouldn't necessarily create a template for them, for us -
CW (00:44:21):
Right, sure.
CS (00:44:22):
- my new startup. Except for maybe say, "Hey, let's start with the bug ID, or with the story ID, colon, description of it. And then let's all kind of do what you changed, what was wrong, what you faced, what may not work."
CS (00:44:38):
And then as people get comfortable with it, maybe add process over time. That may backfire because then people get used to slacking off, and then you hit them with a process hammer.
CS (00:44:47):
They might not like it. I don't know. We have three of us, so we should try experiments. We can do A/B testing and see which company does better.
EW (00:44:57):
Since I usually work for startup Xs, I think, and you two work for much larger companies, I think I'm the only one doing the experiment here.
CS (00:45:07):
Oh yeah, you should totally do this across your clients.
CW (00:45:10):
Yeah, yeah.
EW (00:45:11):
I'm sure they'd like that. Okay. So the intern has checked things in, and then the intern goes over to the software engineer and says, "I want you to look at it." And this was not related to code reviews. And the software engineer says, "I don't see it." There's another step we need to do in order to sync everybody up.
CW (00:45:38):
Not if you're using, we haven't decided if Yolo is centralized or decentralized.
EW (00:45:43):
Centralized or decentralized, at some point, everybody else has to -
CW (00:45:49):
Well, there's two steps.
EW (00:45:50):
- fetch. Or pull.
CS (00:45:50):
...There's a minimum of one step, perhaps two steps -
CW (00:45:56):
Yes.
CS (00:45:56):
- that are required. So is Yolo distributed or not?
CW (00:45:58):
Let's go with distributed.
CS (00:45:59):
Alright, it's popular. So Yolo is like Git in that it is distributed. So the intern has, what did we say?
CW (00:46:08):
They checked it in.
CS (00:46:10):
They checked it in.
EW (00:46:13):
They committed it, which means it's committed on their local drive. And then they're going to push it to the server. In a central repository, those two steps are the same, commit and push. In a distributed system, commit and push are separate.
EW (00:46:28):
It can be quite confusing when you go between the two. But commit says, "Hey, Git, I want you to know," or, "Hey, Yolo, I want you to know about this change." And push says, "Okay, I want everybody to be able to see the change."
CW (00:46:44):
Yeah, commit...It only works in that local copy of the repository we talked about, that has everything, but it only makes the change there on your local disk.
CW (00:46:54):
And the push, or shove as it is in Yolo, takes it, and throws it over the network, and says, "Here's this thing from this other copy of the repository. I want you to put it in the master origin repository." And that usually takes a lot of authentication, because now you're going over the network.
EW (00:47:16):
Okay. So when our intern went over to our software engineer, and says, "I want you to look at my file," the software engineer might not be able to access it, because...the intern hasn't pushed it. But the software engineer might also not have it, because -
CW (00:47:36):
They haven't yanked it yet.
EW (00:47:38):
They haven't yanked, or pulled, or fetched.
CW (00:47:43):
You need some operation that goes to the remote repository, and says, "Hey, do you have anything new that I don't have in this local copy on my desk?" And it says, "Yeah, I've got 15 changes." And then it plays those back over yours to bring those in sync.
CS (00:47:58):
Plays it back? What does that mean?
CW (00:48:02):
It takes each commit as they come over and applies the changes.
EW (00:48:06):
It synchronizes them. It makes them the same. Chris is telling you it plays them back, because Git actually takes each thing -
CS (00:48:15):
Yeah.
EW (00:48:15):
- and applies them one after another. And so it really is playing them back, but mentally it's okay to -
CW (00:48:25):
It's just copy. It's just copy.
EW (00:48:25):
It's just copy.
CW (00:48:27):
Yeah. Yeah.
EW (00:48:27):
But it's just synchronizing them.
CW (00:48:28):
Sorry.
EW (00:48:28):
It's making them the same.
CW (00:48:29):
Sorry.
EW (00:48:30):
No, it's fine. I mean, it's hard to tell what detail is important.
CW (00:48:32):
So the software engineer has done that and he's, "Oh, look at that." And he can open the file and see it. He can run a command to maybe see the history of that file and see a list of all the commit messages. And there's the intern's at the top. Yeah.
EW (00:48:47):
That. That thing. What is that called?
CW (00:48:51):
What?
EW (00:48:52):
The log?
CW (00:48:53):
Yeah. The revision history?
EW (00:48:55):
The revision history.
CW (00:48:56):
Yeah.
EW (00:48:57):
That is one of those things that if you don't use version control, you don't know how much having -
CW (00:49:04):
Oh, yeah.
EW (00:49:04):
- the revision history, it's just some sort of magical device.
EW (00:49:09):
And it's really hard to explain because you get a list of kind of crappy commit messages, and dates, and people who checked them in. How is that useful?
EW (00:49:19):
But I'm telling you, it is so useful. And it's not just because, "Oh my God, the intern, didn't follow our style guide again. I'm going to look at this and it's going to be horrible. I'm going to spend my morning writing an email." It's just something about the logs.
CW (00:49:37):
Well, here's -
EW (00:49:37):
It feels like progress, sometimes.
CW (00:49:39):
Well, okay. But there's a very practical reason. Let's say somebody comes to you and says, "Hey, I ran version 1.8 last night, and three of the ICs lit on fire.
EW (00:49:52):
Woohoo.
CW (00:49:52):
But it didn't happen with version 1.6, which we released in April. And you go, "Ah, okay, I'm going to go look at the Git log for the IC driver file and look at all the things that were done since April." Now you have a list right in front of you of everything that could possibly have caused the bug.
EW (00:50:13):
And I have done binary search. You go halfway, does it cause the problem? You go halfway, does it cause the problem? Until you narrow in on when the problem started.
CS (00:50:23):
I think it's important to actually take a step back and talk about, be very pedantic, and say the two sort of miracles that have just occurred with having this history.
CS (00:50:31):
The first thing is that you were able to go back in time and say, what did we release, was it 1.6? Was that the older one? And then 1.8 was the newer one? Basically, pre-fire, and post-fire.
CS (00:50:42):
And you are able to see the text version, the log, of each file that changed, what changed. You can do a diff so you can see in code what changed.
CS (00:50:54):
And you hopefully have loving colleagues who have written notes to themselves and notes to you from the past to the future that say, "I changed this. Then I changed this. This didn't work. Oh, it turns out that on Friday at noon, if you run this code, sometimes it catches on fire."
CS (00:51:14):
And so sometimes you might get something that is the smoking gun, or the smoking chip in this case. If you don't get that, so, that's kind of the first miracle of version control.
CS (00:51:26):
The version control gives you sort of the history of everything that has just happened, both in human, written, here's what I changed, form, and in code deferrable form. The second miracle is that you can then go back and say, "Alright, let me get the thing that we built for version 1.6, the pre-fire version."
CW (00:51:46):
"Let me check it out as if it was." Go back and literally get the thing that was 1.6, check it out, recreate it, and then run it on the device and see, "Okay, no fire." And then "Let me check out version 1.7 and see if there was fire or no fire. Okay. No fire. That means the problem must've happened between 1.7 and 1.8."
CS (00:52:05):
And then you can say, "Okay, I know that was four weeks ago." So go to the code from two weeks ago, check for fire. And what Elecia said, you can go and do binary search, basically, on this issue. And then Chris was starting to say -
CW (00:52:18):
There's a Git command that does this for you.
EW (00:52:22):
Oh, bluh bluh bluh bluh bluh.
CW (00:52:23):
There's a Git command.
EW (00:52:24):
Bluh, bluh, bluh, bluh, bluh.
CW (00:52:26):
Git -
EW (00:52:26):
Bluh bluh bluh bluh bluh.
CW (00:52:26):
- is amazing.
EW (00:52:26):
Bluh bluh bluh bluh.
CW (00:52:26):
Let me tell you about the word of Git.
EW (00:52:27):
Okay, wait a minute. There were a couple other things -
CS (00:52:30):
The word of Git.
EW (00:52:30):
- that happened here.
CS (00:52:33):
The word of Git.
EW (00:52:33):
You went back to the original version, the 1.6 that wasn't supposed to cause a fire, and you rebuilt it.
CW (00:52:38):
Yeah.
EW (00:52:38):
And you checked to see if it caused a fire.
CW (00:52:40):
Yeah.
EW (00:52:41):
You know the brilliant part of that? We work with hardware that isn't perfect. Sometimes you realize then that it was never the code.
CW (00:52:50):
Oh, because it lights on fire on the version [laughter].
EW (00:52:52):
Because it lights on fire on the version they say works. Of course, if you're rebuilding it, you have tools, but there is another miracle to this revision log.
CS (00:53:03):
Three miracles?
EW (00:53:03):
And that happens on Mondays for me, when I type up my status reports.
CW (00:53:10):
Oh, you have everything you've done.
EW (00:53:12):
And it happens once a year, with a review, when I can go through and look at all of the changes that I have made. And if I wrote good enough notes, I have that list that my boss wants that says the effect I've had over the year.
EW (00:53:29):
So yeah, I think there are three miracles there, and I mean, tracking your own progress on things is kind of nice.
CW (00:53:35):
The flip side, the flip side of that is -
EW (00:53:39):
Caused fire.
CW (00:53:42):
No, is that there's some managers who really like metrics. And some version control systems, you can go in, and you can say, "Hey, I wonder how Chris has been doing the last three months. Wow. He's really been committing with a lower frequency than usual."
CW (00:53:57):
"That's somewhat concerning, and oh, look at Bob, he commits a hundred times a day. Bob must be doing a really great job. We'll promote him."
EW (00:54:08):
Or addition lines and subtraction lines.
CW (00:54:11):
Yeah.
EW (00:54:11):
Chris only ever deletes code. And Bob writes a thousand lines for every hundred check-ins.
CW (00:54:17):
Yeah. Chris's salary over lines of code written, it's not a number.
EW (00:54:22):
Oh. Yeah. These metrics,...they have been mocked extensively for good reason.
CS (00:54:33):
There are companies, there are companies who sell packages that extract these metrics and tell managers that the way to keep your employees doing better is to find people who are stuck by looking at the repository stats.
CS (00:54:47):
And then you can know when to offer them help because they are stuck.
CW (00:54:50):
That sounds reasonable.
CS (00:54:52):
Well,...it sounds reasonable. But then you read between the lines, and it's like, "Well, maybe the stuck employees need coaching or extra, anyway."
EW (00:55:00):
Or just fire them.
CW (00:55:01):
Or just yeah. Get rid of them.
EW (00:55:03):
Yeah. Well.
CW (00:55:04):
Because people should never-
CS (00:55:05):
We just shot ourselves in the foot with making the version control case, by the way.
EW (00:55:11):
Yeah.
CW (00:55:11):
Yeah, don't use it.
EW (00:55:12):
The metric systems are sometimes really good -
CS (00:55:15):
The metric system has been a mistake - [inaudible].
CW (00:55:16):
It's a tool of deep code.
EW (00:55:18):
That was a good joke. [Laughter]. You talked over it.
CW (00:55:20):
I'm sorry. I'll cut me. What was the joke?
CS (00:55:25):
I said the metric system has been a big mistake since the invention of the centimeter.
EW (00:55:31):
Yeah. Well as somebody who takes great delight in deleting as much code as I can get my hands on and still make the system work, those systems make me crazy. But, yeah.
CS (00:55:45):
If you work at a company where people, management, is, I will call it, abusing metrics, then you can hopefully find a new job. Because...I've never been a part of a system that works that way. Maybe I'm more fortunate than others, but, yeah, I don't know.
CS (00:56:03):
The hiring market for software engineers seems to be pretty good right now, depending on where you're at. So hopefully if that's happening, you can find somewhere else to go. Because it's not everywhere, for certain.
EW (00:56:15):
This is a good segue before we get into branches. I hear hiring where you're at is happening. Hiring.
CS (00:56:25):
It is happening.
EW (00:56:26):
Hiring? Hiring is happening?
CS (00:56:27):
Hiring is happening. Interviewing is happening at the very least...I work for iRobot. We are based in Boston, actually just outside of Boston. And we also have a office in Pasadena, California, and we are hiring tons and tons of people.
CS (00:56:41):
Actually, I think we have at least 20 different software engineering reqs that we're trying to hire for. Basically, we're trying to build more robots, more different types of robots. And we are hiring because of that.
CS (00:56:51):
So we're hiring, I think we had an Android software engineer too, because we have Android and iOS apps that we develop. We are hiring people with extensive computer vision and robotics background.
CS (00:56:59):
We are also hiring software engineers who maybe have dabbled in robotics, and maybe just think robots are cool, but aren't a PhD in robotics.
CS (00:57:07):
We were hiring the PhD in robotics and the non-PhD in robotics, or the non-PhD at all. So basically all types of software engineers. If you think working on robots is cool, if you think living in Boston, or Pasadena, California is cool, then please go check out irobot.com.
CS (00:57:23):
Somewhere on there is a careers link. And feel free to email me. My email is [REDACTED] at irobot dot com. That's a [REDACTED] at irobot dot com. And I would be happy to talk to you, even if you think you're not a potential match at all.
CS (00:57:37):
...I'm always happy to talk to people who are interested in what we do and listeners of this show. And yeah, I love talking about what we do. So it's a good time.
EW (00:57:48):
And if you don't recall his email, you are welcome to hit the contact link on embedded.fm, or email us, show at embedded dot fm, just ask for a referral. And I will hook you up, and Svec will talk to you, and it will be great. Okay.
CS (00:58:04):
Exactly. And if you don't remember their email address, you can email me at [REDACTED] at robot dot com. And I will tell you the show at embedded dot fm email address.
EW (00:58:14):
Great. We've gone through almost all the version control benefits. Somebody said that version control is like control Z for the software. And knowing how often I type control Z in order to undo...whatever I just did, I like the idea that -
CW (00:58:37):
There's less undoing than you'd think.
EW (00:58:41):
But there's so much, I mean, merge work with others, and how to figure out who did what, know which you did. These are all important. One of the benefits we haven't talked about is that you can gain an important feeling, and that is lack of shame.
EW (00:59:02):
Which is to say to everyone who keeps apologizing about your lack of version control system, I'm not in charge of judging you, unless you pay me to judge you, which I'm quite happy to do, but then you will definitely get a version control system.
EW (00:59:17):
But overall for all of the angst that goes into, "Oh, we don't have a version control system. It's just too hard." Just do it. It's not that hard. And it makes you a better engineer, and it makes your team more functional. Okay. Sorry. Mid-show rant -
CW (00:59:40):
I feel like we've branched off.
EW (00:59:47):
Okay. Like a tree.
CW (00:59:48):
I hope that's not mid-show by the way.
EW (00:59:52):
Because we're going to have to eat sometime.
CS (00:59:53):
I heard the editor's pretty terrible for this show, so I'm not sure that's going to get cut, man.
CW (01:00:00):
Nothing gets cut. Only synthesized things you didn't say get added.
EW (01:00:04):
Okay. The Yolo tree command.
CW (01:00:07):
Well, let's just talk about branching in the abstract.
CS (01:00:10):
So I actually want to...draw a line in the show so far. So up until now, what we've talked about is, I think Elecia, you said it, right, the control Z aspect.
CW (01:00:19):
Yeah.
CS (01:00:19):
Sort of the undo, and the history aspect of version control, and the documentation aspect of version control. So you can see what you did. You can go back and recover things you did before. You can see what was changed by who, when.
CS (01:00:32):
...I feel like from version control system to version control system, even back going to RCS or CVS, which are pretty old version control systems, through SVN, and Git, and Mercurial, and Perforce, and even Visual SourceSafe -
EW (01:00:47):
Yeah.
CS (01:00:47):
Yeah...If you're using Visual SourceSafe at work, yeah, you need change. But anyway -
EW (01:00:52):
Somebody finally hit bingo with that one.
CS (01:00:54):
That's probably true. That's probably true...So all those systems basically work the same, or do pretty much the same thing as far as logging, history, rolling back, that kind of a thing.
CS (01:01:08):
So there's not many differences between any of the systems as far as how they approach...that basic part of version control system. Where they differ a lot is I think what we're about to talk about, which is branching.
CW (01:01:23):
And I would say the stuff we've talked about up to now for a small shop, one or two people, is really almost everything you need. Checking in, checking out, commit messages, going through history.
EW (01:01:36):
But it's the minimum.
CW (01:01:37):
But yeah, it's the minimum. It's the minimal -
EW (01:01:39):
Understanding branches is going to make you happy.
CW (01:01:41):
So branches.
EW (01:01:42):
Branches.
CW (01:01:43):
I nominate not me to talk about this.
EW (01:01:47):
Okay. Since I'm probably the weakest on actually using branches a lot, I will go first. Let's say, we're going to go back to the intern, commit something, and we all want to review it, before the intern can put it into -
CW (01:02:06):
The main repository.
EW (01:02:07):
The main repository, or onto the server where it's going to function, onto production code. So we want to review it but...there's this chicken and egg problem. As soon as they committed it, it's committed. And we want to review it before it's committed.
EW (01:02:25):
So instead, the intern should commit to a branch. And the branch is going to be located in the same repository. Ideally, it's going to have a very descriptive name. There are lots of processes about how you do the names.
EW (01:02:45):
Sometimes it's initials and date as well as what it was based on. Sometimes it's shorter than that with the idea that the branches are deleted and die later after they're merged into the main one. But the idea is you're not committing for everyone.
EW (01:03:03):
You're committing a special set that people will get to look at that is not the production code, that's not the main code, that's not the master code. It's a branch, and I can have a branch, and Chris can have a branch, and Svec can have a branch.
EW (01:03:22):
And then at some point before we release, we all have to merge back into the main branch. And that process is really non-trivial, and I think you have to have a drawing for it. But that's me, because I get very lost with where...You branch off, and then you merge back in. Those are the terms we're all agreeing on, right?
CW (01:03:46):
Yeah, yeah.
EW (01:03:46):
Okay. So I have trouble with this sometimes. If I branch off of one point, and then I need that main stuff, I need it to come up to my branch, and then I need to merge stuff, but it doesn't quite work. And so there's this iffy -
CW (01:04:04):
Let's back up a little bit -
EW (01:04:05):
So where do I get lost -
CW (01:04:05):
- in conceptually what branching is.
EW (01:04:09):
Okay.
CW (01:04:09):
I'll try to describe it. So we talked before how you have this revision history, right? And each point in the revision history is, you can think of it as a snapshot of the code at a point in time. The way we've talked about it up to now is that's just a line.
CW (01:04:25):
A branch is a fork in that line, where now you have two revision histories coming off of one point, and they are completely separate. So once you branch, it's like a virtual copy of the code tree within the repository that's different...from the line that we were talking about before.
CW (01:04:48):
And changes can go into that, but they don't affect the other branch, the other -
EW (01:04:53):
The main. [Inaudible]
CW (01:04:56):
-and you can do this multiple times. Branches can have branches. It can get crazy. That allows you to make changes, check things back in, store them in the repository without affecting other people. Which is what you were saying.
EW (01:05:10):
And you still get all the good repository stuff.
CW (01:05:12):
Yeah.
EW (01:05:12):
Where other people can see it. You get backed up. You can go to a different location.
CW (01:05:16):
Yeah. Now, like you were saying, at some point you want to get that back to the main line.
CS (01:05:24):
Hang on, let's -
EW (01:05:25):
Branching's easy. It's the merging -
CW (01:05:26):
See, I went too far. I went too far. I went too far.
CS (01:05:28):
Well, I think -
CW (01:05:29):
Fix me.
CS (01:05:29):
- you went a couple of steps, well, no, I think you're good. So I think let's do the intern example now.
CS (01:05:34):
So we tell the intern the way that we develop software, we decided that the way we develop software is that, anytime you make a change, you don't put that change into the main, the master branch, until people have had a chance to review it.
CS (01:05:48):
But, because we want the code in the revision control system, so that...if the building catches on fire, or if you decide to quit, we still have your code the next day, and because the code needs to be in the revision control system in order for others to review it easily.
CS (01:06:04):
So what we tell the intern is, we say, "Alright, intern, you create a new branch using Yolo branch name. And so the intern has created their own branch, and they name it "intern dash bug fix 1234" because they fixed a bug that was "bug 1234" in our bug database.
CS (01:06:29):
And it's got the intern's name at the front of it, so that everyone knows this belongs to them. So then there is now a master branch in our repository.
CS (01:06:37):
And there is another branch, which has all the same history as the master branch for now, at the point when the intern has created his "intern dash bug fix 1234" branch. Then the intern commits their bug fix onto this branch, the intern "bug fix 1234" branch.
CS (01:07:00):
So the code is in the repository on their machine, but is not on the main branch, on the master branch. It's only on their intern branch. Have I gone too far, or not far enough so far?
CW (01:07:11):
I think that's okay.
EW (01:07:12):
Yeah. I'm good with this.
CS (01:07:14):
Okay.
EW (01:07:14):
The intern has changed on their branch.
CS (01:07:17):
Okay. Now, so...because Yolo is a distributed version control system, that branch only exists currently on the intern's machine. It does not live on the central server that our company X has. So then the intern does Yolo shove? Was that the word we used?
CW (01:07:35):
Yeah, yeah, yeah, yeah.
CS (01:07:35):
Yolo shove -
CW (01:07:35):
You're getting it.
CS (01:07:37):
- Yolo shove their branch to the main repo, to the central server. And so now the central server, which we as a company have agreed is the main revision control system, or server, now has the master branch and the intern's branch.
CS (01:07:54):
So then the intern walks over to the software engineer and says, "Alright, I've made the change. Can you please look at the change before I affect anyone other than my branch with it." Then the software engineer says, "Okay, in order to get your change, I have to," did we say yank?
CW (01:08:13):
Snarf. Snarf.
EW (01:08:13):
Snarf.
CS (01:08:13):
Oh, snarf.
CW (01:08:13):
Snarf?
EW (01:08:13):
Yank?
CW (01:08:13):
I don't remember.
CS (01:08:16):
Wow. This is terrible.
EW (01:08:18):
In Git, it would be fetch.
CW (01:08:20):
It would be pull.
EW (01:08:22):
This is my problem, that I have to do a fetch, a pull, a fetch, a pull, and then finally I am done.
CW (01:08:22):
Yeah, you should be able to just do a pull.
CS (01:08:26):
Just do a pull. Just do a pull.
EW (01:08:29):
Okay.
CS (01:08:30):
So you do Yolo pull. The Yolo pull. And then that means the software engineer's Yolo software looks on the main repository and says, "Is there anything new here that does not exist on the software engineer's machine? Oh, yes. There's a new branch that got created."
CS (01:08:46):
And then it pulls the branch down onto the software engineer's machine. The software engineer then sees this branch has a change on it where the bug fix happened, that the intern changed some files.
CS (01:08:58):
And the software engineer can build the code, can run the code, can look at the diffs of the code, can talk about it and okay, I'm going to stop there. Is that okay?
EW (01:09:09):
Okay. The software engineer has, we've okay'd the code. The intern's code that is on "intern branch" -
CS (01:09:16):
Whatever.
EW (01:09:16):
- "bug 1234" is ready to go. We want it to go back into the main branch.
CS (01:09:22):
Okay.
EW (01:09:22):
And like I said, I find branching very easy and intuitive. It's merging that's a pain in the -
CW (01:09:29):
Why?
EW (01:09:31):
Because if anything's happened in between, you can get conflicts. And because...I never really feel like I'm doing merges right. And this is from somebody, I do a lot of merges. I mean, I'm kind of making it sound like I'm completely -
CW (01:09:49):
Yeah.
EW (01:09:49):
- stupid about this. But I do -
CW (01:09:49):
So I think we should not get too deep into this.
EW (01:09:52):
Okay.
CW (01:09:52):
But there's a couple ways of dealing with this stuff. Git, for example, is very branch dependent. If you read the "How you're supposed to use Git," you're always supposed to be developing in a branch, and then you merge it back.
CW (01:10:05):
Everybody's got a branch for their current work. Branches all over the place. Because it's very quick to make branches in Git. Conceptually that's how they design it to work.
CW (01:10:15):
Unfortunately, they provide many ways of kind of solving the problem you have, about how do I merge back in? And the chief problem is the thing you said, where the main thing that you're merging into, the main trunk, has drifted past you.
EW (01:10:37):
Because in our example, the intern has made some changes.
CW (01:10:41):
Right.
EW (01:10:41):
The software engineer has made some changes. We've made some changes, and -
CW (01:10:44):
And now you're trying to put it back, but you're trying to put it back, and you're actually out of date in some way.
EW (01:10:49):
Yes.
CW (01:10:49):
So you've got new changes-
EW (01:10:51):
It's this lack of synchronization problem.
CW (01:10:51):
- but you've got a bunch of old stuff too.
EW (01:10:53):
Yeah.
CW (01:10:53):
So Git provides you a bunch of ways to do this. You can merge the main trunk into your branch, and that will bring you up to date. You can test locally in your branch. You still haven't done anything bad -
EW (01:11:07):
To the main branch.
CW (01:11:07):
- to the main branch. And then once you've done that you can merge back in. Now there's a time gap there where might've moved past you a little bit. Sometimes it matters. Sometimes it doesn't.
CW (01:11:17):
There's another thing you can do in Git called "rebasing," which is where it says, "Oh, well, take the master trunk and take my changes, only my changes, and put them on top as if I had committed them at the top." And that's nice, because then you get up to date, and your revision history looks nice.
CW (01:11:41):
That's another way to do it. Unfortunately, there's a bunch of ways to do it with these things. And that's where people get tripped up.
EW (01:11:46):
Yeah.
CW (01:11:46):
And each shop tends to have their own preferred way of doing things.
EW (01:11:50):
I was complaining about C++, and how there are 97 ways to do everything, and so everything feels very artisanal. Git is sometimes that way.
CW (01:11:58):
Yeah.
EW (01:11:58):
That you use it the way your team agrees to use it, and teams can agree with drastically different use models. And so, it's easy to feel like you don't know what you're doing if you don't know what...this team's methodology is.
EW (01:12:19):
There isn't a standardized, agreed upon methodology for everyone. And the books will tell you different things. I mean, if you get five different Git books they're all going to have different things.
CW (01:12:29):
Well, there's even named -
EW (01:12:33):
There's named methodologies.
CW (01:12:33):
- methodologies. There's Gitflow, which does this, "Oh, do your branches this way." So yeah, I don't think we should get too far into that.
EW (01:12:41):
That's fair. I mean, that's really kind of getting down into Git, and I think that's one of those things where you should get a book. You...should get a book. This is important to your career.
CS (01:12:52):
I think the meta point we can make here is that you've got to choose a way of dealing with branches. And so if you don't have any reason to choose any of them, just Google around. And Gitflow, or any of the more popular ones are well-documented.
CS (01:13:10):
You can find reasonable examples and reasonable explanations on the web. And so, just like when someone asks, "What C++ coding standards should I use?" I say, go use Google's. Not because Google is magical, but because it is canonical enough, because it's Google.
CS (01:13:24):
And it's published, and it's defensible, and it's something. And if you don't have a reason to not do that, then just start with that. So pick a flow, pick a way to use Git branches that seems to make sense for you, and stick with it.
CS (01:13:42):
And then within a few months, or a few product revs or whatever, you'll figure out what are the warts. What's the stuff that's really easy with it? What's the stuff that's confusing? And what's the stuff that's really hard to do?
CS (01:13:52):
And over time,...your use of Git and branches, or SVN and branches, or Mercurial and branches, will probably evolve. I don't think any company I've been at that has used any version control system has sort of stayed using the same model for more than a year, maybe a couple years.
CS (01:14:11):
So it is an evolving thing. Just like your product evolves. Just like the way that you write your software probably evolves. Your Git usage, or your SVN usage, will probably evolve and change as well as you learn more, as you hate yourself for having made decisions in the past.
CS (01:14:28):
And as you figure out what the warts were, just again, like with any other technology choice.
EW (01:14:36):
Okay. I have a few more questions, and then we should probably wrap it up. Do you have a time when you used version control, maybe outside work, or on something that wasn't code, and it was good?
CW (01:14:52):
I'm certain I did, but I'm drawing a blank.
EW (01:14:56):
You don't use version control for music at all.
CW (01:14:59):
Well, Logic has a little bit of a thing to help you with, but I would not,...no, that wouldn't work very well.
EW (01:15:09):
Svec, what about you?
CS (01:15:11):
So I wrote a book chapter, and it was about FreeRTOS, and that was a pretty significant chunk of work. And the publisher happened to...have, I think it was an SVN repository. It was the way that we delivered work, the authors delivered work to them.
CS (01:15:30):
And so I had to use SVN in order to give it to them. And I ended up using SVN to mark my own changes. And that was great too, because actually there, when it would be edited, they had an editor, had a copy editor, they could make changes, and it was there in the revision control.
CS (01:15:46):
And then I could go back through and make changes, either agree or disagree with their changes, and then go back and forth. And I would delete paragraphs safely, knowing that if I thought there was something good later, I could go back to it, because I had the magic of version control.
CS (01:16:00):
So I've done that with that. I don't know if it counts, but I've been versioning my .bashrc file since 1995 using RCS. And so I have it now. It lives in RCS directory in Dropbox, but I've carried that around with me since '95, I think.
CS (01:16:18):
And that just uses straight up RC, because RCS works. RCS is revision control system, it stands for, I think. And it is old, and it is super basic, and it works.
EW (01:16:29):
It's still functional.
CS (01:16:30):
Yup.
CW (01:16:31):
It was the first one I ever used, yeah.
EW (01:16:32):
Yeah, me too. I also used it for my book, and as Svec said, it was great. Because I could delete things, and I could trace things. And I could see what other people, what the editor and copy editors were doing.
EW (01:16:48):
And I didn't expect that to work as well as it did, but it really was quite nice. And the last question I have is, are there times you don't use version control, and realize later you really should have?
EW (01:17:03):
And for me, when I take classes at Udacity, or any of the classes I've been taking online, I don't version control my schoolwork.
CW (01:17:11):
Yeah. That's probably -
EW (01:17:13):
And I don't know why. I mean, I have private Git. It's not like I'm worried about showing off my answers to everybody.
CW (01:17:21):
Well, even if you just have it on your disk. You don't have to do a server.
EW (01:17:25):
No, that's true.
CW (01:17:26):
And most of the IDEs make it pretty easy.
EW (01:17:29):
And it would be so much better if I version controlled my schoolwork.
CW (01:17:32):
Yeah. It would be.
EW (01:17:34):
And yet -
CW (01:17:34):
...The same thing for me. I haven't -
EW (01:17:38):
...It seems like too much effort, but I'm sitting here telling you, all of the listeners and everybody, it's not nearly as much effort as you think it is. And I have totally regretted -
CW (01:17:48):
Especially for something like that. For something like that, you're totally doing the stuff we talked about in the first 15 minutes to half an hour, right? Where it's, "Oh, here. Just check this out and check it in. No trouble."
EW (01:17:59):
There's no branches.
CW (01:17:59):
Yeah.
EW (01:17:59):
There's no other people. It's just me saying -
CW (01:18:02):
There's not even push and pull.
EW (01:18:02):
- this is a good place -
CW (01:18:04):
Yeah.
EW (01:18:04):
- for me to stop today.
CW (01:18:05):
Yeah.
EW (01:18:06):
Yeah. Okay. Svec, do you have any times that you'll admit that you should have?
CS (01:18:14):
Anytime I added a Word document, or an Excel spreadsheet.
CW (01:18:19):
Yeah.
CS (01:18:19):
Right? I mean, Word has "track changes."...I hate track changes. It does not ever do what I want it to do. And there is no good revision control diff. Beyond Compare, which is my favorite diff tool in the world, actually does an okay job of diffing one Word document to another.
EW (01:18:40):
Word has in-app diffing now that's not terrible anymore.
CS (01:18:47):
Yeah. I use a Mac mostly.
EW (01:18:49):
Oh.
CS (01:18:49):
And I think it either doesn't exist on the Mac or didn't exist on the Mac.
CS (01:18:52):
So I wish at the very least, many times, that I had just stuck the whole stupid binary file, put the whole docx file, into revision control, so I could at least go and do a basic text diff on what was in there. Instead I trust their remember history stuff from within the app itself, and that doesn't end well.
CW (01:19:17):
I really wished I had it in the eighties when I was writing BASIC programs on an Apple II.
EW (01:19:22):
Okay. Last one. Really. I promise this is the last one.
CW (01:19:26):
[Inaudible] Don't roll your eyes.
EW (01:19:26):
The intern comes back and says, "Okay, it made sense, when you wanted to see my file, that I should commit it. But what if I'm doing a lot of stuff? Do you only commit when you're done? When it compiles?"
CW (01:19:42):
Well, this is the place where branches are nice, because...then you can commit as often as you like, and you don't harm anybody else.
EW (01:19:50):
How is as often as you like, how long is that?
CS (01:19:54):
I give the same advice that I give about voting. Vote early, vote often. Commit early, commit often. That was a joke. That was a terrible joke. But seriously, commit early, commit often.
EW (01:20:06):
That would have been funny if you were from Chicago.
CW (01:20:10):
I'd say as frequently as any time you make a functional change that you think is a unit of work.
EW (01:20:17):
On our Slack channel, on the embedded.fm Patreon Slack channel, I suggested if you haven't committed, you should commit every night before you go to bed.
CW (01:20:30):
Oh, yeah. Definitely.
EW (01:20:31):
Because when you wake up in the morning, you never know what that last hour of work was. And it's a good habit to get into. I mean, we say commit often, but I admit four hours will go by before I'll commit.
EW (01:20:46):
I don't usually manage a whole day, but early in my career, it was good to get into the habit of not waiting too long.
CW (01:20:54):
Yeah.
EW (01:20:55):
You're not hurting anybody by adding commits.
CW (01:20:57):
It's free.
EW (01:20:58):
It really is free.
CS (01:21:00):
Well, the beauty of Git is that it is free, and you can check in code that is broken, and that is not working. And you say, "I am just too tired to deal with this compiler bug, but I want to save where I'm at."
EW (01:21:12):
Yeah. Alright. Let's see, you are still hiring at iRobot, which we already talked about. And I guess that brings us to the last, last, last question. Do you have any thoughts you'd like to leave us with, Chris Svec?
CS (01:21:30):
Yes. I guess when you come up against anything like version control, which seems like this giant piece of work, this giant messy thing, sort of take a step back and think, what am I trying to do?
CS (01:21:42):
At the beginning of this conversation we said, how do we convince the manager, the software engineer, the electrical engineer, that any of this is worthwhile. The reason it's worthwhile is because you get history. You can recreate stuff if you break something or lose something.
CS (01:21:54):
And then you get this kind of release management sort of branching for different projects or branching for different efforts. So as long as you remember sort of the high-level why you're doing it, I think that will help you endure the pain when you do shoot yourself in the foot.
CS (01:22:11):
When you do have to figure out the right branching strategy for you, when you do realize, "Oh, I wish we would have done it differently," you want the history. You want the being able to go back in time. You want to be able to recreate stuff.
CS (01:22:22):
And you want to be able to sort of sanely separate different code that's doing different things using branches. So it's totally worth it at the high level, even though it's frustrating on a day-to-day basis sometimes.
CS (01:22:35):
...I'll say the other thing is that you spend 95% of your time with any revision control system, just doing basic check in, check out, kind of stuff. So the merging is not usually painful on a daily basis.
CS (01:22:49):
The stuff that sounds hard is not usually done on a daily basis. One of the reasons it's hard is because it's not done often. So the often stuff is easy, and quite frankly, it feels pretty good when you get in this sort of checking it often habit.
CS (01:23:02):
So that's quite the last thought I left you with. It's more than I intended, but there you go.
EW (01:23:07):
No, it was good. It was a nice summary. Thank you for being with us.
CS (01:23:11):
Thank you very much. It was a good time.
EW (01:23:14):
Our guest has been Chris Svec, Senior Principal Software Engineer at iRobot. You can read his "Embedded Software Engineering 101" articles at embedded.fm, and he's going to post a new one very soon.
EW (01:23:29):
It's going to be about C. We're getting out of the world of assembly and microcontrollers. So you should look forward to it.
EW (01:23:37):
And I want to say thank you to our Patreon subscribers for Chris Svec's microphone. Also thank you to my Christopher for co-hosting and producing. And of course thank you for listening.
EW (01:23:48):
I have a final thought to leave you with. "Always remember that it's much easier to apologize than to get permission." Grace Hopper said this. She went on to say, "In this world of computers, the best thing to do is to do it."
EW (01:24:05):
Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.