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.