I've been playing around in PICO-8, working on some generative art ideas. Lua is a fun little language that feels a lot like something between BASIC and JavaScript. Lua isn't my favourite language, but it's fun at the small scale. PICO-8, however, is a fantastic little game engine (or “Fantasy Console”) that has all of the feels of the 80s.

First tests

I started with a Minecraft style terrain generator, but as 2D tyles:

It was a fun attempt and performed reasonably well that I filed away under maybe later.

My second attempt was a stamp generation tool, that defines some simple verbs and nouns for generating art, and applies it to coloured tiles:

The third test evolves on the previous and improves the performance significantly:

I'm working on taking the basic concepts from these tests and building a Swift/iOS version that adds some interactivity. We'll see how that goes!

#pico8 #weblog

I set up a new dev laptop for myself over the Christmas holidays. I took the opportunity to burn down my old environment and to survey the 2021 tool landscape, which included testing out various terminals and setups, editors, and fonts. This year I discovered Fira Code, a tidy little monospace font that supports ligatures.

Ligatures are two or more letters (or graphemes) that can be combined to make a single glyph. The result of combining letters into these ligatures can make complex syntax a bit easier to read, especially if you are familiar with the notations the concepts are based on.

Fira Code in Nova

Fira Code has installation instructions for most platforms, though be aware that most editors have additional requirements to enable the automatic display of ligatures.


2010 has come and gone. I've shipped a few projects, each a number of times. I've registered dozens of domain names and dropped a few of the older ones. I've started (but not finished) a dozen spare time projects. I've had hundreds of new ideas, and a few of them were even interesting. I've learned a lot, but not enough (it's never enough). I've expanded my horizons and gotten stuck in ruts. I've gained weight and I've lost weight.

But in the end none of that matters. The real question is, what have I learned?

I'm overworked.

I don't like it, I have a choice, and yet I do it anyway? WTF? Working as much as I do gets less done with poorer quality. The prolonged, unproductive stress is a quick path to burnout and apathy, both of which are the enemy.

There are holes in my knowledge and experience.

I need to spend time learning around the stuff I work on every day, and study things I haven't used for a while. I must grok more. I must not rush past the details I don't need now, as I'm missing out on a universe of useful things.

I don't contribute enough.

I need to get involved in a more recent OSS project and post more of my personal stuff to Github. I also need to get back to teaching programming.

I need focus.

Simpler, polished, less fat, and finished. I need to pick fewer projects and complete them, while still taking time to play with new ideas. New ideas are handy for learning new things, and polish and shipping develop my endurance. A lot of what I need to learn is how to say, “No, but ...” more tactfully. And sometimes I just need to say, “Fuck off.”

I need to breathe in as much as I breathe out.

The rate I make stuff has to be met with feeding my inner maker, and the pace of both needs to be tempered with rest and exercise. Wax on, wax off.

Me time.

I get a lot done when reflecting and day dreaming. Even taking the time for a long lunch is a good investment. I need to slow the fuck down and feed myself and my muse. Skipping lunch to work? Why do I do this?

Great tools really matter.

They're the difference between a bloody knuckle and a perfect build. Why did I spend so long using crappy commodity hardware and fix-it-yourself software and systems? I must continue to hunt down and use good tools, stepping around the piles of shit that are out there.

Great people matter even more than great tools.

People are multipliers, and I need to work with the people who are both positive numbers and much greater than one.

I am wrong more than I'm right.

The real trick is learning to figure out which is which. Take commuting for example, it sucks a lot less than I remembered. In fact, I really enjoy it. Remembering that I'm wrong makes it possible to see it when I am.

And over everything else, don't lose the passion.

I love the rush I get when I finally grok something interesting, the insane joy of starting a new design, the comfort I find in crafting software the right way, and the feeling I get when I finally ship something.


“A common example is process as proxy. Good process serves you so you > can serve customers. But if you're not watchful, the process can > become the thing. This can happen very easily in large organizations. > The process becomes the proxy for the result you want. You stop > looking at outcomes and just make sure you're doing the process right. > Gulp.” (Jeff Bezos)

This is a quote from a Jeff Bezos letter to the board, talking about internal metrics and improvements. Sometimes when you add a process to a problem, the process can become the focus and not the outcome.

In PM land we use tools and techniques like burn down charts, sprints, and spikes. You can get obsessed over getting these things right, and fail to ship effective, quality software. The special language used in and around these processes adds to the problem too, as the language ends up feeling like an accomplishment in itself. Too much focus on the pomp and circumstance of a process takes away from actually building great software.

