Crafting Code Podcast: Recent Episodes
Crafting Code Podcast
A podcast about crafting software where we discuss the importance of doing the right thing, at the right time, with the right tools.
The need to learn is taken as a necessity in our industry. And yet, most who write code spend almost all their time in performance mode and very little in learning mode. We are delighted to have special guest Steven Diamante join us to talk about this topic. We discuss the importance of learning on your own and in groups, and talk about ways to improve learning outcomes in our training meetings.
The effort required to author a good book can lead to a depth of understanding that doesn't come as readily to other mediums. And when a good book stands the test of time, it's worth sharing. In this episode, Dave and Allan share our recommendations for books we think are worth reading if you are serious about software. We grouped these recommendations into some categories from generally applicable to most developers to the more specialized deep-dives.
Applying Conway's famous Law tells us that software architecture and culture are intertwined. How people communicate affects how they architect their software. And the reverse is also true: being intentional about an architecture can change how people behave. In this episode, your hosts discuss this hidden coupling and how important it is to align the two.
The culture of your company has a big influence on how much you enjoy your job. Unfortunately, finding one that fits just right for your unique combination of people is hard. On top of that, there are inevitably subcultures within the larger organization. In this episode, Dave and Allan discuss things we've valued in company cultures, things we watch out for, and some ideas on being intentional in influencing a culture.
We often hear stories from successful companies shared across the industry, but usually what they did to succeed doesn't work for us. Are there principles that are independent of the organizations that we work at? Coda Hale thinks there are. In this episode we review the article, 'Work is Work' which you can read at https://codahale.com/work-is-work/
Why is asking questions such an important soft skill for software developers? Is a mindset of inquiry a way to learn more and engage in better, open communication? How can we utilize questions during retrospectives and blameless postmortems? Can questions be an important teaching tool? Will you learn more about asking questions by listening to this episode?
In the physical world we readily intuit how context matters in decision making. For example, a compact car is a perfectly fine vehicle, but may not be suitable for hauling a large load. Context informing software decisions may be even more important, since it isn't as obvious. In this episode, your hosts discuss the need for context and values as we look at 'best' practices, non-functional requirements, and patterns.
In episode 29 we discussed ways that a software developer can make an impact in their job. In this episode, we reflect on what things have made the most impact on Dave and Allan as software developers. We share experiences, books, presentations, people, and practices which have made a significant difference in our careers. Our hope is that you'll hear something that helps you in your career.
AI is a hot topic in tech these days, and usually people are talking about LLMs. Are they really going to be replacing programmers? Or are they just the latest fad in a long line of promises to replace those pesky coders? In this episode, Allan and Dave talk about out experiences with AI code assistants and how tools tend to slowly evolve how we work rather than fundamentally overthrow it.
The concept of clean code is one that Dave and Allan feel is very important. But sometimes we hear or read of people saying it is unimportant or unnecessary in some cases. In this episode, we explain what we mean by 'clean code' and why we think it really matters. After all, it's exponentially easier to make a mess than it is to keep things clean.
What does a software architect actually do? The answer will vary widely depending on the company you work at. But generally speaking, we've found that there are two main things every architect is expected to do: make decisions and draw diagrams. So in this episode, your hosts discuss tools and strategies they've used to successfully deliver on those two expectations. We value clarity in communication over being overly specific; after all, every diagram is wrong and a 1:1 scale map is pretty useless.
How can I make a difference? What should I be doing in my role? These are pretty common questions software developers ask themselves, even after many years of experience. In this episode, we discuss how to make a difference (and some of the struggles we encounter) at various sizes of business. We also talk a little bit about career paths or specializations. Whether you're in a small team or a large enterprise environment, we hope you'll find something that resonates with you.
The change of perspective which comes from reframing a problem can often yield fresh insights or improve our outlook. Discussing the state of a technical system in terms of health may be preferable to the oft-used debt metaphor. In this episode, your hosts discuss how this shift in thinking can help us deal with our software issues, and then we share some ideas which have helped us communicate and manage technical health.
Is the mythical 10x developer real? We think so... at least inasmuch as some people regularly improve the systems they work in until they (and often their team) are far more productive. We've definitely experienced 10x systems. So join Allan and Dave in the search for this cryptid through the economic principles and interconnected practices it calls home.
Constraints make great engineering. They aren't always a bad thing, and understanding them can help you make better coding decisions. In this episode, Dave and Allan discuss many different common constraints. Some are more obvious like technology, time, and budget. Others are easily missed but still useful: people, org charts, and culture.
Bits do not rot when left alone, but the world around the code changes. Over time, although the code itself has not changed, the value provided by it will effectively rot away. In this episode, your hosts talk explore this topic; from video games and antiquated coding paradigms to the Red Queen hypothesis and software gardening.
Are we unintentionally doing things which reward bad behavior? Sometimes company policies incentivize people to do the wrong thing, like coming to work sick because they've run out of sick days. Although we rarely have control over company policies, we can look for ways that our teams reward bad behaviors. In this episode, Dave and Allan share some examples of bad behaviors we've seen, in the hope that we can influence our teams, managers, and companies to think about what we incentivize and how we might act differently.
Technical debt is a metaphor which is thrown around a lot, but what is is really? In this episode, Dave and Allan discuss the metaphor and how well it holds up when compared to financial debt. Regardless of the name, we have to spend time and money addressing this unavoidable, perennial problem. So what can we do about it?
Software frameworks are so useful we can hardly imagine working without them. Yet they have an insidious tendency to invade, corrupt, and wrest control away from us. In this episode, your hosts discuss the good and bad of frameworks and offer some suggestions for keeping them at arm's length.
In this episode, your hosts (finally!) share some actual code examples to illustrate some of our thoughts about crafting code. Follow along with the code at https://github.com/crafting-code-podcast/crafting-katas as we discuss how we implemented Conway's Game of Life in multiple languages. Testing strategies, optimizations, and feedback loops all demonstrate that crafting code is ultimately an iterative process.
The works of Edsger W. Dijkstra have made a huge impact on the software industry. In this episode, your hosts dive into his paper, The Humble Programmer ( https://dl.acm.org/doi/pdf/10.1145/355604.361591?download=true ), to discuss how well it holds up to today's programming world. We cover hardware, cleverness, abstraction, proofs, and more. Even when we disagree with his specifics, we find ourselves still nodding in general agreement.
There are many benefits to having communities of practice, so long as the community continues to exist. In this episode, special guests Jon Turner and Neil Sorensen discuss what they've learned over their many years attending and facilitating the Utah Software Craftsmanship group (http://utahsc.org/).
Will using simple tools help you keep your codebase simple? In this episode, your hosts try to draw a distinction between simplicity and ease, then examine how they apply to the tools we use to write code. Unfortunately, simplicity and complexity depend on what level of abstraction you're working at. Sometimes we choose to trade simplicity for easiness, or visa-versa. And maybe there are some simple tools that make your coding life both difficult and complex!
Programming languages are the tools we use to craft code. They have philosophies, environments, ecosystems, and idioms to consider. Picking which languages to use is an important choice for individuals and businesses. Although we all have likes and dislikes, perhaps sometimes we have to leave behind our code baggage to learn something new. But remember most of all: programming is fun!
Software architectures are generally described in broad strokes that make them generally applicable and easier to understand. But this is a lossy process. Whether or not an architecture is good or bad depends on context. So in this episode, Matt, Dave, and Allan share some examples of systems we've worked in to help illustrate architectural decisions.
Starting a new job can be a nerve-wracking experience. There's a lot to learn if you are going to be effective in your new position. Sometimes change is forced upon you, but there are reasons to voluntarily start over. It can be an important part of our personal or career journey.
Despite the near-universal agreement of the importance of software architecture, it is very difficult to define. In this episode, your hosts share what we've learned from holding the architect role (and title) at various companies. For us, the crux of it comes down to figuring out how to deliver technical value for changing business needs over time.
What does it mean to be a full-stack developer as opposed to front- or back-end? Is anyone really full-stack? Is it a reflection of who you are, or is it more about how your company chooses to operate? Whether or not you have a preference for the part of the stack you work in, there is value to expanding your understanding and collaboration.
Mistakes are inevitable. In this episode, your hosts share some of the lessons we've learned the hard way through the mistakes we've made. Our hope is that some of you may be able to avoid making these same mistakes. But if not, at least know you're not alone and we can all improve.
What do you need to know to be a successful software developer? No matter your path into writing software, there are some things you ought to learn. Unfortunately, formal education doesn't teach us all we need to know, and even worse: sometimes even teaches us the wrong things!
Humans communicate through stories. That includes the ones writing code. The folklore of your team teaches you about your history (the hows and whys that got you here) and your ambitions for the future. In this episode, Dave and Allan (sans Matt) discuss the storytelling element of teams.
Coupling and cohesion are fundamental concepts in software systems. From types of coupling to Conway's Law, Matt and Allan (sans Dave) discuss how these two ideas can affect your day to day work beyond just the formal definitions.
TDD is one of the most powerful, professional practices we are aware of for designing code. It provides a consistent way to make sure you solve the problem at hand while naturally improving your code quality. This episode takes a deep dive into your hosts' thoughts on the practice.
Communities of professionals don't just spring into being on their own. In this episode we welcome a special guest, Mike Clement, to talk with us about his experiences in starting and building communities. Meeting with a group of kindred spirits can make a huge difference in your career.
A professional doesn't just write code, they also know when to delete it. In this episode, we discuss the problems that code can cause and share some ideas on how to go about making your codebase smaller.
Practice is key to learning and developing skills. It provides us fast feedback and allows us to fail in safe efforts which can be reversed or thrown away. Playing in code can motivate us and our teams to improve, creating outcomes that employers desire.
What does it mean for a software team to be effective? What sorts of things can you do to increase your effectiveness as a team? In this episode, we discuss the principles and practices which we have seen in common among effective teams.
Coding is a specialized skill where we learn to communicate with a machine. Unfortunately, this can often blind us to the fact that crafting code involves a lot of communication with humans. Writing clean, expressive code communicates with other coders. Communicating well with non-coders helps us understand business needs so we can write the right code.
Failing projects are the bane of a software developer. In this episode, we discuss how principles of crafting software can rescue a failing project. Whether the problem is rooted in the code, the team, or the system, we can improve our feedback loops, make small but significant improvements, and focus on finishing instead of starting. Slowly but surely, the project can turn around.
What does it mean to craft software? In this first episode, your hosts David Adsit, Matt Baker, and Allan Stewart discuss what we think software craftsmanship is all about. We cover how crafting code helps you find better ways of doing things, steadily add value, and build a community of professionals. We also talk about how this craft is not about art as an expression or perfectionism; nor is it about elitism or exclusion.