<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Tim Mecklem</title>
    <description>Managing Partner at Launch Scout | Software Engineering Leader | Elixir, Phoenix, Ruby, and Rails Enthusiast</description>
    <link>https://timothy.mecklem.com/</link>
    <atom:link href="https://timothy.mecklem.com/feed.xml" rel="self" type="application/rss+xml" />
    
      <item>
        <title>Quietly do new awesome things</title>
        <description>&lt;p&gt;Putting other considerations aside for a moment, I’m awestruck at how fluidly I can move into spaces that would have taken much deeper research and learning before Claude and friends. In the timespan of a couple of days, I’ve been able to build a Windows-executable Elixir application that uses websockets, starts on login, and manages some complex process lifecycles. Additionally, it has an NSIS installer. It’s likely this software would have never been built a year ago due to the amount of time it would have taken me to get up to speed on all of that, and not only does it exist now, it has a full test harness, is part of a CI build process, and is in production use. I read every line of code for all 70+ files in the PR, I understand what it’s doing and how it’s doing it, and it has opened a door that would have been shut in the past. Let the AI coding debate rage on as it will, and we’ll just be over here in the corner building crazy new stuff we only dreamed about before.&lt;/p&gt;
</description>
        <pubDate>Wed, 10 Dec 2025 00:00:00 +0000</pubDate>
        <link>https://timothy.mecklem.com/nibbles/2025/12/10/quietly-do-new-awesome-things/</link>
        <guid isPermaLink="true">https://timothy.mecklem.com/nibbles/2025/12/10/quietly-do-new-awesome-things/</guid>
      </item>
    
      <item>
        <title>From fungible to linchpin</title>
        <description>&lt;p&gt;Unbeaten career advice: If you write software for a living and you want to move from “fungible resource” to linchpin, start understanding the big problem you’re a small part of solving, and take ownership of whatever part of the solution you can. The industry is full of people capable of taking Jira tickets and eventually turning them into some kind of functional software. Even (especially?) in this year of AI transformation, the scarcest resource is a competent contributor who cares about the problem behind the problem they’re solving and is willing to proactively own part of it.&lt;/p&gt;
</description>
        <pubDate>Thu, 04 Dec 2025 00:00:00 +0000</pubDate>
        <link>https://timothy.mecklem.com/hot-takes/2025/12/04/hot-take-from-fungible-to-linchpin/</link>
        <guid isPermaLink="true">https://timothy.mecklem.com/hot-takes/2025/12/04/hot-take-from-fungible-to-linchpin/</guid>
      </item>
    
      <item>
        <title>AI needs technical oversight</title>
        <description>&lt;p&gt;Despite my technical background, I almost shipped two features* to our internal production application that could have cost Launch Scout time and money today. I gave reasonable prompts, but the underlying technical issues with the solutions were nuanced and non-obvious to my trained eyes at first.&lt;/p&gt;

&lt;p&gt;You know that I am bullish on the capabilities of these tools and the productivity gains from them. I just wanted to give the other side of it for why it’s still important to have someone at the helm who understands the mental model of what’s happening with the code.&lt;/p&gt;

&lt;p&gt;*Nerdy details:
One feature was having a recurring job look at timestamps on a table to determine which records had been reviewed and which haven’t. Claude built it in such a way that created a race condition that some important information would be lost, so I had to re-prompt it to use a “last seen” kind of timestamp model instead of a current date and time.&lt;/p&gt;

&lt;p&gt;The other would have also resulted in a difficult to diagnose issue with actions from one OS process needing to communicate with another OS process. It didn’t understand the state that needed to be shared between the two, and assumed it could access everything from a side that didn’t have the correct context.&lt;/p&gt;
</description>
        <pubDate>Tue, 02 Dec 2025 00:00:00 +0000</pubDate>
        <link>https://timothy.mecklem.com/nibbles/2025/12/02/hot-take-ai-technical-oversight/</link>
        <guid isPermaLink="true">https://timothy.mecklem.com/nibbles/2025/12/02/hot-take-ai-technical-oversight/</guid>
      </item>
    
      <item>
        <title>AI coding as improv comedy</title>
        <description>&lt;p&gt;AI-assisted development is great, but also can get extremely frustrating. It continues to work better if I think of it as “improv comedy coding” instead of something more productive and serious. Lets me laugh at the ridiculous parts and makes it easier to celebrate the wins.&lt;/p&gt;