e.g., Let's put a pin in this ...

The real value isn't in the process or lingo, it's in doing things better and making better software within profitable budgets. It's something that's been rolling around my head for a while, and Bezos describes it nicely.

I was talking about basic project management principles with a friend the other day, when I came across this Bezos quote. It sparked a discussion about software development processes, including hitting a few topics that I think are especially distracting in software development.

Do you use sprints, burn down charts (etc.) in software project management?

Yes, these are fairly common software management tools now, and I use some aspects of them. Now of course we don't say “spike” ever, or “tent pole”, but we do plan sprints of flexible durations, and we're always aiming for minimum viable steps and frequent releases.

I think it's a common mistake to set fixed durations with sprints, as it can shift the focus to succeeding at the sprint versus shipping something viable (i.e., both useful in the short and medium term). It can really deflate the team if sprint durations make no sense, as developers pick up on goals that aren't about useful or quality software.

Fixed duration sprints can also force poor decisions, as your primary goal is time and not the other factors important to software. If you relax your use of sprints a bit, you can pick sprint times that fit the underlying problem better. The real goal with sprints is to focus on scoping the project, and improving the overall tempo of development. Sprints shouldn't be truncating quality for minimum viability, nor should they be pushing teams to burnout faster. Really, all we want from sprints is a framework to keep us focused on the right features and a strong speed of development.

Does 'sprint' equate to 'crunch time'?

No, it shouldn't.

This is a great question. My friend is coming from another domain, specifically small-scale custom manufacturing. He's not fully familiar with software development terminology (though he's vaguely familiar with how software is generally developed). Conversations like this are a great reminder that the language we've developed in this industry is insular, even though it is based on what we think are clear metaphors. When you think about if from an outsider's perspective, you can see how arbitrary the language is, and how the imagery doesn't fit perfectly.

This is especially true with terms like sprint. You can't literally sprint all of the time, as it suggests expending the maximum amount of energy over short distances. Software projects are anything but short, and the idea of sprinting through the entire thing is absurd. The PM concept of sprints doesn't match the real world use of the term very well.

A sprint is like a focused mini project. To some degree, it's like having a personal trainer guide your workouts and push you a bit. The idea is to use the mechanism to help you push to a clear goal.

More traditional PM structures projects as very long, boring wanderings through the desert. Waterfall projects, for example, don't produce workable software until much later in the process.

We might say, “we're authorizing blanket overtime” which tells the > guys we need as much effort as we can get right now. There are some > tasks on the shop floor which simply can't be done faster, so we > would add more hours. Or worst case a second shift. There's huge > inefficiency in adding a second team.

That is a common manufacturing practice for increasing bandwidth, but sprints aren't only about increasing output (though the term strongly suggests that). A sprint is more like setting up a smaller shop, with a special, focused project.

Ahhh. We would job things out to other manufacturers ...

That's not quite it either, though I do find using sprints for special ops is especially useful, as you push the focus of the tool to problems that need special focus.

The concept of project sprints was really to make things feel more focused and tactical. It was a backlash on the traditional waterfall planning (i.e., requirements, design, implementation, and testing).

But after using sprints a bunch, they can become empty words for traditional project management things. The trick is really to keep sprint projects focused on smaller, but useful deliveries.

Sprints really just become project phases like those in the waterfall model, except that you've organized the deliveries differently. You try to partition design into things you can deliver on shorter intervals, rather than aiming to deliver one giant thing at the end. There is a huge advantage to delivering these small and useful pieces early on, as you learn a lot about what works (and doesn't) well before the end of it all.

I was saying earlier that the concept of sprinting suggests running fast, which if you think about it is so expensive in terms of long-term motivation and energy. It's an odd side-effect of the name itself, as running fast isn't part of the definition of a software sprint, yet the term implies it so strongly.

There's this pattern of making special languages for our formal processes, based on the ways we approach building software. It's difficult to find ways to describe processes that don't eventually become ideology or warped in some way. The simple act of naming the parts can change how we think of them, if we lose focus on the real goals.

I can't think of an analogue in manufacturing ...

It eventually boils down to the same set of problems as with projects in any industry. I've seen special-ops style projects in manufacturing before:

One re-manufacturing mill I worked with started a finger-joint mill. They took their best staff and had them design and built the new plant in stages, apart from their traditional management techniques. They split the work into smaller chunks, and had something up and running early.

