Doing work that's essential but not important - podcast episode cover

Doing work that's essential but not important

Mar 10, 202514 minEp. 482
--:--
--:--
Listen in podcast apps:

Summary

Caleb discusses the crucial distinction between important and essential work, highlighting how essential tasks, though often overlooked, are vital for achieving world-class quality. He shares examples from his own work on the Flux component library and documentation, and emphasizes that consistently addressing these non-urgent but essential tasks is key to delivering exceptional products that stand the test of time.

Episode description

The podcaster did not provide a description for this episode.

Transcript

All right. So something... Here's a thought for you. There's important work that's essential. Important meaning in demand. And essential meaning... Has to be done. And then, and that's obvious. That's just work that you know you have to do. Then there's important work.

or sorry there's essential work work that's got to be done but it's not important nobody's yelling at you to do it there's plenty of other high priority tasks and this is kind of an interesting thing that i want to talk about and i think i just kind of stumbled into this uh yesterday so i'm working on the call out component you heard me talk about that working on

the documentation page for the call-out component and putting a lot of effort into it like pretty proud of where it's at making sure every single example is unique and custom and not not phoning it in at all you know every bit

Writing a lot, designing a lot, making sure dark is good and responsive is good and all that stuff. The API is clean and crisp and perfect. Just leaving no stone uncovered. Really excited about it and proud of it. Great. But I get to the bottom of the docs page and I realize... the like the only thing that is preventing this page from being like a flagship documentation page that i'd be like you want to go check out flux go to the call out page i'm proud of that you know

is that there's no reference documentation at the bottom so there's no like here's all the available components by name here's all of their props and slots with their types and their defaults and descriptions of each and blah blah blah It's just missing entirely from the flux docs because it just never happened because it was never important. But I do consider it essential.

I get enough requests for it, I guess. Like, I don't hear about it a lot, but I know it's something that has to be done. I know if I were browsing, you know, basically as the creator, it's one of those creator holes. that as a creator of something you use i source dive the flux source all the time like as i'm using it i'll just open up like the blade file for the button component and remind myself what sizes are available like that kind of thing

But the majority of people do not source dive. So they do not. In fact, I saw somebody tweet today that they, oh, well, whatever. Okay. Yeah. So as the creator. You don't feel like API reference docs are that essential. I don't really go to them. I would first go to the source code as the source of truth. But...

Most people are not going to do that. If they want to know, oh, what sizes are available? They're going to want to scroll down, find a size prop and see what's available. And then while they're there, they're going to search through other ones and go. Oh, that's pretty cool. Oh, there's a description trailing prop. I didn't know that. Or like, oh, this accepts, you know, oh, the tooltip accepts a gap and an offset in addition to the position. That's cool. I didn't know that.

and now i know okay whatever you get it you get why they're essential right for this to be like a really clean good documentation page api reference docs are essential however they're not important so they're never going to get done

And this isn't something that I necessarily thought about. As I was doing this though, I was like, to make this callout page perfect, I need to have reference docs and I can't just have it on one page. So I built it for the one page and just started pulling the thread. How hard would it be to add it to every page? How much can cursor help me? You know, and it, it's getting better by the way, cursor, sonnet, um, Claude sonnet.

3.7 thinking mode in cursor with composer in agent mode if you do that it's pretty impressive what it can do um so today i'm spending my day so i mean thankfully this is something that if i did it by hand it probably would take me i don't know maybe three days but with cursor it's taking me i guess a half a day you know i'll say do it and i said if i started front to back and really put my head down i bet i could do it in a single day with cursor's help

But now I'm doing the long, arduous process of going through every single thing that Cursor wrote, removing hallucinations, adding things that it can't discover, reworking it all, you know, whatever. Definitely grateful for it.

in situations like this heavy manual labor situations cursor or whatever any sort of ai is super helpful um okay back to what we're talking about api reference docs is what we're talking about So add the API reference docs because for this to be great, they need to be done, which means that that's a signal right there, that essential things stand in the way of greatness.

not doing essential things like essential tasks that haven't been done that that is the thing that is preventing your thing from being perfect or great or world-class you know it's really this category of thing often Words like attention to detail, thorough, those types of words get ascribed to what I'm talking about. Not important. but essential work and by essential again i think another definition of it is the category of things that if not done sorry for the double negative prevents you

prevents your thing from being great or flagship or world-class, prevents your thing from being world-class. What are the things standing between your thing and it being world-class that people aren't asking you for? Those are the things I'm talking about. So it was just sort of, I've realized that this is in a category of work that things that will never get done, things that just won't get done if you're always going by.

priority or importance or whatever so if you have your to-do list which you always do your whether it's written or not it's a roving to-do list of things that have to get done and it's often ranked in order of demand It's how loudly people are asking you for this thing or whatever. That's just often how it's naturally ranked. And it often also makes most sense to work from the top. Do the most important thing next, right? But if you do that...

If you stay in that zone, everything below the fold of your to-do list will remain undone forever because it will never be important enough to get done.

