The home team talks about the past, present, and future of crypto; good reasons to go public with your open-source project before you think you should; and the importance of test-driven development.
Highly-touted cryptocurrencies like TARA don’t always solve the problems they’re supposed to, as Bloomberg reports.
If you’re looking for a compelling deep-dive into a crypto scammer, Cassidy recommends BBC podcast The Missing Cryptoqueen.
Ceora is working to improve the quality of her commit messages in order to turn what’s now a personal project into an open-source project that others can contribute to. One great resource she’s found: Zen and the art of writing good commit messages.
Attention devs: if you have tips for basic project maintenance and hacks for improving commit messages, Ceora wants to hear from you.
Read up on the benefits of test-driven development.
Today’s Lifeboat badge goes to user Nina Scholz for their answer to What’s the difference between Object.entries and Object.keys?.
Ceora Ford So let me preface this by saying, I've been working on a personal project lately since I've been taking a little break from working and all that kind of stuff. And so I've been trying to do better with my commit messages and make them somehow understandable. Because potentially, I would like to make this an open source project that other people can contribute to, so that means that my commit messages have to be semi-good. So it got me thinking about how do you create a good commit message in the first place?
[intro music plays]
Ben Popper All right, everybody. Listen up. I got a good one for you. Gatsby is the fastest front end for the headless web. If your goal is building highly performant, content-rich websites, you need to build with Gatsby. Go to gatsby.dev/stackoverflow to launch your first Gatsby site in minutes and experience the speed. Go on over, support the show. That's gatsby.dev/stackoverflow.
BP Hello, everybody. Welcome to the Stack Overflow Podcast, a place to talk all things software and technology. I am Ben Popper, Director of Content here at Stack Overflow. Apologies for the poor audio quality today. But I am joined as I often am by my wonderful crew of co-hosts, Ryan, Cassidy, and Ceora. Hi, y'all.
CF Hi!
Cassidy Williams Hello!
Ryan Donovan Hey!
BP So let's start off maybe by acknowledging the elephant in the room. Crypto is having a bit of a week. A lot of cool people that I know in my universe went to work at crypto and Web3 companies and I hope that they weather the storm and make something that people find useful. I don't want to admit to the Schadenfreude, but it's hard to look away when things are going this crazy.
CF So wait, what exactly is happening because I didn't get to read through this news article ahead of time.
CW Everything is down, basically. Just all the things are down and people are nervous. But then in some circles, it's a lot of people being like, "If you have the cash, now is the time to buy."
RD The fire is warm. Throw your money on it.
CF I guess it depends on how you're looking at it. I mean, if you want to be glass half full, then maybe it's like, "This is the perfect time to get in on it." I don't know.
RD Yeah. They always say, "Buy the dip."
CF Is there a cause to this? I've heard also that just generally with stock market stuff, everything is pretty low. Not everything, but a lot of things are low right now.
CW Many things, yeah.
CF Yeah. So is this kind of in tandem with that or is there another cause to this?
BP Definitely a part of it is like the macro picture of, people are nervous about the economy, and inflation, and Russia, and China's economy. People are nervous. And also we had a great year. After you have a great year people often can sell their shares and take their profits. So then after you have a great year you have a not so great year. But I would say, the thing that crypto people had always said in the past was, "We're not the stock market. We're different. Buy crypto, not stocks. Invest in this, not that." And now they're all just moving like they're in lock step.
RD And I think the Coinbase news that you posted might get people freaked out. Coinbase announced that you don't actually own the coins that they hold for you. So if they go into bankruptcy you could potentially lose everything.
CF Wait, if Coinbase goes into bankruptcy?
RD Yeah. Coinbase, for the record, is not in danger of going into bankruptcy. But...
BP Right. And again, as Cassidy has pointed out before about reinventing the wheel, it's like, wasn't this the problem it was supposed to solve, that everybody owns their own stuff and it’s a decentralized network?
CW Right. That's the whole point.
BP And then everyone was like, "Well, I can't make a good mobile app. Coinbase, can you make a good mobile app? Okay, you're in charge now. Here's all our crypto."
CW Right. And that's exactly it. That being a problem means that it's centralized, which is not decentralized, which is the whole antithesis of crypto things.
BP Back to square one. Exactly.
CF We've talked about this so many times. I'm honestly very sad that this is happening though. I'm sure this isn't true, but I hope not too many people are losing a ton of money. I know a lot of people have used this as their primary form of investment, and that makes me nervous that some people are losing out on a lot of money that could be life-changing in a negative way. And that makes me scared. I don't like that too much.
CW A friend of mine jokingly tweeted, she said, "I'm not buying low right now because all of my money is already in crypto, therefore I have no more money to buy low with."
RD Yeah. I mean, I think this is sort of a symptom of crypto being a newer financial product, because they don't have a way to have sub-accounts. I mean, maybe they do, I don't know. But it seems like the way they had to do it was to put it in a wallet. If a single entity is buying this crypto coin, they have to control the wallet.
BP Yeah. I also think there was a lot of hype around it and a lot of enthusiasm and now there's a bit of a comeuppance of just like, is this fifteenth new coin that I got actually also going to be the one? Is this seventeenth NFT that I minted from an artist who will be important in a hundred years? Again, I'm not trying to wish ill on anybody. I'm not trying to take pleasure in this, but we did talk a lot on the way up here about whether this was hype or substance and [inaudible]. And we have to talk about it because so many people in this profession of software engineering and developer relations and people I know working in marketing have gone to these companies. The amount of venture capital for that, we can't not talk about its impact on the industry.
CF Yeah. I really hope the blowout isn't too big. I hope that the impact isn't too big and too negative because I know quite a few people who have not only invested a lot in crypto, but like you mentioned, gone to work at these different companies.
CW Right. They've invested their time and career, not just money.
CF Yeah. And that could be terrible. I would hate for this to go really, really badly. I mean, we had an episode as well where we talked about like the great migration of a bunch of tech workers across different professions and disciplines moving to crypto companies or Web3 companies. So I just hope that we can weather this storm and come out of this in one piece.
BP Yes, agreed.
RD Well it's the hot new technology and hot new technologies don't always pan out.
CF Yeah.
CW Right. There's a podcast that I listened to recently. I don't know if any of you have heard of OneCoin. The podcast was called The Missing Crypto Queen. Highly recommend checking it out. It's a short form podcast that the BBC produced. I think it's like eight episodes, ten episodes and that's it. And it came out I think a little bit before the pandemic. But it basically follows this company that tried to be a crypto company and take on Bitcoin and change crypto forever, basically. And then the more people dug into it, and even though thousands and thousands and thousands of people were investing in it, it ended up being a scam. It was a fascinating look into the research of how it hit its heyday and then started to go downhill and up again and down again. And it talked about the psychology of investing in it and also just the technology behind it too. And I highly recommend checking it out. I just finished listening to that one.
BP Sweet. I guess the other thing that came out in sort of this wash that you're talking about, like scam or not scam, real or not real, was perhaps the end of one of the most popular stablecoins, Terra. The whole idea there was like, "We built this algorithm. We have the smarts, the software, the math. One Terra will always be worth $1." And now they're just rapidly falling away from one another. So it'll be interesting just to see if that can hold and to see how robust the system is. I mean, one of the things that somebody said to me recently that I thought really clarified my thinking was to imagine the internet in 1996. You dial up, you can't get through, you get a busy signal. It's too slow to be worthwhile. It's too expensive. It's glitchy. Like, okay, Web 3.0 is like the internet in 1996. And I actually went and looked it up, the dot-com bust wiped out something like $5 trillion worth of stock market value. So we've seen this kind of buildup and blow up before. I'm not even sure crypto has blown up as much money as dot-com did, adjusted for the time. So it'll be interesting to see what happens next.
CF Yeah, I think I discovered what the dot-com bubble was a little while ago while I was researching what crypto was. And like you said, I think it's just a natural progression for most newer technologies. At first it's super interesting. Everyone wants to get in on it. And then it goes through some turbulence and only the strongest few come out the other side. Even for a while, machine learning and AI were huge, and there were companies starting out that their whole thing was supposed to be machine learning and AI, and how many of those have lasted up until now? So it's just a natural progression. I just hate to see people get messed up in the process. Just like what happened with the dot-com bubble. There were tons of people who didn't make it through that, or who made it through, but barely.
RD I mean, that's the nature of risk though if you're betting on something new. The folks who invested in pets.com probably lost their shirts, but amazon.com came out around the same time and they have many shirts now.
BP Right. Shirts per sale. Yeah, I think that's right. And one interesting thing, Ceora, to your point, is that I remember talking with Paul and Sarah and other folks who got laid off during the dot-com bust. It was not easy then for a software developer to turn around and find another job. Jobs kind of dried up for a few years there. That's not the case now, thankfully. People might get laid off, but luckily there are still many other companies in other areas of software or technology. Just every industry now needs developers of some kind that you could hopefully find a good place to land on your feet.
CF So we have more hope this time around.
BP We have a little more hope. Ceora, do you want to bring us to your topic, AKA your project? AKA let’s help you out.
CF Sure! So let me preface this by saying I've been working on a personal project lately since I've been taking a little break from working and all that kind of stuff. And so, I've been trying to do better with my commit messages and make them somehow understandable. Because potentially, I would like to make this an open source project that other people can contribute to, so that means that my commit messages have to be semi-good. So it got me thinking about how do you create a good commit message in the first place? And I came across this article, it's called ‘Zen and the Art of Writing Good Commit Messages.’ It's pretty short and kind of goes over principles that I knew of but wasn't really following. I'll just explain what usually happens to me when I'm working on my project. I'll do a bunch of stuff and then remember, “Oh, I forgot to commit,” and then I'll try to do a commit. And then it'll be something stupid like, “I just built this feature,” and then push that to GitHub, when honestly it's better to do commits frequently that kind of explain what's going on so that people who potentially want to also contribute, or even like your teammates who are working on the same thing as you, can have an idea of what's going on. So I just wanted to hear out. We have some developers in the room now so I wanted to hear if you have any tips or tricks when you’re doing Git commit messages or even just basic project maintenance when it comes to your project and maintaining it on Git and GitHub and stuff. Give me your tips. I need them desperately.
CW So first of all, I do the exact same thing where sometimes on personal projects I go in deep and then after a while I'm like, “Oh no, I haven't committed in a long time.” So I will say whenever that happens, I at least try to break up the files where I'll say, “Updated the CSS to get to this point, updated these components specifically,” and at least break up the file. So it's still probably not best practice because you want to get a timestamp over time rather than just like, “This file was really hardcore updated,” and that was it. But that's typically what I do. And honestly I do occasionally just set a timer where if the timer goes off when I'm deep in a coding session, I'll be just like, “Oh actually, should I commit right now? Or do I want to finish X, Y or Z?” Just to keep that in my mind, because it is such a good practice to do that, especially if you break something. Because if you break something and then you can't figure out how to go back and it's been so long since you've committed something, that is just a headache waiting to happen.
BP This is embarrassing, but I used to set a timer to save my game on especially hard ones so I wouldn't get far and then not have saved and have to go all the way back.
RD Yeah. We published something recently from this guy Mark Seemann who talked about using commits as save points and using Git tactically to do the sort of smallest possible code change and then saving and then saving and saving. And you have this full record of working code along the way,
CW Right. It's kind of like if you are playing a game and you know a final boss is coming at some point, you save along the way because you’re just like, “I've survived this long,” and you keep going. It's a very similar concept, I think. And then also in terms of just Git management and just your repository management and stuff. First of all, we talked a little bit about this in an earlier episode that I did with Matt where we were just talking about open source in general. First of all, you should make it public before you think you should. People, chances are, aren't going to be skimming through your code. Ceora’s making a face on that. But you should just make it public. It's okay. But also as you work on features, treat it as if you are maintaining a public project anyway. When I have my own projects, for example, something that is something that I need to get better at, but what you can do is, for every feature that you want to do, everything you want to make, just create issues for yourself. Because then, every time that you want to finish something or get certain components, or pages, or aspects of your application done, if it's tied to an issue, that kind of reminds you to commit as well, because then every time you make a little bit of progress you're like, “Ooh, I can check that off,” and it's kind of like checking something off of your to-do list, but it's an actual issue where there's a record attached to it. And that way you can also make notes for yourself as well. Because sometimes, especially on your own personal projects, you might just have a ton of to-dos in comments in your code. It's very common. Ceora, your face. I love how expressive you are. But if you put it in an issue, then that's where those kinds of notes can live so that way your code stays clean.
RD Yeah. And as somebody who has written documentation, I have absolutely gone through issues and PR comments to try to figure out what a checkbox does. So you're creating a historical record that archivists of the future will dig through and try to figure out how this works.
CF That's a good tip. I had actually tweeted something where I was like, “Can someone help me to remember to commit often?” And someone suggested, I'm going to read this comment verbatim because I don't want to mess any of the terminology up. But they said as you add more tests, as they pass locally, you will soon want to see them run past as part of your commit or the build pipeline. I don't know what that means.
CW I'm ready to talk about this!
CF Yeah, please do!
CW Test-driven development is so fun and it's something that I think is much easier to do for backend development than front end, but it's still something that's awesome and something that I’ve done especially back in the dark days where I was a backend developer. I would write all of the tests that I wanted to pass before I actually built the features. For example, way back in the day when I was working at Venmo, I was part of the team that implemented blocking in Venmo where you could block someone on the account. So we would write all these tests like, “Okay, does this person appear in someone's feed when you've blocked them? Are they able to make a payment? Are they able to make a charge request, or various different things?” At first, all of those tests failed because blocking wasn’t implemented. But as we slowly implemented the feature, those tests started to turn green over time, and then you could make a commit message every single time a test turns green. And you can do similar things with front end development, it's just a bit harder because it tends to be visual and where you would probably want to have unit tests more than integration tests for it. But it's a great way to once again have those check marks where every time something passes or changes, you can push it and have it committed.
CF You know what? I've been thinking a lot about test-driven development. Actually, I've heard a lot of people mention it and talk about it and stuff. And as the resident junior developer who represents all junior developers on this podcast, it seems like the normal progression as a developer is to be like, “You know what? I should probably actually dedicate some time to learning more about test-driven development.” And I actually had an interview recently where I was doing the code in front of somebody else, which was really nerve wracking. And then the interviewer asked me, “What are some use cases you should test for to see if this code will work?” And it just got me thinking that that's probably the normal thing to do when you're coding, is to think about, “Okay, what could break this code?” Especially if you're building something that users are going to interact with. If you have some open source project or you're actually contributing to code for a product that people have to use, it's probably important that you think about, “How could someone break this and ruin my day so that I have to fix it?”
RD It's also probably good to just think about how your users are going to use it.
CW Because they will be wrong at some point.
RD They'll do some dumb stuff.
CF Yeah. And of course I think it's intuitive because I built the thing. Of course it's going to make sense to me. But I'm actually working on something that hopefully will become something that people actually use. We'll see. But as I was coding it and stuff, I'm like, “Ah, you know what? The people who are using this probably aren't going to be super technical and think the way that I do or that other developers do. What are some of the ways that they're going to use this and it be not what I think would be the right way to use this, and how can I build for those use cases?” It feels like test-driven development is like thinking along those lines. I wouldn't know though, I've never done test-driven development. So you tell me.
CW So there's something that I did ages ago, like truly a decade ago. I went to this workshop for understanding the concept of test-driven development, and what they did was they said, “Okay, by the end of this we're going to write a function that just returns Fibonacci numbers. But we don't want you to write this at all. Let's write what we expect first.” And so it wasn't proper testing or anything, but it was just saying, let's just say the function's called Fibonacci, “If you do Fibonacci-0, you'd want zero elements to be returned. What should be returned? Nothing. Okay. What about Fibonacci-1? What do you expect to be returned?” And we would write a few different functions of what we would expect our Fibonacci function to do, and then we would start to build our Fibonacci function later to specifically return those values, just for the individual test cases. So don't over-optimize at all, we just solve the first one first where it returns nothing. So we did like, “If there's nothing in here, if it just is a zero, we return nothing.” “Okay, if it wants 1, we want this.” And then over time if you want to keep having the earlier tests pass, you have to start to optimize your code a little bit more. And it was a really good exercise. And there's this one game that I want to share called Elevator Saga. This was very viral back in the day. I know it still exists, but if you go to play.elevatorsaga.com, what it is is basically a tester for that kind of test-driven development in a way where you just solve base cases first and it gets more complicated. So the first thing is just to transport 15 people in an elevator in 60 seconds or less. And there's like a little JavaScript API where you're just like, “Okay, I just want to go to floors 0, 1, and 2,” and you can just make the elevator go up and down and that's fine. But then it gets more complex. You might have multiple cars and you can kind of optimize your code over time. And it's a really good exercise in this way of thinking and I highly recommend playing it.
CF I should try that out. I definitely need it.
BP I have a question for Cassidy and Ryan. So we were comparing it to doing a save game. One of the things that kind of irks me when I'm doing a save is, once I have too many then I can get lost. I don't know where I wanted to start again and naming conventions aren't good. I kind of forget, like, “Why did I call it this again?” And I feel like it's the same with when you're leaving notes for yourself. So is there a balance that you want to strike there of not over-annotating? Ryan, like you were saying, it's great when I have this historical archive, maybe for a technical writer it is. But Cassidy or Ceora, from the point of going in and looking at a codebase, do you ever get overwhelmed by someone who's just left a million annotations?
CW Constantly.
CF I don't think I've come across that before, honestly. Cassidy, you probably have more experience with this kind of thing.
CW I have. Something that's particularly useful that I've seen a lot of teams do and my company does that right now too. They basically do squash commits, where whenever you are about to work on a big feature, let's just say we're making the elevator component or whatever. For this pull request, we're going to push all of our commits specifically to this branch where it's saying, “Okay, we're creating an elevator car. Now there's two elevator cars. We're making it pass these tests and these tests.” You do all of your commits, whether they're spammy or not, into this one branch, but then when you want to actually merge it into the main trunk of the entire repository, you do what's called a squash commit where it just squishes all of your commits together into one mega commit into the repository. So if you ever want to see all of the granular stuff, you can go to that branch, you can go to that PR and see what the individual steps were. But in your main history, it's just the features that are in the commit history.
RD I've seen that too, where it's just one PR per JIRA issue, basically.
BP Yeah, that makes sense. So you're bundling them and then there's a little index you can expand if you want to dive deeper.
CW Right, exactly. Because sometimes you do have just a stupid commit where it's just like, “I forgot a semi-colon or this little space right here.” You don't need that in your big mega project of commits so that's where squish commits can be handy.
CF Have you ever come across a codebase that's overly commented? I feel like most of the time I see code that doesn't have enough comments that explain what's going on. But one thing for me is that I always try to make sure for the main branch that the comments probably don't need to be there, not they don't need to be there, but the comments that are like, “I don't know what's going on here. I need to fix this later.” That doesn't need to be on the main branch, you know? But have you ever come across anything where you're like, “Maybe you should clean up the comments here a little bit more.”
CW I have particularly with students or folks on internships, but I don't want to blame them for it. It's a good thing to know what you're doing. But sometimes the comments are just really granular where it's just like, “This is an if statement that checks if this variable is true.” I can see that in the code. I don't necessarily need that to be commented. And I understand because they're trying to learn best practices and I have been that student doing that. But I think over time you start to realize, “Okay, these are the kinds of things that need to be commented.” Something that's not immediately obvious, something where it's like, “I'm not sure what's going on here but I'm leaving a note for anybody who tries to refactor it later,” that kind of stuff. I've seen that and I think those comments are good. It's when it's commenting very granularly, basically the pseudo-code of what the next line is doing is when it's a little over the top.
CF That's so funny. Okay, good to know. I'll keep that in mind while I'm working on my project.
[music plays]
RD As we often do, we shout out a lifeboat badge. Today's lifeboat goes to Nina Scholz for their answer to, “What's the difference between Object.entries and Object.keys?” So if you're interested, we'll drop that in the show notes and you can check it out.
CW That's a great question, too. That's an actual interview question I've had before.
BP We're here to help you progress in your career by dropping interview questions in. Alright, everybody I am Ben Popper, Director of Content here at Stack Overflow. Apologies again for my audio. You can always find me @BenPopper on Twitter. You can always email us, podcast@stackoverflow.com, we'll shout you out. And if you like the show, leave us a rating and a review. And I am getting my first 3D printer. It's on the way. I went ahead and bit the bullet. Let me see if I can find which one it is. It's called the Creality 3D Ender 3 Pro. So it was kind of an entry-level model.
CW That's a nice one, though.
BP It got five stars. It wasn't very expensive. So I can try it out and see if I like it.
CF Cool. That's exciting!
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find me on Twitter @RThorDonovan. And if you have a great idea for a blog post, you can email us at pitches@stackoverflow.com. And I have a rec. I like language learning, and my favorite language learning app is this one called Lingq.com. It does full text and you can highlight words and create little flashcards from them and then test yourself on them. It's very good.
CF Cool. I’ll have to check that out. Awesome. My name is Ceora Ford. I'm a developer advocate at nowhere. I love saying that so much! But if you're interested in hearing more from me, you can find me on Twitter. I spend the most time there online, and my username there is @Ceeoreo_. I don't have a tech rec this time, so I'm just going to pass it on to Cassidy.
CW Hello, everybody. I'm Cassidy. My tech rec for the week is Elevator Saga. It is an older game, but it still teaches you so much. I don't think I've ever gotten past level seven. So try to beat me. You can find me @Cassidoo on most things.
BP Wonderful. And yes, shout out to JJ Asghar, a developer advocate over at the IBM Cloud team, who broke 500 rep on Stack Overflow and wanted to let us know. JJ, thank you for contributing that much to the community, we appreciate it. All right, everybody. Thanks for listening and we will talk to you soon.
[outro music plays]