Ahh, I see!

They treated it like a special thing, which helped them escape their traditional planning techniques.

Of course sprints aren't really just special-ops anymore, but that's where the concept started from. We used to say “Let's push hard and get this out by next week”. We used this push mindset well before Agile methodologies were well-defined, and sprints were really an extension of that.

Yeah we did that too, but I guess we were so unfocused that it was > normal to work on random projects.

In the end it's just different words for the same things. The mindset of making projects smaller and focusing them on early and useful releases is the best part of sprints. The concept of isolating design to reduce scope is also great.

Really, sprints cut across the grain of the old waterfall style planning, repackaging a lot of the risk to earlier deliverables. It really only works if your sprints produce production quality deliverables though, which is why it's so important to avoid serving the process over the goal of building something incredible.

Sprints are a good example of allowing the process to become the focus, instead of obsessing over what you're making. This is what frustrates me the most about software development methodologies: when great concepts become ideology and the underlying intent is lost. You start spewing the bullshit terms without even thinking. They become bullshit when the term is the focus, rather than the outcome.

e.g., Let's spike this feature for the next sprint.

Or, Our sprints are only 1 week, so that story is too much for us right now ...

It's disingenuous to use these words all the time. It allows a lot of passive-aggressive behaviour too, as you can use the noble act of following the process as a way to beat down legitimate concerns about what customers or the business needs.

What I see happen is that smart people can control production and planning by using the process language in clever ways. Arguing things for the sake of process can be a sign of that problem, i.e., elevating the process above the intent.

The problem isn't in the process, however, it's just a reminder that it's easy to focus on the wrong goal. Sticking to your process is often a much clearer path than figuring out what your users really need, or how to design that thing in such a way that it's a viable business. And because the process can be easier to succeed at, it becomes an easy target for people on a career path.

As software leaders we just need to remind our people to apply the process and tools for the outcome. We want to build useful things for our fans and users, and we want these projects to serve the needs of the business. The processes and methodologies are just tools to this end, and not the end itself.

#SoftwareEngineering #Weblog

Sometime over the last year I stopped paying attention to Twitter. Between the political cacophony of 2016 and a growing list of people I was following, the noise ratio was just too poor to hold my interest. Twitter had become like LinkedIn to me, a service I used to have a professional presence, but not one that inspired or taught me anything. I had given up.

A friend recently challenged me to find the interesting in Twitter again. He suggested declaring bankruptcy and starting over. While I liked his suggestion, I decided to apply another minimalist principle to my feed. Instead, I've been scrutinizing the people I follow looking for the “spark of joy” in what they post, things that make me grin, things that inspire me, or things that challenge me in some way. Anything that's disingenuous, caustic (for no reason), or just consistently unintelligent can go.

Every week or so I read a few hundred Twitter posts and un-follow things that don't have that spark. Slowly, my feed has improved. It's almost at the point now that I'm consistently seeing interesting things.

Things that don't have the spark

I've found a few patterns in how people use Twitter, things that just tend not to work or be interesting.

  1. People who repost a lot are not very interesting. There are a few exceptions to this, but it's true enough that it's my first heuristic for questioning a source.
  2. People who post a lot of political stuff are less interesting overall too. This, unfortunately, has had me filtering out a lot of otherwise interesting programmers and designers, especially in 2016. We should all care about our country and how its run, but I find that topic doesn't mix well (at least in excess) with things that are inspiring or interesting for people who create things.
  3. Corporate accounts, especially those that only post links to their blog articles, are rarely very interesting. They can feel dishonest when they're clearly only there to build traffic (versus trying to teach, inspire, or motivate).
  4. Famous people are not always interesting either, especially when they're just there to build traffic.

There are also a few hints in the body of what people post that affect how I feel about them:

  • random UPPERCASE words,
  • bad grammar or spelling,
  • crappy images,
  • overuse of emojis, or
  • overuse of hashtag / mentions ...
  • unless of course using it is somehow ironic or instructive.

There are a few details that make people stand out on Twitter, things like:

  • clever use of whitespace,
  • funny/smart use of emojis, and
  • other fun uses of images, links, etc.

It's amazing what a bit of whitespace can do to a Twitter post, even though not all clients show it. A small amount of attention to detail shows that an author cares (and is knowledgable).

In the end, weeding the garden is good