</description>
        <pubDate>Mon, 24 Nov 2025 00:00:00 +0000</pubDate>
        <link>https://timothy.mecklem.com/hot-takes/2025/11/24/hot-take-ai-coding-as-improv-comedy/</link>
        <guid isPermaLink="true">https://timothy.mecklem.com/hot-takes/2025/11/24/hot-take-ai-coding-as-improv-comedy/</guid>
      </item>
    
      <item>
        <title>Measuring vs Controlling Software Projects</title>
        <description>&lt;p&gt;A lot of project managers and delivery teams don’t know what a truly successful software project looks like. Successful in solving a business problem at a cost less than the return, on a reasonable timeline, with healthy practices that leave the team positioned to turn around and do it again (not adding technical debt or burning out the team). This is something that I think most people in software development sense but no one wants to admit or talk about. The majority of my career as a dev, I was on projects that shipped code late and de-scoped to the bones. I “shipped” a lot of junk early in my career that rarely that met the business need presented to the team through layers of indirection.&lt;/p&gt;

&lt;p&gt;The thing is, you can &lt;em&gt;measure&lt;/em&gt; important things via traditional project management techniques. Sometimes you can &lt;em&gt;predict&lt;/em&gt; useful things too. You just can’t easily &lt;em&gt;control&lt;/em&gt; software projects through dials connected directly to those metrics. Throwing more people and money at a project to get milestones back on track is usually the quickest way to knock it further off track. The best way to “control” a project’s outcome is through continuous process improvement and investing in deep understanding of the nature of software development. The shortcut to this is usually adopting Kanban WIP minimization and flow maximization techniques, and thinking through the lens of theory of constraints and cycle times. Rather than throwing resources at a perceived bottleneck, take time to understand if it truly is the bottleneck and if so why it exists.&lt;/p&gt;

&lt;p&gt;It is truly rare to find a person who understands how to maximize budget, scope, and time indirectly through iterative improvement and fundamental agility and responding to reality instead of updating spreadsheets.&lt;/p&gt;

&lt;p&gt;Who do I know that understands this, has implemented it successfully, and agrees with it?&lt;/p&gt;
</description>
        <pubDate>Fri, 07 Nov 2025 00:00:00 +0000</pubDate>
        <link>https://timothy.mecklem.com/nibbles/2025/11/07/measuring-vs-controlling-software-projects/</link>
        <guid isPermaLink="true">https://timothy.mecklem.com/nibbles/2025/11/07/measuring-vs-controlling-software-projects/</guid>
      </item>
    
      <item>
        <title>Phoenix LiveView Websocket Fallback Session Cache</title>
        <description>&lt;p&gt;If you ever run into a phoenix app continuing to fall back to longpoll even after you’ve configured the websocket correctly, clear the browser’s session cache. (LiveView stores a fallback flag in the session). This is for you, future Tim.&lt;/p&gt;
</description>
        <pubDate>Thu, 06 Nov 2025 00:00:00 +0000</pubDate>
        <link>https://timothy.mecklem.com/nibbles/2025/11/06/phoenix-liveview-websocket-fallback-session-cache/</link>
        <guid isPermaLink="true">https://timothy.mecklem.com/nibbles/2025/11/06/phoenix-liveview-websocket-fallback-session-cache/</guid>
      </item>
    
      <item>
        <title>Dogfood something with AI</title>
        <description>&lt;p&gt;If you’re a developer using AI, dogfood something. Build something end-to-end that solves your own problem (where you’re the customer), and own it from first git commit through integration and deployment, over time. It’s possible to do on the side, will help you level up, and you’ll see where the cracks appear in using AI tools from a customer perspective. Push your knowledge of testing tools and automation and make the thing you build robust and reliable. Build the small affordances that make your life nicer. See what it’s like on the other side of your dev environment. Then talk about it and share your experience with other people. There’s a lot of joy in software beyond writing the code.&lt;/p&gt;
