The question was not answered.

“Don’t’ except if you want or need to” is not an answer to “how do I …?”

Presumably the person asking the question is at the point where they want or need to share code. Why not tell them the best or preferred ways of doing it?

Also the entire attitude seemed weird to me.

Don’t share code with yourself. Don’t share code with others. Don’t create packages for others. Don’t use other’s packages. Just dump everything into main package. Don’t follow best practices. Don’t listen to people with more experience than you. Don’t take advice from thought leaders. Don’t follow prevailing practices in the community.

Except if you want or need to……

Really?

Big thumbs down on this episode. Do another one where the question is actually answered and also tell us how to do all of that when we decide we need or want to do it.

Just listened to this episode and had immediately some thoughts that I would like to share. First, thank you for taking on this kind of more general topic on coding. I have the feeling, go time sometimes becomes just code time, if you know what I mean. Go really seems to be this down-to-earth language, all about functionality. With myself being more on the go-curious side, coming mainly from Java and Spring, go reminds me of what coding is actually about - functionality, managing structure to get the job done and keeping the right things the right amount maintainable; as opposed to wrangling with leaky abstractions of some framework.

One critique, the title might be a bit misleading or clickbaity as fears of overengineering summarizes the episode better, I guess.
From my experience, both with a codebase slowly growing for over 10 years and another one just 14 months old, focused on fast iteration, the is one big issue with reusability. And that is discoverability. It applies to other experienced coworkers, new devs and even yourself from the future, probably just two weeks from now. Though this problem is also a cultural and an organizational one, I always felt a big burden in discovering, communicating or extending parts laid out to be reused.