The best thing about cleaning out who I follow is that I've re-discovered some really interesting people, who write things that change how I think. It also has me weighing what I post more carefully, as Twitter doesn't really allow you to demote or segregate content well. For what it's worth, some basic categorization for feeds would allow for people to segment their streams a bit, allowing followers some choice of what aspect of a person you read about.


I had a realization last week:

How can it be more me? If I'm not in it, can I get into it?

I'm an idea guy. It's why I love designing software, both in terms of system design and user experience. I love designing and developing products too. It's something that can get me fired up, keep me from sleeping, and keep me motivated through even the darkest, rainiest days.

It's easy to conflate the love of designing things and your favourite ideas with projects you should actually work on yourself. Not every idea is worth doing. Not every idea is suitable for a given company, team, or even an individual to do. The thing has to fit the people making it somehow. Ideally the ideas and designs embody something that is at the root of those people, as the result will be something that is much more than the sum of its parts.

So I had one of those ideas

Like many people, I use task lists to organize the projects I work on. I write the tasks on a large piece of paper, organizing them in lists and columns around the sheet. In the center of the page, I summarize the high points of all the lists into a single focus list, which I separate visually from my others on the page. This list has very specific tasks and goals that serve the various projects and sub-projects on the page. Often finishing the focus list is an incredibly successful sprint of work towards some larger goal.

One of many focus list wireframes from 2016

I've been thinking about building a tool for my focus lists for a few years now. I've used the project as a way to practice sketching various UI designs, looking for balances between skeuomorphic, spacial, and domain-centric ways of thinking about the problem. As a practice project it's been fun.

The other day I read that Microsoft planned a shutdown of a recent acquisition, Wunderlist. I wondered if I should dust off my focus list designs; I could easily commercialize the idea and build it myself. The problem was that I didn't bother to stop and ask myself if it was something I should do. I didn't wonder if it fit who I am.

When I dug into the question a bit, I found a list of reasons why I wanted to build a task-list application:

  • My idea of focus lists is pretty great
  • I know how to design and build web things
  • I have a bunch of designs that I'd love to build

Most of my reasons to build a TODO tool are all pretty shallow.

If I ask myself harder questions, the project seems way less obvious:

  • Does the project fit who I am?
  • Are task lists something I get excited about?
  • Should I really build a task app?

I had to admit to myself that I'm not passionate about productivity tools. I use them and I need them, but I don't talk or write about them, as they're more of a necessary evil than something that excites me.

Looking more objectively, a task-list project just doesn't fit me. It isn't very Bruce. I love the idea. I'm proud of my clever design and approach. But the thing itself isn't something that lights a fire under me. It doesn't get me excited for the thing, rather I'm more excited about the hubris of it.

From point A to point B

To figure out if a project is really me, I think I have to do a few things. First, I have to imagine that it's the only thing I'm working on. Am I still excited a month from now? Am I talking about it? Am I willing to do the boring work to finish it?

I also have to imagine if it's something that fits what I've done already, at least the stuff I'm still excited about. It needs to fit where I'm going too. If I draw a line through those things and extrapolate, do I like where it points? Is the thing it points to a better version of me?

So I now have a new question for my side projects: is this project really me? Is it a very Bruce thing? I have lots of project ideas that are totally me. I think I'll focus on those.


There's a lot to like about our beloved task management tools. But if we're honest, there's a lot they get wrong too. Here are a few ways TODO tools grind my gears:

  1. Every task and list looks exactly the same.
  2. Lists are organized with limited hierarchy and pre-requisites.
  3. Lists are organized with no real spacial control. (Kanban boards are a great example of how spatial organization can vastly improve how we think about certain types of lists.)
  4. Tasks lists are either a huge a black hole or they're a cacophony of noisy craziness.
  5. Task tools can be too atomic. A task is an indivisible line item, in single list. Grouping and splitting tasks is often manual and way too much work.
  6. Importance is missing from most list tools; everything has the same weight; there are only minor visual differences between lists and items.
  7. TODO lists require careful weeding, and they accumulate cruft really easily.
  8. It's can be difficult to work a list; one task is usually a dozen and not all completed tasks are interesting.
  9. Task lists don't care where you're at personally, they just sit and stare at you. I swear my lists judge me some days.
  10. They don't play nicely with your schedule. Not everything on your lists needs to hit your calendar, but the stuff that does really does.
  11. Completing a task is more than checking it off. Tasks have more exit states than done, anywhere from “Wow, that was a bad idea” to “This doesn't matter anymore because of such-and-such”.
  12. Huge lists are super demotivating.
  13. Huge sets of completed tasks don't have the positive effect you wish they would.
  14. Some tasks are time sensitive, which is more than just when it's due.
  15. Some tasks are recurring, but not in the it's-due-every-wednesday sort of way. Meaningful tasks like “You should really filter through the bug list this month” need to happen regularly, but not monthly on Tuesday mornings.
  16. Some tasks are just plain different than others. I'm looking at you, “Find inspiration today”.
  17. I finish certain types of tasks better at certain times of day, or when I'm in certain moods.
  18. And finally, task lists are very rarely inspiring. I've never looked at my TODOs and had an epiphany.


