462: Decomposition as a key developer skill with Steve Polito
Summary
Joel Kinville and Steve Polito explore decomposition as a fundamental skill for software developers. They begin by discussing how Steve used AI to generate conference talk ideas from his atomic note-taking system, which sparked a conversation about the broader concept of breaking down complex problems.
The conversation first focuses on product and feature-level decomposition. Steve shares his early struggles with breaking down work, contrasting horizontal slices (model, controller, view) with vertical slices that deliver user-facing value. They discuss the benefits of vertical slices: faster shipping, better-informed implementation, and the flexibility to reprioritize. Practical tips include talking to stakeholders to reduce scope, starting from the UI and working backward, and avoiding modals as a first implementation to reduce friction.
They then zoom into code-level decomposition. Steve mentions relying on Rails conventions and established project patterns, while Joel introduces his “triangle of separation” heuristics: single level of abstraction, separating branching code from doing code, and pushing conditionals up the decision tree. These principles encourage extracting logic into small, named functions that can be composed. They discuss finding decomposition opportunities through code churn and duplication, and the atomic unit of code being a named method or function.
The episode concludes by speculating on how decomposition skills might become even more valuable in an AI-assisted development world. While AI can handle minutiae, developers will still need to understand systems, break down problems, and provide clear context. The ability to decompose work at all levels—from system architecture to algorithm steps—remains a core human skill that enables effective use of AI tools.
Recommendations
Concepts
- Vertical Slices — A method of breaking down work into thin, user-facing deliverables that provide immediate value, as opposed to horizontal layers (model, controller, view). This leads to faster shipping and better-informed code.
- Triangle of Separation — Joel’s set of three heuristics for code decomposition: write code at a single level of abstraction, separate branching code from doing code, and push conditionals up the decision tree. These encourage extracting logic into small, composable functions.
- Atomic Notes — Steve’s note-taking system where each note has a thesis statement title and a paragraph of supporting information. Notes hyperlink to each other, creating a network of ideas. He used AI to find connections between notes for conference talk ideas.
Tools
- Judo Scale — Mentioned in the ad read, Judo Scale is a tool that helps applications handle traffic spikes and lower hosting costs through auto-scaling. A free plan is available.
Topic Timeline
- 00:01:11 — Introductions and personal updates — Joel Kinville introduces himself and guest Steve Polito. Steve shares a fun fact about Mansfield, Massachusetts, where the Acela train reaches its top speed. Joel discusses his recent experiment using AI to generate conference talk ideas from his atomic note-taking system, feeding note titles and conference themes into a chat interface to find connections.
- 00:07:07 — Introducing decomposition as a core developer skill — Steve proposes decomposition as perhaps the one skill every developer should master. He relates it to breaking down ideas in his note-taking system and suggests it applies to many aspects of development life. They agree to explore the topic from different angles, starting with breaking down epics or story tickets into smaller, valuable pieces.
- 00:08:14 — Breaking down features into vertical slices — They discuss the importance of breaking features into “vertical slices”—thin, user-facing deliverables that provide value—as opposed to “horizontal slices” like working on the model, controller, and view separately. Steve shares how a ThoughtBot interview question highlighted his initial naive approach. Vertical slices lead to faster shipping, better-informed code, and avoid dead code.
- 00:12:25 — Practical tips for scoping and breaking down work — Steve offers concrete strategies for breaking down work: talking to stakeholders to clarify or reduce requirements, using feature flags, and identifying the least amount of information or UI needed to deliver value. He gives an example of a dashboard feature, suggesting to first ship just the calculated number, then add line items, and finally a modal—or potentially skip the modal entirely if it adds unnecessary friction.
- 00:19:05 — Benefits of granular stories and iterative development — They explore the strategic benefits of small, vertical slices. In startup environments, it allows for faster iteration, the ability to cut scope if follow-up work is harder than expected, and quicker validation of a feature’s value. Tight feedback cycles enable teams to be more agile and avoid wasting effort on features users don’t need.
- 00:20:21 — Zooming into code-level decomposition — The discussion shifts from product to code decomposition. Joel notes that while composition is often discussed, someone must first build the composable parts through decomposition. Steve shares his approach: relying on conventions (like Rails), avoiding premature abstraction, and using code churn as a clue that logic might need decoupling. Duplication is another signal for extraction.
- 00:25:20 — Atomic units of code and decomposition heuristics — They ponder what constitutes an “atomic” unit of code for decomposition, settling on a named method or function as the smallest piece of behavior that can be referenced and composed. Joel introduces his “triangle of separation” heuristics: write code at a single level of abstraction, separate branching code from doing code, and push conditionals up the decision tree. These force extraction of logic into small functions.
- 00:32:27 — Origin of decomposition heuristics and Elm influence — Joel explains the origin of his heuristics, citing an “aha moment” while working with Elm’s Maybe type. The compiler forces null checks, leading to patterns where business logic is written in a confident style (assuming values are present), and null handling is separated. This separation of conditional logic from core behavior inspired the broader principle of separating branching from doing code.
- 00:35:41 — Decomposition and the future of AI-assisted development — Joel speculates that being skilled at decomposition might make someone a better AI-assisted developer. Steve sees two sides: AI needs context, but breaking problems down could help it focus. They agree that providing AI with clear, step-by-step instructions (like pseudocode comments) is effective. Steve emphasizes the importance of human understanding and retention, using spell check as an analogy for over-reliance, but sees AI as great for roadblocks or minutiae.
- 00:41:07 — Wrap-up on the enduring value of decomposition — They conclude that decomposition is a core skill today and will remain valuable with AI. Developers will still need to understand systems and break down problems, while AI can assist with syntax and minutiae. The ability to decompose at all levels—from system architecture to algorithm steps—enables effective use of tools and maintains team understanding of the codebase.
Episode Info
- Podcast: The Bike Shed
- Author: thoughtbot
- Category: Technology News Tech News
- Published: 2025-05-06T07:00:00Z
- Duration: 00:42:18
References
- URL PocketCasts: https://pocketcasts.com/podcast/the-bike-shed/ce1490c0-4406-0132-c909-5f4c86fd3263/462-decomposition-as-a-key-developer-skill-with-steve-polito/ef0c55ec-2c57-4972-af5a-9b3186ecba09
- Episode UUID: ef0c55ec-2c57-4972-af5a-9b3186ecba09
Podcast Info
- Name: The Bike Shed
- Type: episodic
- Site: https://bikeshed.thoughtbot.com
- UUID: ce1490c0-4406-0132-c909-5f4c86fd3263
Transcript
[00:00:01] Imagine the last time you had to deal with request timeouts or backed up job
[00:00:05] queues in your job environment. Take yourself there. Can you feel it? The
[00:00:10] stress? The frustration? Here’s what Judo Scales knows. You’re either not auto
[00:00:16] scaling or your auto scaler is not doing its job. Because auto scaling is supposed
[00:00:22] to prevent scenarios like this. In comes Judo Scale. Judo Scale helps your app
[00:00:27] smoothly handle traffic spikes while dramatically lowering your hosting
[00:00:31] costs. You can use Judo Scale’s free plan forever so you’ve got nothing to lose.
[00:00:36] If you want to say goodbye to those painful production incidents, visit
[00:00:40] judoscale.com slash bike shed for your special gift as a bike shed listener.
[00:00:44] That’s judoscale.com slash bike shed.
[00:00:57] Hello and welcome to another episode of the Bike Shed, a weekly podcast from your friends
[00:01:05] at ThoughtBot about developing great software. I’m Joel Kinville and today I’m joined by
[00:01:11] ThoughtBot colleague Steve Polito. Hey everyone. Hey Joel. Thanks for having me on.
[00:01:15] And together we’re here to share a bit of what we’ve learned along the way.
[00:01:19] So Steve, what’s new in your world? Hey, all right. So a little fun fact that I learned recently. So
[00:01:26] I’m in Mansfield, New York. I’m a student at the University of New York. I’m a student at the
[00:01:27] University of Massachusetts and there’s a commuter rail station here. And apparently it’s
[00:01:34] one of two places in maybe America, we’ll just say that, one of two places in America where the
[00:01:40] Acela can go its top speed by a platform, which is roughly 150 miles an hour. And I can confirm
[00:01:48] that it is incredible when that happens and also very frightening. So if you haven’t heard of
[00:01:54] Mansfield, Massachusetts before, that’s going to put it on the map for you.
[00:01:57] So if you’re a big train enthusiast, check it out. I don’t think you’ll be disappointed.
[00:02:03] And for those who aren’t familiar, the Acela is the, for the US, considered high-speed rail
[00:02:09] mainline connection that runs between New York and Boston and then beyond.
[00:02:16] Exactly. Yeah. So I don’t know if that’s a good thing or not for Mansfield. I don’t know if it’s
[00:02:21] like, we just got to get out of here. Let’s keep it moving, folks. But I’ve been on the platform
[00:02:26] before when that thing goes by.
[00:02:27] It’s really cool, but also terrifying.
[00:02:30] Blows off your hat.
[00:02:31] Yeah, it blows off your hat and anything else that isn’t strapped down.
[00:02:34] It’s just like the cartoons.
[00:02:36] Exactly. Yeah. So yeah, it’s a little fun fact. But other than that, just enjoying the nice
[00:02:41] weather up here. It’s spring, so things are starting to get warmer, get nicer. What about
[00:02:48] you? What’s new in your world?
[00:02:50] I’ve wrapped up a conference season where we’re submitting a lot of abstracts to calls for
[00:02:57] proposal. And I got a chance to try something a little bit different this year. Repeat listeners
[00:03:03] of the show will have heard me talk about my note-taking system, where I take down ideas as
[00:03:10] a series of atomic notes. Each note is, the title is a thesis statement, something I think is true
[00:03:17] about software. And there’s a paragraph of supporting information. And these notes hyperlink
[00:03:23] to each other. And what I did this year is I took the thesis statement and I took the thesis statement
[00:03:27] and I took the thesis statement. And I took the thesis statement and I took the thesis statement
[00:03:27] Themes that a conference was looking for and a list of all of the theses in my note-taking system, dropped them all into an AI and asked it to find talk ideas that would fit within the theme of the conference based off of where I had multiple notes in my note-taking system that could act as the basis of it.
[00:03:52] Nice.
[00:03:53] Did it work out as you would expect?
[00:03:55] It worked decently well.
[00:03:58] Some of them were ideas where I already had that as an idea.
[00:04:03] Kudos to the AI for finding that, but I’d already found it on my own.
[00:04:06] Some of them were ones I hadn’t thought about, but while digging into them, I realized, wait, I wrote a blog post version of this.
[00:04:13] So the AI is onto something.
[00:04:15] I hadn’t considered it as a talk idea, but there’s already a blog post out, so I could absolutely take that blog post as the sort of skeleton for a great talk.
[00:04:25] And then there’s a few that are, I think it didn’t quite understand what my note was about.
[00:04:29] And so it made some inferences between some notes and then tied them to a topic in a way that I don’t want to quite say it’s hallucinating, but it’s connecting things that don’t really make sense.
[00:04:43] And I think it would do a better job if I’d fed it the full context of the note rather than just dropping titles.
[00:04:50] Yeah, that’s cool.
[00:04:51] And it was just like a chat GPT type interface.
[00:04:54] Yeah.
[00:04:55] Chat interface.
[00:04:56] Okay.
[00:04:56] So no complicated API stuff, just copy paste.
[00:05:01] Nothing like that.
[00:05:02] Cool.
[00:05:03] I’m really intrigued at the possibility of using an AI to interact with my notes because I’ve built up a lot of interesting ideas in there.
[00:05:12] And there’s various ways I can search and query the notes.
[00:05:15] There’s some visual graphs I can generate from them that are helpful to understand.
[00:05:19] But I think there’s a lot of knowledge and intuition that’s maybe locked away in there that I could access more easily.
[00:05:25] Yeah.
[00:05:26] That’d be cool.
[00:05:30] I wonder if there would be a way for it to like, maybe also help you come up with like, probably find trends and maybe also help you like, think of a topic you haven’t even thought about yet that you might be thinking about.
[00:05:43] I don’t know.
[00:05:43] It’s interesting.
[00:05:45] I like exploring ideas like that through AI.
[00:05:47] Yeah.
[00:05:48] Yeah.
[00:05:48] I’d be really curious to see what I can get out of connecting an AI to my notes.
[00:05:53] And I don’t want the AI to write my notes because I think that’s.
[00:05:55] That’s where I get a lot of value.
[00:05:57] Distilling my thoughts, breaking them down into individual pieces, writing out a paragraph of prose.
[00:06:03] That’s stuff that’s useful for me to do.
[00:06:06] But there’s other things such as maybe I’ve written new note and I’m trying to think what are some ideas that are relevant that are already in my note taking system that would be, that would make sense to link.
[00:06:19] I will sort of scan through manually, do a couple searches on some keywords to see.
[00:06:24] Are there any?
[00:06:25] Existing ideas I would want to link to this, but I’d love to see an AI sort of suggested notes to link or something like that.
[00:06:33] Notes that are on similar topics or maybe even that have an interesting connection, but I would never have like thought of it.
[00:06:39] That seems like it could be really powerful.
[00:06:42] Yeah, absolutely.
[00:06:43] I agree with that.
[00:06:44] I feel like a thing that I really valued doing as part of this note taking system is breaking down larger ideas into smaller sort of atomic.
[00:06:55] And that’s helpful for the notes.
[00:06:59] I like having them broken down atomically, but I think that it’s actually something that we do sort of every day as developers.
[00:07:07] And I don’t know, maybe if there’s one skill that I feel like every developer should get really good at, it’s decomposition.
[00:07:15] And I think that could apply to a lot of different aspects of our dev life.
[00:07:19] We can take that from a few different angles.
[00:07:22] I think maybe the first angle we could look at.
[00:07:25] Looking at an epic or a story ticket and figuring out how to break that work up into smaller pieces or to decouple it, which it’s a learned skill that I feel like I kind of struggled with when I first started out doing software, because it doesn’t really have a whole lot to do with coding, depending on what it is you’re tasking with.
[00:07:55] And if you don’t take that time to kind of break it down and instead jump right into the code, you might miss this solution.
[00:08:07] And I can kind of talk more about that with some concrete examples, but I want to hear how that resonates with you.
[00:08:14] Yeah, I think definitely at a sort of product level, learning to break down larger sets of features into sort of individually shippable pieces is a really important thing.
[00:08:25] There’s a little bit of overlap, some of that is often done by project managers, but I think that as developers, that’s a skill that we need, as well.
[00:08:33] What do you think was helpful for you in terms of leveling up that skill?
[00:08:37] I think, honestly, one of the things that highlighted it for me was the interview here at ThoughtBot, because there was a question along those lines, which was like, how would you break this up?
[00:08:50] And I honestly, I’m pretty sure my answer was like the nightmare.
[00:08:54] Yeah.
[00:08:55] Yeah.
[00:08:55] Yeah.
[00:08:55] It was a very naive answer, which was, I was thinking about it almost like in terms of horizontal slices.
[00:09:03] So I was like, oh, okay, you know, you can work on the model in one PR and work on the controller in another PR, the view in another PR.
[00:09:11] And that is one way to break up the work, but it’s not going to result in necessarily the most effective way to ship it because you’re going to most likely be shipping dead code.
[00:09:24] Right.
[00:09:24] This is something that’s been…
[00:09:25] This is something that’s been mentioned on the podcast a lot, which has actually helped me.
[00:09:29] You know, so if you just work on the model separately, cool, that’s great.
[00:09:33] But like, there’s no interface for someone to interact with that model, whether it’s an API or like actually like a browser, right?
[00:09:41] You’re not delivering value.
[00:09:43] No, no.
[00:09:44] And not only that, but if you work in a, you know, vertical slice, that’s kind of what I’ve always referred to them as like vertical slice, meaning like, what is it?
[00:09:55] A feature that doesn’t introduce dead code and is something that introduces new behavior that can be interacted with, whether it’s like, you know, again, through like the web browser or an API or something like that.
[00:10:10] You try to work on thinking about it in terms of what behavior you’re going to introduce.
[00:10:17] I found it does one of two things.
[00:10:19] You have a much more informed way of building it because you’re not building it in isolation.
[00:10:24] So that virtually…
[00:10:25] The horizontal slices that I just mentioned, right?
[00:10:28] Like if you build the model in isolation, you aren’t being informed by how the user might be filling out the form to create that record in the database.
[00:10:38] And then you might end up getting it wrong and have to go back and change that code after it’s already been shipped.
[00:10:45] Whereas if you work on a vertical slice, you’re going to be informed by the actual behavior the user is going to be using to help you shape your…
[00:10:55] Not only your model, but your controllers or anything else in between.
[00:10:59] And once I understood that concept, it was helpful for me breaking down work.
[00:11:07] So that way I basically knew when I was given a task, I knew, one, let’s make sure it’s providing value.
[00:11:14] Like someone can actually interact with this when it ships.
[00:11:17] And then from there, I would think, okay, well, what’s the thinnest vertical slice I can ship here?
[00:11:25] Because otherwise…
[00:11:25] Otherwise, this PR is going to be sitting around for days, if not weeks, because it’s too big.
[00:11:32] And that was something I kind of struggled with once I had this realization of vertical slices, was how to break it down more.
[00:11:39] Right, because there’s two elements to this, right?
[00:11:41] There’s a sort of product-level concern of we want to be sort of continuously shipping value to customers.
[00:11:49] And then there’s a code-level concern that if you’ve got a thousand-line…
[00:11:55] PR, that just sort of really gums up the review process.
[00:11:58] It takes a long time.
[00:11:59] And you’re probably going to get lower-quality review on it.
[00:12:02] Absolutely.
[00:12:03] You know, I think we’ve all been in situations where you need a review PR that’s huge.
[00:12:07] And yeah, it’s challenging to review it.
[00:12:11] And yeah, sometimes the quality of that review isn’t great because it’s just too overwhelming.
[00:12:17] Are there some tricks that you’ve learned along the way to either help scope your stories more tightly or to break down code?
[00:12:25] So that it’s smaller in your PRs?
[00:12:28] Yeah, there’s a few.
[00:12:30] One is just speaking to the stakeholder and getting clarification on things.
[00:12:38] Because it’s possible…
[00:12:40] I try to look at things in terms of what is the outcome in terms of behavior.
[00:12:45] And just because a story is written in a particular way doesn’t mean it has to be that way.
[00:12:50] I think that is something that is often overlooked, right?
[00:12:55] Just because you are assigned a ticket doesn’t mean you need to just take it at face value.
[00:13:00] You can always change it.
[00:13:01] You can always talk to the stakeholder.
[00:13:03] So that’s one thing that could help you break it down, right?
[00:13:06] Because maybe the requirements don’t need to be as strict.
[00:13:10] Another thing is understanding if the code is even going to be…
[00:13:15] Maybe it’s behind a feature flag or something, right?
[00:13:17] So I know we talked about like…
[00:13:19] I’ve been mentioning like, okay, let’s get this in front of a user.
[00:13:22] But sometimes you can get away with having…
[00:13:25] You can get it behind a feature flag, but it still is a vertical slice, right?
[00:13:28] Like everything that went into it was informed by like user behavior.
[00:13:31] But you can ship it safely so that it’s not necessarily in front of a user.
[00:13:38] And that way you can kind of like iterate over it.
[00:13:40] So a very like contrab example, let’s just say we’re making a blog, right?
[00:13:46] And it’s like we could ship the whole thing, right?
[00:13:49] Where it’s like there’s a form with a title, a description, and tags.
[00:13:55] And that’s all well and good.
[00:13:56] But if it was behind a feature flag or something, or even not behind a feature flag, right?
[00:14:00] You could maybe do, okay, let’s just do title and body first, right?
[00:14:04] Like that’s…
[00:14:05] And if stakeholder is good with that, that’s fine.
[00:14:09] And then on the next pass, you can add a tagging system.
[00:14:12] And maybe on the next pass, you could add some type of commenting system.
[00:14:16] I guess if it’s like a front-end feature that’s going to be on a browser,
[00:14:19] I try to think about it in terms of like what are the fields on a form?
[00:14:23] Or what is the data that’s going to be displayed?
[00:14:25] And is it appropriate to remove some of that?
[00:14:28] Or like what’s the least amount of information that I can get on the page that adds value?
[00:14:33] Such that the commit is small so that it will be reviewed quicker and shipped quicker.
[00:14:39] Yeah, by thinking about it in terms of like the UI and having it be functional,
[00:14:42] that forces you to think about everything full stack.
[00:14:44] Because shipping some new fields on a form that aren’t wired to anything
[00:14:50] is now you’re breaking user experience.
[00:14:53] That’s not acceptable.
[00:14:54] So what do you…
[00:14:55] What do you need to do to wire up that one form field or two form fields
[00:14:59] in order to add and improve the experience?
[00:15:02] So you probably need to make some changes to a controller.
[00:15:05] You might need to make a change to a database.
[00:15:07] You might need to wire some other things up.
[00:15:10] But thinking about from the user’s perspective,
[00:15:13] adding that new behavior, what’s the minimum where it’s actually useful?
[00:15:17] And I like starting from the UI and working back.
[00:15:19] That’s a great tip.
[00:15:21] Yeah, I can give a concrete example from something I just did.
[00:15:25] A few weeks ago, but we were displaying some data on a dashboard
[00:15:28] and the final deliverable was going to be, you know, here’s a number.
[00:15:32] In this case, it was going to be paid time off.
[00:15:34] So here’s a number.
[00:15:35] You can click it and then a modal would appear
[00:15:37] and it would give each line item of like, how do we get to this number, right?
[00:15:42] And there’s a few ways that can be simplified.
[00:15:45] So the first could be speaking to a stakeholder and saying,
[00:15:48] is it acceptable to just render the final calculated value?
[00:15:52] And then in the subsequent PR, we can add the line item.
[00:15:55] And depending on requirements, maybe that’s not acceptable.
[00:15:59] Maybe it’s really important that people see how do we get to that number?
[00:16:02] But that’s, you know, that’s one way to simplify it.
[00:16:05] Another is if everything needs to be displayed, you could also just say,
[00:16:10] hey, do we need a modal right now?
[00:16:12] Or could we just show the calculated value in the line items?
[00:16:15] I’ll just kind of smack dab on the page without a modal component.
[00:16:20] And then, you know, in a subsequent PR, increase the fidelity.
[00:16:24] So that’s another.
[00:16:25] As an aside, every time I see a modal in a comp, I’m always like,
[00:16:30] oh man, like, can we just put this on the page normal and then deal with the modal later?
[00:16:37] It always adds just enough friction where I’m like, man, you know,
[00:16:41] so that’s my, that’s like the most concrete example I can give is,
[00:16:45] is personally when Steve Polito sees a modal and I’m trying to cut scope,
[00:16:50] that’s usually the first thing I want to go is just,
[00:16:53] can we just render this on the page, not in a modal?
[00:16:55] So please, you can try that.
[00:16:58] That’s my, that’s my quick tip.
[00:17:00] I’ve had conversations with thoughtbot designers where they’ve been very skeptical of sort of the proliferation of modals.
[00:17:06] Not that they never have a place,
[00:17:08] but that they’re sort of very often overused design element in terms of UI and that they can often be a crutch.
[00:17:14] Now I feel like I should probably have one of them on to the show and like explore this topic in more detail,
[00:17:19] because I think that’s something that maybe you build intuition for as a really sort of experienced UI designer,
[00:17:25] that’s not obvious to everyone else.
[00:17:27] And so everybody else just throws a modal at every problem and we complicate our lives unnecessarily.
[00:17:34] Right.
[00:17:35] Yeah.
[00:17:35] Yeah.
[00:17:35] And in this case,
[00:17:36] I mean,
[00:17:36] I think it was acceptable to have the modal in this context,
[00:17:40] but yeah,
[00:17:41] that’s just one way to kind of simplify the work such that it can be shipped quicker.
[00:17:47] I think there’s another element here as well,
[00:17:49] which is especially on projects a little bit more startupy,
[00:17:53] where you’re really trying to move,
[00:17:55] move fast and the opportunity costs of like spending a lot of time on one feature can be relatively high because you’re losing the opportunity to do a different feature by breaking things down into smaller chunks.
[00:18:09] You can iterate faster,
[00:18:10] but you can also then cut scope if any of the sort of follow up things end up being harder than you think.
[00:18:18] So sort of like you were saying for that,
[00:18:20] like breaking down the line items,
[00:18:22] maybe that summary is good enough.
[00:18:24] And after some initial like that goes live immediately because that’s a short task to do.
[00:18:29] And then based on feedback from users and talk with the product team,
[00:18:35] they realize,
[00:18:36] you know what?
[00:18:37] The sort of breakdown while nice doesn’t provide that much value yet.
[00:18:42] We would like to prioritize other features and then those get to bubble up to the top.
[00:18:46] Whereas if everything was in a package,
[00:18:48] now you’re just sort of committing to everything and you need at least the summary.
[00:18:52] That’s a non-negotiable.
[00:18:53] But you’re having to invest instead of,
[00:18:55] I don’t know,
[00:18:56] one day to get the summary.
[00:18:57] Now you’re doing a week to get the summary plus the breakdown that leads to sort of suboptimal outcome.
[00:19:05] So by being more granular with your stories in vertical slices,
[00:19:07] you get more flexibility for restructuring priority.
[00:19:12] Exactly.
[00:19:12] Yeah.
[00:19:13] The restructuring priority is a great benefit of that.
[00:19:15] It also means if that feature,
[00:19:19] especially,
[00:19:19] you know,
[00:19:19] it kind of in like the startup world where you’re just trying to ship quickly,
[00:19:22] maybe that feature isn’t even valuable to begin with.
[00:19:27] Like,
[00:19:27] you don’t,
[00:19:27] you don’t know until you actually ship it.
[00:19:30] And this is kind of similar to what you were saying,
[00:19:31] but imagine if you spent like two weeks on this dashboard and like turn the metrics tell you that like,
[00:19:36] well,
[00:19:37] no one’s looking at this page.
[00:19:39] Right.
[00:19:39] It’s a lot better to find that out quickly versus,
[00:19:43] you know,
[00:19:43] spending one or two sprints on it to find out,
[00:19:45] Oh,
[00:19:46] this was kind of a wasted effort.
[00:19:47] Right.
[00:19:48] So now I think we’re talking about working in a sort of iterative fashion.
[00:19:52] And what a lot of sort of agile sort of lean startup-y places will tell you is you want to reduce the length of those cycles.
[00:20:04] The tighter that feedback cycle,
[00:20:06] the faster you can respond to change,
[00:20:09] the more agile you can be.
[00:20:11] Yeah,
[00:20:11] absolutely.
[00:20:12] So we’ve been thinking a lot about decomposition at a sort of product and feature level.
[00:20:17] I’d like to zoom in a little bit more into code itself,
[00:20:21] because I feel like,
[00:20:22] there’s a lot of like writing good code that involves decomposition.
[00:20:27] I would talk a lot about composition in code,
[00:20:29] right? Composing objects,
[00:20:30] composing functions,
[00:20:32] which is great when you’re sort of putting together existing behavior,
[00:20:35] but someone has to build those components first and has to think about what are the parts that are reusable?
[00:20:43] Where are the like seams where you could break apart that code?
[00:20:47] And that’s decomposition.
[00:20:49] How do you get good at that?
[00:20:52] Yeah,
[00:20:53] that’s something I’m still working on.
[00:20:55] It’s kind of a process.
[00:20:57] I mean,
[00:20:57] if I’m my discipline is rails.
[00:21:00] So typically I just try to rely on conventions as much as I can.
[00:21:06] So I don’t even have to think about it.
[00:21:08] There are patterns in the community that are sort of well established and give you some pretty obvious places to break down complexity.
[00:21:16] Exactly.
[00:21:17] Yeah.
[00:21:17] So,
[00:21:18] you know,
[00:21:19] I’m always going to try to stick to rails,
[00:21:21] conventions,
[00:21:21] I also try to strike a balance between I don’t want to abstract anything too early because you know the wrong abstraction can always be worse than no abstraction at all.
[00:21:34] So I try to keep that in my back pocket too and especially you know it kind of it does go back to that iterative cycle in a way from a product standpoint where if you’re trying to get a feature in front of your users quickly you’re going to be relying on the feedback of those users.
[00:21:50] Yeah.
[00:21:51] And so for starters,
[00:21:54] one,
[00:21:54] maybe the feature isn’t even that valuable,
[00:21:56] it turns out.
[00:21:57] So it might be okay if you didn’t abstract away the logic into like a class or something.
[00:22:07] Like maybe everything is just procedural in the controller for the time being,
[00:22:12] but then that file never really gets changed because it wasn’t actually valuable and that feature was just deprecated.
[00:22:18] If there’s a lot of churn in that file or file,
[00:22:20] it’s okay.
[00:22:20] It’s okay.
[00:22:20] It’s okay.
[00:22:21] It’s okay.
[00:22:21] If there’s a lot of churn in that file or file,
[00:22:21] then that’s usually a clue like,
[00:22:22] okay,
[00:22:23] we should probably think about,
[00:22:26] you know,
[00:22:27] decoupling this a bit because now it’s getting a little out of control.
[00:22:30] Are there ways that you can use churn to help find the themes of where you should sort of make a boundary between two concepts?
[00:22:39] Yeah,
[00:22:39] this is,
[00:22:40] is there an answer to that?
[00:22:41] Like,
[00:22:41] is there,
[00:22:42] I’m sure there’s probably some command line tools you can run to see which files have the most churn,
[00:22:48] right?
[00:22:48] Like I,
[00:22:48] I haven’t actually done that yet.
[00:22:50] Yeah,
[00:22:50] you can,
[00:22:51] I think a classic one is a,
[00:22:52] it was a complexity versus churn.
[00:22:54] Okay.
[00:22:55] And so you find files that have high complexity and high churn,
[00:22:58] and that gives you a file that you can then break apart.
[00:23:02] But sometimes finding up,
[00:23:04] like it’s all tangled together.
[00:23:05] How do you figure out what to break apart from that sort of high value file?
[00:23:09] Yeah,
[00:23:09] that’s a great question.
[00:23:10] I mean,
[00:23:11] I guess if there is some duplication across the application,
[00:23:16] right?
[00:23:16] So if you happen to notice similar business logic being applied in multiple places,
[00:23:20] that hasn’t been extracted yet,
[00:23:23] that’s a good case to extract that into like a service object or something like that.
[00:23:28] I guess it would depend on the responsibility of what that code is doing.
[00:23:32] Like if it’s,
[00:23:32] if it’s asynchronous or not,
[00:23:35] I think that’s one way to determine where it could go,
[00:23:37] right?
[00:23:37] Like should this stuff live in a job or not?
[00:23:40] That’s one way to look at it.
[00:23:42] Another is like,
[00:23:43] is this just presentational?
[00:23:45] If it’s presentational,
[00:23:46] there’s other ways we can handle that.
[00:23:48] I think those are kind of some starting points.
[00:23:50] So look into sort of patterns of either responsibilities or usage and sort of
[00:23:57] try to cluster around that or use those as almost,
[00:24:00] I imagine you have like a junk drawer of stuff and you’re just sort of putting
[00:24:05] two or three big magnets around the edges for different things and just sort of
[00:24:08] pulling things towards one magnet or another based off responsibilities or time
[00:24:13] access,
[00:24:14] that kind of thing.
[00:24:16] Yeah,
[00:24:16] exactly.
[00:24:17] I like that.
[00:24:18] That’s a good visual.
[00:24:19] I like that.
[00:24:20] And then,
[00:24:20] I mean,
[00:24:20] for me personally,
[00:24:21] I would,
[00:24:22] if it’s like a new project without too many patterns yet,
[00:24:26] I would just try to rely on our ThoughtBot guidance and also the Rails guidance.
[00:24:31] If it’s an established project that already has its own conventions,
[00:24:35] you know,
[00:24:35] I would just lean into whatever those may be.
[00:24:38] I had a thought the other day when I was thinking about the idea of decomposition.
[00:24:43] And when you’re decomposing tickets or even sort of commits,
[00:24:48] we often talk about trying to break things apart.
[00:24:50] We often talk about trying to break things down to sort of an atomic level where it doesn’t really make sense to break down further.
[00:24:56] So an atomic story is sort of that thinnest vertical slice.
[00:25:00] An atomic commit is sort of a commit where I guess you could have some controversy around what is an atomic commit.
[00:25:07] I tend to define it as the smallest amount of code that adds value,
[00:25:11] is not dead,
[00:25:12] and like passes CI,
[00:25:14] is deployable.
[00:25:15] What is an atomic unit of code when you’re doing decomposition?
[00:25:20] Right?
[00:25:20] You’ve got a file that’s a junk drawer.
[00:25:22] What is the sort of atomic level where you can’t really break it down further?
[00:25:26] This is the smallest piece of something that can stand on its own.
[00:25:31] I mean,
[00:25:31] the first thing that comes to mind is like a method or maybe even like a constant,
[00:25:37] but that by itself doesn’t really add.
[00:25:41] I mean,
[00:25:41] I guess we’re talking about atomic code,
[00:25:44] right?
[00:25:44] So I guess by itself it is just a small thing.
[00:25:46] It’s just one line.
[00:25:47] So yeah,
[00:25:48] I don’t know.
[00:25:48] I think my knee jerk reaction would be,
[00:25:50] would be something like a constant or a variable that may be like a molecule would be a method.
[00:25:57] And then from there a class might be an organism.
[00:26:01] I’m like mixing names here,
[00:26:04] but you,
[00:26:04] you get what I’m saying and the whole being,
[00:26:07] I guess itself would be the application.
[00:26:09] But yeah,
[00:26:09] I think final answer constants are small or maybe print,
[00:26:14] but then,
[00:26:14] but then there’s primitives too,
[00:26:15] right?
[00:26:15] But that’s,
[00:26:16] I guess a different thing altogether.
[00:26:18] I’m curious what you think though.
[00:26:19] I,
[00:26:20] I trust you’ve given this more thought than I have.
[00:26:22] I want to hear what you have to say about this.
[00:26:24] My sort of go-to I think is thinking a method or a function.
[00:26:27] If you’re in a functional language,
[00:26:29] I think a constant or variable is probably also a good choice.
[00:26:33] Those tend to be more static though.
[00:26:35] So maybe the sort of atomic piece of data is a variable,
[00:26:42] but an atomic piece of behavior is a method.
[00:26:45] What I think is important though,
[00:26:46] it’s,
[00:26:46] it’s a thing with a name because the thing with the name,
[00:26:49] can be composed with other things because you have something to reference it
[00:26:53] with.
[00:26:54] Whereas something that doesn’t,
[00:26:56] you don’t have a way to,
[00:26:57] to reference it.
[00:26:57] So I’m imagining complex code,
[00:27:00] right?
[00:27:01] And you’ve got a conditional with a bunch of different branches.
[00:27:05] Somewhere else wants to reuse the behavior in one of the branches of that
[00:27:11] conditional.
[00:27:12] You can’t do that.
[00:27:13] You can’t just say,
[00:27:15] Hey,
[00:27:15] I want this branch of a conditional,
[00:27:18] you know,
[00:27:19] and sort of,
[00:27:19] older school code that has like a go-to command,
[00:27:22] right?
[00:27:22] You can go to jump to particular lines,
[00:27:24] but that’s at that point,
[00:27:26] you’re effectively creating your own sort of conditional logic,
[00:27:29] but in a language like let’s say Ruby or JavaScript,
[00:27:32] you can’t just reference a particular line in a conditional.
[00:27:37] If you want to do that,
[00:27:38] what you have to do is you have to extract that behavior from the conditional
[00:27:41] into a standalone method or function,
[00:27:45] reference that from the conditional,
[00:27:46] and then other places can also reference it.
[00:27:48] And so I’m thinking,
[00:27:49] in terms of like,
[00:27:50] I’ve got complex code and I want to break it into smaller chunks that can
[00:27:53] be remixed.
[00:27:55] I think your initial gut reaction,
[00:27:58] if it’s a method or a function is probably the correct one.
[00:28:02] Yeah.
[00:28:02] I’m with you on that.
[00:28:04] I’m with you on that.
[00:28:05] And that’s a,
[00:28:05] I like that something with a name that,
[00:28:07] that has behavior.
[00:28:08] That’s a great way to look at it.
[00:28:10] And I think that maybe helps explain,
[00:28:12] I have a series of heuristics that I use for breaking down code into
[00:28:16] smaller pieces that I call the,
[00:28:18] the triangle of separation.
[00:28:20] So it’s three principles that say,
[00:28:23] write code is single level of abstraction,
[00:28:25] separate branching code from doing code and push conditionals up the decision
[00:28:31] tree.
[00:28:32] And when you dig into all of those,
[00:28:35] what they all sort of push you towards doing is pulling logic out into
[00:28:39] smaller functions that can then be composed back together.
[00:28:43] So if I give an example from the first one or the,
[00:28:46] the one about the separating branching code from doing,
[00:28:48] that says that a method or function that has conditional in it.
[00:28:52] So an,
[00:28:52] if else doesn’t get to have both the conditional logic and the
[00:28:57] implementation.
[00:28:58] So if you have an,
[00:28:59] if else,
[00:28:59] the only thing you can do from an,
[00:29:00] if else is call another function.
[00:29:03] And if a function has actual logic,
[00:29:05] do this thing,
[00:29:06] do this thing,
[00:29:06] do this thing,
[00:29:07] or calculate this thing,
[00:29:09] I can’t have conditions in it.
[00:29:11] So functions are either branching or they’re doing,
[00:29:13] they don’t do both.
[00:29:14] And what that does is basically every time you encounter a conditional,
[00:29:18] it’s like,
[00:29:18] it forces you to split out functions.
[00:29:21] So now you have a bunch of little pieces that can be composed together.
[00:29:27] And part of the reason that’s valuable is that wanting to have access to a
[00:29:31] branch of a conditional is a thing that you end up wanting to do more often
[00:29:35] than you think.
[00:29:36] And so having a sort of pre-made already usable as a function is really
[00:29:40] convenient.
[00:29:41] Yeah.
[00:29:41] I like that.
[00:29:42] I’m curious what,
[00:29:44] cause I’m with you with those heuristics.
[00:29:46] Like I,
[00:29:47] those resonate with me.
[00:29:48] What led you to those?
[00:29:51] Was it just experience over time?
[00:29:53] Like,
[00:29:53] was there an aha moment or was it just after like a decade,
[00:29:56] you look back and you were like,
[00:29:58] Oh yeah,
[00:29:58] this is kind of where I’ve been.
[00:30:00] I’ve been going towards this path for a while now.
[00:30:02] And I,
[00:30:03] I’ve probably been here for a while and just didn’t realize it.
[00:30:06] It was a little bit of both,
[00:30:07] but there was definitely an aha moment that came while I was doing a lot of
[00:30:12] Elm.
[00:30:13] And Elm has this concept of a maybe type.
[00:30:17] It’s a value that it has.
[00:30:18] It is potentially null.
[00:30:21] And every time you want to access a value that’s potentially null Elm’s
[00:30:26] compiler will force you to make a null check.
[00:30:28] And that gets really annoying as you’re passing a nullable value
[00:30:33] throughout a system and having to do a null check all the way down the
[00:30:37] line gets really clunky.
[00:30:39] And so what you end up doing is you tend to either not do anything to it
[00:30:45] and just sort of pass it all the way down the line and then unwrap it at
[00:30:48] the end.
[00:30:48] Check whether it’s null or not,
[00:30:50] or you’ll unwrap it at the beginning and have a branch for if the value’s
[00:30:56] null,
[00:30:57] and then you just sort of in there,
[00:30:58] then you have a continuing branch for things that are for the path.
[00:31:01] It’s not,
[00:31:02] not nullable.
[00:31:03] And the way that Elm does this is that it provides a way to just say,
[00:31:07] run this function on this value if it is present.
[00:31:10] And so what you end up doing that function,
[00:31:13] really what it’s doing is abstracting away the conditional that if null
[00:31:18] due to null,
[00:31:18] nothing otherwise do this thing and the actual behavior that should only
[00:31:24] care only be executed if the value is present that you create a separate
[00:31:27] function for.
[00:31:29] And so I was exploring patterns around how that worked and the idea of
[00:31:35] separating your business logic that doesn’t need to know whether a value is
[00:31:40] nullable or not.
[00:31:41] Just say,
[00:31:41] assuming the value is present,
[00:31:42] here’s the business logic I want to run.
[00:31:45] So all of your business logic functions are written in a very confident
[00:31:48] style.
[00:31:48] Because they can assume,
[00:31:50] in fact,
[00:31:50] the compiler guarantees that they’re present.
[00:31:54] And then the nulls and the presence checking all gets done sort of
[00:31:58] separately.
[00:31:58] That’s a separation of logic right there.
[00:32:01] And so then I started wondering,
[00:32:02] are there other places you can start doing that?
[00:32:04] And I started expanding that to other forms of uncertainty and then started
[00:32:08] realizing,
[00:32:09] wait,
[00:32:09] this is just,
[00:32:10] if I strip away all the syntax from the language,
[00:32:13] all this is doing is separating code that does conditionals from code that
[00:32:17] does business logic.
[00:32:18] And the business logic functions don’t do conditionals.
[00:32:21] They just do their business logic,
[00:32:23] assuming that they’re on the right path and it’s up to you to compose them
[00:32:26] later.
[00:32:27] So it’s a very compositional approach that Elm has that was an aha moment for
[00:32:31] me.
[00:32:32] Thank you for walking me through that.
[00:32:34] And I’ve benefited from your,
[00:32:36] your learnings just by listening to this podcast.
[00:32:39] Cause I’ve,
[00:32:40] I’ve heard these and read these several times for you.
[00:32:43] And even though we don’t always work together on projects,
[00:32:46] you’re kind of working with me without,
[00:32:48] without realizing it.
[00:32:49] Cause I’ll think,
[00:32:49] okay,
[00:32:50] you know,
[00:32:50] I’m coming to a fork in the road here.
[00:32:52] What should I do?
[00:32:53] Should I,
[00:32:53] how should I break this down?
[00:32:54] And I come back to those heuristics.
[00:32:56] So thank you for that.
[00:32:58] Are there any sort of heuristics or refactoring patterns that you’re
[00:33:02] particularly fond of?
[00:33:04] I think it depends on the project I’m on in terms of like,
[00:33:08] I’ll try to do whatever the project is doing.
[00:33:12] That’s my general heuristic is like,
[00:33:14] I don’t want to introduce a different way of doing something on a project.
[00:33:18] I’m joining,
[00:33:18] unless I think there’s a good reason to use that approach.
[00:33:22] Yeah.
[00:33:23] I don’t know.
[00:33:24] I mean,
[00:33:24] the things that you mentioned,
[00:33:25] I try to do,
[00:33:26] I’m always kind of caught between like,
[00:33:30] how small can I make this diff?
[00:33:33] Because then it’ll just probably pass code review much quicker.
[00:33:39] So that’s one thing I like to do,
[00:33:41] but then I also struggle because I’m like,
[00:33:42] well,
[00:33:43] you know,
[00:33:43] Hey,
[00:33:43] that’s sure.
[00:33:44] This is like a two line change and it’s super easy to read,
[00:33:47] but,
[00:33:48] is there an opportunity to refactor this and like maybe follow a better pattern?
[00:33:55] And that’s something I kind of struggle with.
[00:33:56] I never know the answer because the abstraction could take an extra day or two
[00:34:00] and it may not add any immediate value right away,
[00:34:03] especially kind of to go back to the churn discussion earlier.
[00:34:06] Like maybe the thing I’m working on has very low churn and low complexity.
[00:34:11] So it probably wouldn’t really benefit from being abstracted,
[00:34:14] especially if we’re just trying to iterate through things.
[00:34:16] But yeah,
[00:34:18] I mean,
[00:34:18] in general,
[00:34:19] I like to keep commits very small.
[00:34:21] This isn’t so much a coding heuristic,
[00:34:23] but I,
[00:34:23] I just always try to explain the why and not the what in my commit messages.
[00:34:30] I love that.
[00:34:31] Yeah.
[00:34:31] And the best is when the ratio is like a hundred to one.
[00:34:35] So like you have a one line diff,
[00:34:37] but you know,
[00:34:38] the PR description is like a short story.
[00:34:41] Those are always fun,
[00:34:42] right?
[00:34:42] Cause it’s like,
[00:34:43] wow,
[00:34:43] this is a significant change.
[00:34:45] What’s going on here?
[00:34:46] Yeah.
[00:34:46] Like when that happens,
[00:34:48] I feel like commonly for me,
[00:34:49] those have been like really tricky bugs where I’ve spent like a full day just
[00:34:54] hunting down the bug.
[00:34:56] And so the commit message might have that whole story of the journey I went on
[00:34:59] that day,
[00:35:00] but then also maybe some of the tests and things I ran that proves that this
[00:35:05] is in fact the source of the bug or the explain like why this like sort of
[00:35:09] random config change here actually is the cause of the bug.
[00:35:12] So like laying out the chain of evidence for me,
[00:35:15] that’s commonly,
[00:35:16] if it’s a one line change and paragraphs of text in the commit message,
[00:35:20] it’s going to be a bug fix.
[00:35:23] Exactly.
[00:35:23] Yeah.
[00:35:23] And that’s when you want to really add as much detail as possible.
[00:35:27] If nothing else,
[00:35:28] it’ll just benefit you like two weeks later when you’re like,
[00:35:31] why don’t I do this again?
[00:35:32] Cause I always forget why I did the thing.
[00:35:34] So it’s good to look back at that.
[00:35:36] So I’d like to sort of zoom out a little bit and ask you to speculate a little
[00:35:41] bit right now.
[00:35:44] There’s a lot of hype around AI.
[00:35:46] And AI assisted coding and sort of at a surface level,
[00:35:51] it seems to me that being good at decomposition might make you a better AI
[00:36:00] assisted developer.
[00:36:01] Any thoughts on that?
[00:36:03] Yeah.
[00:36:03] As in,
[00:36:04] if you’re,
[00:36:05] if you’re good at breaking things down,
[00:36:07] both stories and code,
[00:36:09] AI will be able to help you do your job better.
[00:36:12] Right.
[00:36:12] You get better outcomes.
[00:36:14] Yeah,
[00:36:14] I agree with that.
[00:36:16] Cause,
[00:36:16] well,
[00:36:16] let me think about this.
[00:36:17] I can,
[00:36:17] I can see it going two ways.
[00:36:19] Cause I know AI likes to have as much context as possible.
[00:36:24] So if I’m breaking something down as small as possible and feeding it into the
[00:36:29] AI,
[00:36:30] it may not have all the context that it needs.
[00:36:32] So that’s just,
[00:36:33] I’ll leave that there.
[00:36:35] I’m not sure.
[00:36:36] I’m not sure what to think about that,
[00:36:37] but I also know when you’re working with AI and you’re trying to solve a
[00:36:41] particular problem.
[00:36:42] I mean,
[00:36:43] it’s good to focus on that particular problem and not have all the
[00:36:46] unnecessary data in there.
[00:36:48] Right.
[00:36:49] So scoping things down,
[00:36:50] maybe can help the AI have a smaller problem to solve.
[00:36:54] Potentially it’s harder because it has less context.
[00:36:57] Sometimes you can break things down,
[00:36:58] but not like exclude that from the context.
[00:37:01] So maybe you give it a,
[00:37:03] instead of saying,
[00:37:04] here’s a problem I want you to solve it.
[00:37:06] You can say,
[00:37:06] here’s a problem.
[00:37:08] And here’s five steps I want you to take to solve it.
[00:37:11] I think even sort of a micro version of that,
[00:37:14] that people sometimes do with like a get,
[00:37:16] hub co-pilot is writing a comment above a method for sort of like,
[00:37:20] here’s sort of five steps of what the algorithm needs to do,
[00:37:23] you know,
[00:37:24] like pseudocode or even just straight up pros,
[00:37:26] then co-pilot will fill it out.
[00:37:28] Mostly correct based off of that.
[00:37:31] Right.
[00:37:32] Yeah.
[00:37:32] And the thing I,
[00:37:34] so I do think being able to break down your work will help you be a
[00:37:36] better AI assisted developer.
[00:37:39] The one thing I’m a dork.
[00:37:42] So I,
[00:37:43] I like solving problems.
[00:37:45] And that’s not to say I don’t leverage AI,
[00:37:48] but I,
[00:37:48] I find that if I can do the work myself,
[00:37:52] it’s not necessarily going to be better than what AI can do,
[00:37:56] but I’ve like,
[00:37:57] I’ve retained the thing that I’m trying to do.
[00:38:01] And that that’s really important to me.
[00:38:03] And a concrete example of where I’m doing the opposite is I am a really
[00:38:09] bad speller.
[00:38:10] And I just,
[00:38:11] I’m like,
[00:38:11] Hey,
[00:38:12] spell check,
[00:38:13] do this for me.
[00:38:14] And I’ve,
[00:38:14] I’m so reliant on spell check that like,
[00:38:17] I can’t spell to save my life because I’m just,
[00:38:21] I had,
[00:38:22] there’s no retention there because spell check does it for me.
[00:38:25] But the opposite is,
[00:38:26] is what I’m trying to do with programming,
[00:38:28] which is like,
[00:38:29] I want to actually know what it is that I’m doing here.
[00:38:33] So I try to do that as much as I can.
[00:38:36] And obviously if I’m like,
[00:38:37] if it’s a complete roadblock or a concept,
[00:38:40] I have no idea about sure.
[00:38:41] AI is a great tool and I use it frequently,
[00:38:44] for stuff like that.
[00:38:45] But if I’m basically the topic of this is like,
[00:38:49] can you breaking things down?
[00:38:50] Decoupling can be helpful,
[00:38:51] helpful.
[00:38:52] If you’re able to understand how to break the work down,
[00:38:56] hopefully it’s not too overwhelming for you as a developer because you’re
[00:39:00] just,
[00:39:00] you’ve isolated the thing you need to work on and you can not worry about
[00:39:04] anything else.
[00:39:05] And especially if you have a corresponding test for it too.
[00:39:09] And breaking down can be at all sorts of different levels,
[00:39:11] right?
[00:39:11] It could even be at a like full on system level.
[00:39:14] Here,
[00:39:14] we’re going to want something that has like these subsystems.
[00:39:18] We’re going to like interact with them in such and such a way.
[00:39:22] So if you’re designing some kind of like authentication system,
[00:39:25] oftentimes you need to sort of think in terms of larger pieces,
[00:39:28] you know,
[00:39:28] you’re doing an OAuth integration.
[00:39:29] You’ve got to think about a provider versus a consumer and thinking in
[00:39:34] those terms becomes helpful.
[00:39:36] But then,
[00:39:36] yeah,
[00:39:36] like we said,
[00:39:36] we can zoom all the way in where you’re like,
[00:39:38] all right,
[00:39:39] here are the different steps of my algorithm.
[00:39:41] Here are the different sort of sub methods that I’m going to want.
[00:39:44] I’m going to sort of everything in between.
[00:39:47] My sort of hypothesis is that decomposition,
[00:39:51] it’s a core developer skill today when you’re doing everything manually and
[00:39:55] that it will only become more valuable in a world where we have a larger
[00:40:01] presence for AI assisted tooling.
[00:40:04] Yeah,
[00:40:04] I can see that.
[00:40:05] And I guess,
[00:40:06] you know,
[00:40:07] uh,
[00:40:07] that is speculation.
[00:40:08] So check in again on the bike shed and a year or two and see if this is
[00:40:13] right or wrong.
[00:40:14] I think you got it.
[00:40:14] You got,
[00:40:15] or you can ask AI right now.
[00:40:16] What do you think?
[00:40:17] You can always ask it in its opinion too.
[00:40:19] That’s right.
[00:40:19] What are going to be the core developer skills in an AI assisted world?
[00:40:24] Cause it’s probably not going to be like a deep understanding of the minutiae
[00:40:28] of syntax.
[00:40:28] Right?
[00:40:29] No,
[00:40:29] I don’t think it’ll be that.
[00:40:30] I think it’s going to be something,
[00:40:32] you know,
[00:40:32] you’re still going to want to understand the system to kind of go back,
[00:40:36] like the whole spelling thing,
[00:40:37] right?
[00:40:38] Like it’s going to be like,
[00:40:39] you know,
[00:40:39] you’re going to want to understand the system to kind of go back to the whole
[00:40:42] spelling thing,
[00:40:43] right?
[00:40:43] Like if you don’t have like the retention or understanding of the system
[00:40:46] you’re working with,
[00:40:47] that’s probably not going to be good for you.
[00:40:49] So as a human,
[00:40:50] you’re always going to want to know that otherwise that will be a challenge for
[00:40:54] you and the team and the product you’re working on.
[00:40:56] If like no one or if even if collectively all the
[00:41:01] humans on the project don’t quite understand how everything works,
[00:41:05] that would be a concern.
[00:41:07] So the ability to break things down is always going to be helpful.
[00:41:11] Yeah.
[00:41:11] And having something help with sort of the minutiae can be,
[00:41:13] can be time-saving.
[00:41:15] You’re an author writing them,
[00:41:16] writing a book spellcheck is useful.
[00:41:19] Even if maybe it does mean that you rely on it more than you’d like your job
[00:41:23] as an author is not so much focusing on remembering the correct spelling for
[00:41:28] every word you’re trying to communicate ideas,
[00:41:30] tell stories,
[00:41:32] structure arguments.
[00:41:33] That’s the level that you’re really putting most of your effort in.
[00:41:36] And so a little bit of help on the spelling,
[00:41:38] even if it is a crutch sometime,
[00:41:40] I think is a win in the end.
[00:41:42] Yeah.
[00:41:43] AI for the minutiae,
[00:41:44] big plus one for that.
[00:41:45] I love it for that type of stuff because then you can just focus on the stuff that matters.
[00:41:50] Well,
[00:41:50] I feel like at some point I might have to have you come back on for a real dive into AI.
[00:41:56] This was an episode more on decomposition in general,
[00:42:00] but yeah,
[00:42:01] it sounds like there’s some,
[00:42:02] definitely some thoughts percolating there on the use of AI as a development tool.
[00:42:05] Yeah,
[00:42:06] absolutely.
[00:42:06] I love that.
[00:42:07] All right.
[00:42:07] Well,
[00:42:08] Steve,
[00:42:09] thank you so much for coming on the show.
[00:42:10] Yeah.
[00:42:10] Thank you for having me.
[00:42:11] This was a lot of fun.
[00:42:12] And on that note,
[00:42:13] let’s wrap up.