Ep 114: Brand New, Again

Functional Design in Clojure

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to [email protected], or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "what's old is new again". We find ourselves staring at code for the first time—even though we wrote some of it!

Our discussion includes:

• Christoph re-opened his own code base after 14 months!
• Nate joined a software team with a large, legacy code base.
• Why does the problem of "fresh eyes" matter so much?
• How is my past self going to treat me?
• Are the past teammates going to help me?
• Why you shouldn't rely on memory.
• What's involved in really understanding a code base in order to make a change?
• The frustration of being unproductive.
• How is an app put together?
• What's the flow of information?
• How do you really know if your code is comprehensible?

Selected quotes

It's always fun to start something new. You don't have to worry about all those other things from the past!

I was a little nervous about that other guy who made all the code: me fourteen months ago! I wasn't sure how good of a teammate he was going to be.

The word "legacy" is like a big bad word, but I feel like it should be a badge of honor! It's software that is running right now and paying your salary! You should have a reverence for code that exists and is running.

At some point in time, you or a new team member, is diving into a code base with fresh eyes. It brings up so many important issues that we face as developers.

We spend so much time reading code and forming mental models about what is going on.

A fundamental challenge in software development is understanding, comprehending and reasoning about the code base.

Comprehending and reasoning about the code is one of the primary drivers behind the "why" of a lot of the so-called "best practices" of the industry. Why do you write tests? Why do you write documentation? Why do you try to have a good design in your application?

There's this constant learning that we have to do, and so try to make that easier.

He moved on to better projects in the sky. We've lost him to a better project in the Cloud. He moved to a better project upstate!

It's easy to say: "We have great documentation! Our code is super readable! Decoupled? Absolutely! Our pure data models? Totally comprehensible!" It's easy to say that, but you really find out if those things are true when somebody new joins the team or when you have to revisit the code after a long time.

Always trying to teach someone else about your code. There's always some future person.

What can we do now as we're setting up the situation for new people in the future?