Why should you throw away all of your code?
You should throw away your code and try again, because it will make you a better programmer to try the same problem multiple times. Each time you can try a new style or approach to solving it. That's how you get better.
Eric Normand: Why should you throw away all of your code? Hi, my name is Eric Normand, and I help people thrive with functional programming. I've been thinking about ways to advise people to get better at functional programming, to be able to create more concise and expressive pieces of code.
So many people say all the time like, "How did you think to do that?" Here's the thing. My main advice is to code the same thing several times in different ways. The first time you code it, you're probably just figuring out all the details, how it's supposed to work. Make sure you handle all the cases, like null and stuff.
You're not getting it that right. You'll get it working, but it's not going to be beautiful and elegant, just like your first draft of an essay you have to write in school or anything like that. You've got to do multiple drafts to get it good.
You try again. You code golf it a little. What if I used a different data structure? What if I used this other function that's built in? What if I did it with this, changed the order of arguments? Does that make things feel better? You just have to give it some love, a little TLC. See if you can figure out a better way. Sometimes though, you just need to throw away the code and start over.
What happens...It's symptomatic of digital media. We tend to not want to throw stuff away. We feel like we've invested time in this thing, and we want to make edits to it to get it good instead of throwing it away.
I feel like that is something that happens with digital media. If I write, let's say an article, some essay in a Google doc, I'll never just say, "OK, delete it all," and start over, but I will often write on a piece of paper.
When I write on paper, I'll crumple it up and say, "That's trash," and start over. Why is it that I'm so reluctant to do it when it's digital? I think that there's something about that.
That might be good advice. Try it on paper. Write it out on paper. If not, you don't need to go to paper, but delete it. Start over. That first draft was all about learning. It's a prototype. You figured out all the problems. Now, start over. Start over but with all this learning so you're not influenced by the code you already have. Start again. Start fresh.
That's one of the benefits that we have of functional programming, is that things are so easy to write. Things are so short. Compared to other languages, other paradigms, we have plenty of extra time because it's so quick to write.
Use that extra time to try a couple more variations. It's that experimentation that will build up your skill and expression in being concise. The more you do that, the more you'll get better the first time you do it.
You'll still need to do this. You probably could make it a life-long practice where you keep getting better over time by continually doing it even though you're well past your peers in how well you write the first time.
Of course, there's going to be times when you don't really have time. Of course, you're under a strict deadline. Getting it right, getting it working is good enough. When you do have time, don't even think of it as refactoring. Just think of it as trying it out in a different way.
It's what code Codas are all about. This is not just the functional programming thing. They talk about the same thing in other paradigms. Just practice coding. Very often, those Codas, you do the same one over and over because you have already figured out all the problems. Now, the practice is in exploring the different ways you could implement it.
That's been my thought on functional programming. I'm Eric Normand. You can find all of the other thoughts, the other episodes at lispcast.com/podcast. Besides the links to the episodes, you'll find links to subscribe and to find me on social media. On the site/podcast, there are text, video, and audio versions of all of these episodes.
Please get in touch with me if you have any questions or any comments. I love to learn about...When people disagree with me, often, it's just something I said wrong, a misunderstanding. I love to hear about those. They give me great ideas for future thoughts, future episodes. Cool. My name is Eric Normand. This has been my thought. Rock on.