</description>
        <pubDate>Tue, 28 Oct 2025 00:00:00 +0000</pubDate>
        <link>https://timothy.mecklem.com/hot-takes/2025/10/28/hot-take-dogfood-something-with-ai/</link>
        <guid isPermaLink="true">https://timothy.mecklem.com/hot-takes/2025/10/28/hot-take-dogfood-something-with-ai/</guid>
      </item>
    
      <item>
        <title>Subtle Superpowers</title>
        <description>&lt;p&gt;Living in the Rails and Phoenix ecosystems is full of beautifully executed conveniences that are easy to forget and hard to appreciate until you step outside for something. For example, when you test a controller in Rails you typically use a request spec, and it usually goes all the way through to the database in a transactional rollback approach. You get &lt;em&gt;real&lt;/em&gt; testing of everything below the controller out of the box. In another framework like .NET, the standard practices for testing aren’t as consistently established but it seems much more common to mock the service layer. Effectively you’re unit testing the controller methods instead of integration testing from the HTTP perspective all the way down. But it’s a similar amount of effort, and the speed differences are negligible for the confidence it gives. Rails devs are all reading this like, “none of this is new, Tim.” But these standards and this consistency is really powerful in a way that is often overlooked by people who don’t have to straddle ecosystems. It’s one superpower among many for Rails and Phoenix.&lt;/p&gt;
</description>
        <pubDate>Mon, 27 Oct 2025 00:00:00 +0000</pubDate>
        <link>https://timothy.mecklem.com/nibbles/2025/10/27/subtle-superpowers/</link>
        <guid isPermaLink="true">https://timothy.mecklem.com/nibbles/2025/10/27/subtle-superpowers/</guid>
      </item>
    
      <item>
        <title>The Scalability YAGNI trap</title>
        <description>&lt;p&gt;Don’t sacrifice testability, simplicity, and joy over scalability (in either direction) until you &lt;em&gt;actually&lt;/em&gt; have the problem that needs it. If you get some scalability for free, great (thanks, Elixir!). But it’s a great big YAGNI for most endeavors. The technology isn’t the limiting factor early on… it’s the idea that needs to be tested. Pick a solid majestic monolith and it’s pretty likely you’ll never have the kinds of scalability problems you’re tempted to solve before you actually understand your production needs.&lt;/p&gt;

&lt;p&gt;Microservices, k8s, cloud functions, I’m looking at you. It’s almost a trope at this point: &lt;a href=&quot;https://x.com/yatish_me/status/1977521025983324491&quot;&gt;https://x.com/yatish_me/status/1977521025983324491&lt;/a&gt;&lt;/p&gt;
</description>
        <pubDate>Fri, 24 Oct 2025 00:00:00 +0000</pubDate>
        <link>https://timothy.mecklem.com/hot-takes/2025/10/24/hot-take-yagni-over-scalability/</link>
        <guid isPermaLink="true">https://timothy.mecklem.com/hot-takes/2025/10/24/hot-take-yagni-over-scalability/</guid>
      </item>
    
      <item>
        <title>Try a Moon Shot Idea Every Day</title>
        <description>&lt;p&gt;I subconsciously started doing something a while back, and now it’s become an intentional habit. In a side screen, I’ll give Claude an impossible task. Refactor something huge, or try to one-shot an application with a big prompt. The success rate is somewhere in the 5-10% range. That might seem low, but it’s essentially a marginal-cost zero half court shot that pays big when it works. This is largely a side effect of delayed market effects on an industry gobbling up capital and trying to convert long term loyalty through unsustainable subscription prices. As such, I don’t think it will be around forever. While it is, might as well get some big wins with minimal marginal effort.&lt;/p&gt;
</description>
        <pubDate>Thu, 23 Oct 2025 00:00:00 +0000</pubDate>
        <link>https://timothy.mecklem.com/nibbles/2025/10/23/try-a-moon-shot-idea-every-day/</link>
        <guid isPermaLink="true">https://timothy.mecklem.com/nibbles/2025/10/23/try-a-moon-shot-idea-every-day/</guid>
      </item>
    
  </channel>
</rss>