The New Year came and went without much of a fuss. I read about the 2016 Maker Challenge shortly after the holiday, in the flood of annual self-help and 2016 resolution articles. The challenge was something I was keenly interested in, then promptly forgot about in the chaos of startup and family life.


The 2016 Super Mega Awesome Maker Challenge

If you haven't heard of it, the Maker Challenge is a quest aimed at pushing Makers to make more. It encourages you to curate a list of your ideas, tracking your progress through the year. Folks serious about the challenge publish their lists too, which keeps them accountable to their goals.

It's funny: the idea of making a list of ideas public seems so counterintuitive, as in the business of software we under-promise and over-deliver. Talking about something too early can set the wrong expectations, especially as a project changes. I've gotten in the habit of never talking about things before they're almost done, and so I en end up sitting on dozens of ideas for smaller projects that few people hear about.

The Maker list isn't all about huge things, it's about making and finishing things. The projects are contained and concrete, almost like exercises and challenges. The lists I've seen remind me of what writers often do, forcing themselves to write short stories, or to make a habit of entering writing contests. The idea seems to be about pushing to do something, and to vary what those somethings are. The goal is twofold: both to make stuff, and to be making stuff.

Thinking about making and making my smaller projects public is somehow exciting.

The list starts here

Project #0 was to move the list to a Google doc:

2016 project list

I will update the list as I work through it. I'm using the list to obsess over making stuff, tracking ideas, and getting motivated to do.


I've noticed an interesting shift in computing over the last few years. It's one of those changes that becomes obvious in hindsight, though while in the moment it was confusing and disorientating. It turns out I was blinded by my own path of coming up in the industry.

I'm never surprised when a bias gets in the way of seeing something. It's a constant of human progression and the fundamental reason we science. We're aware of our limits, and we pursue knowledge from the perspective of disproving ourselves so that we can uncover the truth despite the limits of our ability to observe and think. Science is cool.

That same set of filters are much more difficult to apply to industry trends, as the facts are fluid, and the reasons for those facts are based on a complex set of interactions between people (who themselves are gooey masses of crazy).

The search for sparkles ✨

Finding talent in computing has always been difficult. There is a large gap in how well people perform while building software, where one developer can be between 5 and 10 times more productive than another. Individuals may also perform better or worse depending on how they fit into their team, and how they mesh with the software stack in use. Measuring these differences in interviews is difficult.

I've used a number of tools when interviewing developers and have found what most researchers have found, that standard measurement tools like brain teasers aren't really that useful. I've used written tests, whiteboard tests, brain teasers, and even off-the-wall questions when interviewing people. I found that the standard tools failed to gauge actual job performance, rather it measured the ability for people to perform in interviews.

I have found a few less rigid techniques for measuring potential hires, mostly in gauging trajectory and passion. Is the developer excited about learning? Are they excited about making software? Do they actually do both of those things? Combined with the standard do-they-fit-who-we-are gut reaction, I've been moderately successful in finding some great people.

⛰ The landscape is not a constant

Now this is where it gets interesting. I've been interviewing and hiring for almost 20 years. I have accumulated a bunch of questions I ask people. And while the technologies I talk about have changed, I have always expected certain skills and behaviours from specific levels of software developers. In terms of soft skills this has been very successful, but recently I've noticed that the hard skills have dissipated.

This Spring I've been hunting for a few senior developers. I've talked to dozens of incredible people, but have been confused by the lack of experience in system design techniques. Looking back I noticed signs of it years ago, though in recent interviews it's a set of skills that have mostly disappeared.

When my own perspective fails me, I look to other pillars of the local scene. I talked about it with a good friend, asking him if he had noticed the shift in any of their recent hires. He's also seen a lack of system design understanding. We emailed back and forth for a few days and came up with some plausible reasons for the gap.