you know on its own um so this is where you just have to like i think this is just a a methodology to adopt and i'll call it like exhaustive task completion maybe it's like this is how you should do it you order and this is another thing that's been ringing around my well actually this kind of comes full circle um kitsy on twitter let me find his tweet so this morning

He tweeted this little conversation with himself that I thought was really, I don't know, like I've been here a hundred times. Can I find it? Okay. So yesterday he tweeted this. He said, me, hmm, I'm wondering what do users want? Users, hey, Google Calendar integration, when? Me, it's such a complex thing to figure out, users.

Google Calendar integration, please. Me, I should add analytics and tracking. Users, can we get Google Calendar integration? Me, I should build a platform. Users, Google Calendar. Okay, so it's back and forth, whatever. And this kind of resonated with me because it's funny that...

This seems silly when you read it in a tweet. You're like, oh yeah, you're dumb. Just listen to the users. They're telling you what to do, but you're doing everything but. But in reality, I think this is honestly the way most... operations operate like i find this trap myself and i it'd be interesting to figure out why this is but this is true for my own endeavors it's like

People are, and that's why I've recorded about this before, but it really is a magical thing if you just do the thing the users want. Users are telling you what to work on. Just work on that thing. I've been trying to adopt that with Flux. Really what you have to do is you have to let go of a lot of your own notions about what should be done in the way it should be done, I guess. Like, I don't know.

it's tricky it's all a balance because you also need to maintain in the integrity of the create like being the creator and the designer you have to have strong opinions and hold them even if the users tell you otherwise um but that yeah it's a mixture but you have to listen to users and a really good default to like building a successful product or something it's just building the things your users are asking for you know

That's what it is. You have to do it responsibly. That's the tricky part. That's up to you. Um, but ultimately you should be doing those things. And it's funny how the things that the users want most, you end up not doing often. So that tweet I thought was pretty funny, but okay. Back to what we're talking about important.

non-essential work or not important essential work wow what a dumb way to say it there's probably like a matrix here of importance and essentialness for tasks and but i don't know i'm but i want to keep it kind of simple keep the discussion simple um yeah so you have to adopt this methodology of doing exhaustive work you work from the top you do the most important work the work that users are asking you for the most it's in the highest demand and then

You figure out everything that goes into making that a world-class solution. That's what it is. And honestly, this is... Wow. I'm a genius. I am so profound. I joke because this is very simple, but I think this is a part, if I've had any success, I think this is a big part of why. And this is the way to do work. You build something. And then you listen to what people want. And then you figure out what it would take to deliver that want.

on a world at a world-class level and then you start working towards that like in sync methodically even if it takes you years and I say years because there are things that Like this even sort of applies on a meta scale, like flux in general, like a component library in general is something that I've punted on for a long time, but it's really that like people want a component library.

Okay, I will build them a component library. But first, to do that on a world-class level, the tool underneath it has to have X, Y, Z, H, Q, P, Z, F. before we can get to that you know before we can build a ui component library that i'm really proud of all these other things need to happen and that can take years all my like yeah

similarly there are other things like let's say livewire native or something it's like if if there was enough demand for that if that's what the users wanted it would be like okay well we have to set ourselves up for that you know and that okay you get what i'm saying it's like

Work in order of priority and demand and importance, whatever, because that's the thing that is going to make your users happy. Giving users what they want makes them happy. That's just a truth, okay? It's a simple truth and surprisingly elusive. Give your users what they want. It will make them happy. But as you're doing so, do everything that's needed to make each of those things world-class, even if it means going slower.

Because, yeah, if you don't do things exhaustively, the non-important essential tasks like API reference documentation, search on the docs, dark mode on your, all of those things, whatever it is, responsive, all those little details. I mean, I'm just using a doc site as an example.

Good syntax highlighting with line highlights. These are things that actually flux is falling short. The syntax highlighting is the next step. Nobody's going to tell me your syntax highlighting needs to be overhauled. Caleb, go spend a week on syntax highlighting. Nobody's going to tell me that. But I know. That you cannot browse Flux and think it is perfection if you come across a code block of PHP that is not syntax highlighted at all. You can't.

There's no perfection there. So yeah, anyway, I don't know. These are all thoughts, but there is something here. Yep. Do. essential not important work in sync refactor as you go sneak it in to your workflow if you're on a scrum team or whatever sneak refactoring in don't

Don't have it as its own line item because it'll never get done. It's not important. Users are never going to ask for a refactoring. So stuff like that has to be done as you go. And it makes you slower in the process. Absolutely.

But the product that you deliver is world-class, and that shows, and that lasts, and that's the only way. If you only listen, if you only do things in order of demand and importance, you go too fast, you stumble over yourself, you have half-baked solution, whatever. But do... yeah okay you hear what i'm saying i'm just saying the same thing over and over again have a good day let me end this thing

This transcript was generated by Metacast using AI and may contain inaccuracies. Learn more about transcripts.