✨ Sparkles become more rare over time

We agreed that skills like system design are (and should be) more rare now than in the 90s. There are a bunch of reasons for this, but mostly it's the result of faster and larger computing resources, combined with tools that are much more capable. While this seems very obvious in retrospect, it was blindingly difficult to see while interviewing people.

Most software development problems in the 90s required some amount of system design. Resources were usually constrained by some aspect of the problem, and tools like capacity planning and careful plotting around the inherent system limits were absolutely necessary. Junior developers had to learn these design techniques to progress to mid-level developers. Senior programmers taught these skills, and were responsible in the many cases where planning failed to foresee limits that blocked the project.

As the industry matures, the risk of failure due to limited resources decreases. Additionally, the tools have progressed, reducing another common friction from 20 years ago. There are fewer times when system design is required by every team member.

And as hardware, tools, and the industry mature further, the business of software evolves with it. Many businesses now focus on little-a-agile techniques, which are iterative and fast. We call it moving fast, which is no longer the desperation of the Valley startup, but a viable approach to building software. It wasn't possible in previous eras of computing, as the technical risks required moving slowly. As those technical hurdles melt away, early startups are freed to obsess over features and utility instead of spending all of their time on figuring out if the problem is soluble at all.

We of course still do system design, though there are fewer people that need to learn it. Businesses can hold off on system level design until they're scaling, as the risks justify the tradeoff in development speed. It's a crazy and wonderful time to be in computing.

🦄 Unicorns see other unicorns 🦄

Now the question remains: how was this shift in computing knowledge surprising? I came up in the industry at a time when most of the problems required careful systems design. My incredible mentor came up in the proterozoic era of computing, where even the smallest of problems required careful design. I learned to think about software in terms of capacity, data, and flow first, using diagrams to think and communicate more clearly.

Today? Most mid and senior level developers can work through problems with less rigour. There is less need to understand how the engines work, and there are many problems that the current generations of developers will never need to think about. Questions about systems planning, measurement, and design are above the experience of these generations.

Deep knowledge has shifted up over each generation of developers and designers over the last 50 years. Deeper design knowledge is now relegated to unicorns and architects. And that's okay. We'll still use it, and we will continue to teach it as deep understanding always pays off over the long term.


I have tried to love podcasts for a few years now. There are several that I like, but I find it difficult to listen to any of them consistently. I'll binge listen for a few weeks, but for whatever reason I get stuck and move on to the next show.

There are a few things that podcasts do that frustrates me:

  • Low quality production
  • Shows that go too long or that ramble
  • Shows that take long hiatuses
  • Surplus of opinions and deficits of facts

I admit that part of the problem is the way I find, consume, and collect shows. iTunes isn't great for discovery or browsing. It does well enough at distribution, but the store is still too monochromatic for the social aspects (shut up, Ping). I end up hopping between sites to find shows, to check in on show statuses, and eventually I just don't remember to do those things. I have lost contact with a few shows due to issues with iTunes or my podcasting apps.

I know that the platform will improve, so I can live with the fragmented social, news, and show information bits. I can also live with gaps in production (TV and Netflix have me trained to binge and wait). What I can't learn to love are the crappy production things. I discovered that there are specific formats that work way better for my brain: shows that are carefully cut, curated, and polished are the ones I consistently enjoy.

There are a few podcasts that are carefully produced, which makes a world of difference.

Things that are important to keep me interested in your show

  • Planning and research keep a show focused and factual. Opinions are interesting, but facts to back up the gut-feelings are way cooler.
  • Production values can turn a so-so show into a good one. Intros, theme music, nice cuts, carefully considered segments and lengths are a few of the things that stand out in the shows I like.
  • Flattering and interesting material is better than incredible guests. I recently listened to an interview with one of my childhood heroes; the audio quality and interview focus was so poor that I lost some respect for the show and my childhood hero. I would have preferred not to hear the botched interview.
  • Broadcast chops matter. I can live with following a podcast through to maturity, but the people involved should be studying and improving. Simple things like excessive filler words (“Uh, ah”, and “like”) and low quality audio-capture really subtract from the experience.
  • Shorter is way better for some reason. Cutting out the boring parts and keeping the conversations focused keeps me listening.

The balance of production quality, focus, and length are the attributes that make the most difference to me. Facts are a close second as opinions get old quickly, and facts are so easy to check.