Thoughts by human, co-written by AI

I feel like I wanna write an article about maybe this will be the title: In the age of abundance, less is more. So, in the age of abundance, less is more, and I think I am slowly realizing this retroactively, that now that you can build lots and lots of new capabilities, features, and all of that, yeah, you should not necessarily build everything that comes to your mind. And an interesting aspect that I want to explore more is from the perspective of working on several ideas or several multiple pathways all at the same time. For example, at work, you could be working on four or five different projects and work streams, and you're doing well in all of them. You don't feel like you're spreading thin because you're able to achieve so much more with AI agents, like helping you. You're pulling off all these, like, feeds that look really good on paper, and in practice as well. You're doing a lot more work, output. Each work stream is progressing. However, it is weird. The same problems do not apply necessarily. For example, I don't feel like I'm spreading thin. However, I don't really know exactly what or how or why, but I feel like there is something wrong that's going on when you are tackling five, six different work streams. For example, at work right now, I'm owning, like, and driving two projects, and at the same time I'm working on the resilience and reliability of testing infrastructure. I'm working on making sure there is a full visibility into this, like, work that I'm doing. For example, whenever I'm building and improving the speed and resilience and reliability. Of the testing infrastructure, I want to be able to see the results that I am achieving. So I'm building this insights dashboard or tooling to be able to see into it. At the same time, I'm also working on the development tools that enables much higher engineering velocity. So that's another thing that more or less I have already built. And now I am more laid back in that work stream in the sense that I'm using it heavily, but I'm not actively making changes over and over. However, what I did was that every time I use this development tool that I built specifically for my project that I'm working on, it accumulates all these, like, logs and usage metrics to be able to collect and know every possible way that I'm using my own development tools, so that later down the line in a week or two, when I have more free time, I'll be able to improve it drastically based on the usage that I've accumulated. So I'm not actively working on it, but I'm still passively accumulating all this. Potential improvements that I'm going to implement. So that's another, yet another work stream that I have parked, but it's still under my radar. And what else? I feel like I'm forgetting something. And I already mentioned, like, five different kind of work streams. And also there is, like a... So, for now, I want you to ask me several different questions, where to kind of, like, pique my interest and further continue this, discussion, or make me able to further pretty much be able to brain dump. I need cool aspects, or interesting thoughts, or challenge my thoughts, or give me alternative perspectives that I haven't thought about, or ask me for a comment, and why do I feel a certain type of way, or... Or similarly share your opinions as well, so that I could possibly contradict and tell you the way I think about it. So the article will kind of... we will be able to kind of craft out the article from this clay of thoughts that we are having right now. And I want you to start forming the article itself as well. Start the worklist folder and start the draft article as well. And while we are discussing, keep writing as well.

So it didn't necessarily start with one moment when this felt wrong. It was actually recently when my mentor gave me the advice that I'm involved into too many things at the same time. And after I gave it a thought, I realized that it was actually correct. So technically, it all came from the reflection after that suggestion. And when I actually gave it a thought, I realized that I was definitely getting involved into, let's say, too many things at the same time, which at the time, or in my mind, didn't seem like a problem. However, that's not my point. I'm not saying that this came up from a problem perspective. It all just came from a feeling that I indeed agree with that idea, and I started reflecting and thinking that actually I could be involved into too many things really now. And none of the projects are getting risky, for example. Like, that's not the issue, or that's not where the advice is coming from. It's not like, Oh, it is bad to be involved into so many things. That's not where the suggestions come from. And when I was thinking overall, I was thinking that... To build, like a deeper closeness around a couple of the projects and fully take the ownership. I mean, it's a wrong way to say because I'm fully having the ownership. There is no ownership of them, but fully, like stay in the boring areas of the project. Sometimes the project is not moving as much or as fast, or it's not interesting no more. And at this time, my mind tries to optimize and jump to another project and keep this another project going to build, like the visibility, or build leverage, or make an impact. So in parallel, I'm starting something new, right? Which seems productive, but feeling productive and being productive and making a big impact is not correlated. is not in correlation. Productivity and impact doesn't correlate the same way. I could, let's say, feel less productive today, do not start this parallel whatever testing infrastructure project or some kind of this or that project. Yeah. [Private workplace example omitted at the author's request.] And let's say I ignored the testing-related things that nobody asked me. For example, I'm doing that out of my own interest because I want to improve the testing infrastructure reliability, eliminate the flakiness, and improve the speed. And that's my own interest because I want to increase the engineering velocity, which I have been putting a lot of time and effort, and it has been paying off. We have been seeing as a team really big, drastic improvements in flakiness, reliability, and speed. The flakiness fell, like, is like five times less than it was, or seven times less than it was. So it's a big deal. Lots of flaky tests got resolved, and that also increases the velocity, engineering velocity, because you don't need to restart the flaky tests, and also improve the speed of integration tests, which improves the iterations on code reviews, and again restarting the failed checks and all of that happens much faster, and you can iterate much faster overall. Okay. However, so it was productive. It was impactful, right? However, what if I backtracked from both of those, and there was times when project dependency is making me blocked. I cannot really make too much progress in my mind, and in those times I try to switch to this another fixing tests, right? [Private workplace example omitted at the author's request.] So if I was not doing any of this, let's say I would be bored, or I would not have as much work on that project actively. I would not be diving deep into this feature work and disambiguation and writing solutions and architecture and all of that. What would I do in those times? Would I just cross my legs and sit? I don't think so. I never behave like that. That's why I juggle all these many projects, because I never just, like, cross my legs and sit while I'm waiting to get unblocked. But... That's not my point. My point is that if I'm stuck in a project and I'm waiting for a blocker, or if you are stuck, you are in this condition, what are you going to do? Mentally, imagine you are blocked by a dependency, and you are communicating this. Everybody knows. Everybody's on the same page. The blocker, there is an accountable person that's working on this dependency that you are blocked on. The backend team is working on it. In the UI, I built everything already, and PMs are aligned. Everything is aligned. I'm just waiting for the dependency to get unblocked, then I will integrate with the backend and validate, release the feature. So seemingly, there is, like, nothing to do. However, in this mental example, or in this, like, philosophical or theoretical mental state, I want to sit in this situation, and I want both of us to sit in this situation. What would you do? What am I going to do in this situation? Am I using this parallel work stream as a coping mechanism? Because I don't know what am I going to do when the project stalls. And I cannot make progress, so I jump to something else. Is it kind of like an escapism? Is it some kind of, like, escapism from boredom and chasing the dopamine hit? It sounds like it, but let's not jump to the conclusions. However, let's still pursue this scenario. Maybe I'm trying to chase the dopamine hit. However, in this example, if we're saying that I'm only allowed to work, there is a constraint. In the age of abundance, less is more. That's my new constraint and a tenet that I want to fully respect. So I'm not able to jump to a parallel project. I cannot touch the testing. I cannot touch the dev tools, the dev insights, nothing. So what would Goga do? I don't know. I have no idea. I would just sit there and do nothing, probably. However, my mind will not allow me to do nothing. So what are the things that I would do? Guess what? I already have an idea. I have already a few ideas. I would plan, which I hate, right? So maybe I'm not just chasing the dopamine hit. I just hate planning, and that's what I'm trying to procrastinate and avoid. How could plan what will I do whenever the blocker gets unlocked? Which technically it doesn't require that much planning. So now let me think out loud. Now I'm gonna do a brain dump, which is going to sound very messy and very all over the place. However, that's how my mind works and that's how I think. Let me start. This is the example. The following is the example. I can plan. So these are all my thought conversations that's happening in my brain, right? This is the follow-up. What if I make plans? But that's weird. What do you mean make a plan? I know what am I going to do. I'm gonna... the dependency arrives, gets merged in, I'm gonna build towards the dependency, validate that everything works, inform the people, send out the messages, tell everybody, try it out, get it reviewed, mergeed in, validate. Send it for the insiders, send the messages, send the screenshots. I'm going to do all of these. And I know I'm gonna do all of these. What is there to plan? Write this plan down? It's already in my mind. Why should I write it down? What benefit am I gonna get out of all of it? I'm gonna do it either way. But if you're gonna do it either way, might as well write the plan, and it's gonna be so much easier. But I don't know if it's gonna be easier, because it's already easy for me. So maybe, I don't know, I'll give this idea a weight of 1, 1.5 out of 5, okay? So let me continue thinking and brain dumping, and maybe I'm gonna find an idea that's much higher weight, closer to 5 than just 1.5. So I want to be doing impactful things. Imagine I have 24 hours or 48 hours that I'm gonna be blocked and this backend dependency is not gonna resolve, and all I can do is send messages and send updates and inform people that I'm blocked and I cannot really do nothing about it. Imagine it's a theoretical scenario, and I'm not allowed to pick another project to work on in the meanwhile. Imagine. Right? So another thing I could do is maybe update the documentation, a design doc, refresh the design doc, because it's kind of outdated, because the dependency that the backend team is working on will change in certain amounts of maybe 10% or 20% of the design document. So maybe proactively update it and mark the sections as TBD, not fully designed, but are about to get finalized, and once it gets finalized, it's almost like contractual. So I will be building towards this contractual design document, and it will be all documented, so that as soon as the dependency lands, I can just tell my AI agents, this is the final work that landed. Here is the design doc. Here is the rationale of the decisions that was made, and why were they made, and what changed. You can see the delta of the changes, and the agent will be coherent and will be able to fully understand what needs to be changed in the code, what needs to be done, what needs to be communicated. If there is any open questions still remaining, ask those open questions. And anticipate. That's another thing. Let me get through the anticipation part, but let me close this second idea of updating the design document and writing the contract, right? The design document work and bookkeeping. Let's call it bookkeeping, right? So idea one was, what was it? Planning, which is kind of like bookkeeping as well, right? But idea two is design document, or bookkeeping, documentation. I'm gonna give... I'm gonna give this idea 2.5, 2.3. It's a good idea. The documentation upkeep or bookkeeping is a good idea, but the problem within is that before the final design lands, the design changed like two or three times already while it was getting worked on, and I've been observing it. If I keep updating the design document each time they're changing their approach in the backend, the dependency is changing, I'll just create a mess. I will just create, like, confusion in the design document. It will be messy. And first of all, the responsibility and the boundary of my design document is within the UI product work that I'm doing. Why am I all of a sudden owning this entire dependency backend service, like updating the contracts every time they change? Like all of a sudden I'm, like, introducing this coupling of these backend decisions into my product document, product, the frontend design document. Frontend design needs to worry about the contract, and that's it. I don't need to be updating their approach and solution and their rationale why they're making all these changes all the time in my frontend design document. So I'll be creating lots of Sprout, and ideally I need to wait at the end, once our solution is merging and finalized. This way I can update my design document ideally and avoid all this mess. So that's why maybe I'm gonna demote this idea to weight of 2.0. Just 2. Let's see. Not even for 0.3. Because it's messy, and you're just doing, like, documentation work. What's else? Anticipation. Anticipation is a really interesting thing. It has helped me a lot during the meetings or demos or design reviews. Whenever I write a design document for review or a demo or anything like that, a presentation, nowadays I'm not content with just writing a document or a presentation and be content with it. I ask my AI agent to anticipate the questions that we are going to receive and help me understand them, and help me come up with my own judgment, and help me come up with my own solutions, and help me come up with my own answers, and give me cross-references and references to some authoritative docs and... Documentation and cross-validate against different services and dependencies, so that I have my own understanding of what questions we're gonna receive, what potential blockers or implications are gonna get raised, so that whenever the actual meeting comes, I'm, like, fully anticipating what is about to happen. So it goes beyond just the current state situations. It's kind of like looking into the future and see the potential questions we're gonna receive, and anticipate those questions and let's come up with the answers right away. So when we go into the meeting, I'm receiving all these questions that I've already prepared, and I've already thought about and I've already answered, and I'm just answering them like a master of the craft. So technically, I could do something similar while I'm waiting for my dependency to get unblocked. I could be anticipating questions or problems or UX questions or product questions that are going to come up after this solution gets merged in, and stuff like that. I could be anticipating all of it and getting prepared to Getting prepared to do all of this when the moment is right. So I'm spending all this time anticipating that what is going to happen, and whenever it happens, because it's going to happen—that's why anticipation is a cool thing—it's going to happen. The thing is that not everything that you are anticipating is going to happen, but at least 10-20% of the questions, for example, that you are anticipating is going to get asked towards you, and you're going to be ready to answer. That's how it works in the meetings. So in the case of the project work, 10-20% of the anticipation work will be useful. So in some sense, I'm still going to give this a score of two because similar to the documentation work, this is like a meta work. This is not work in my mind. It feels like you are doing this meta-meta work so that whenever the work becomes— whenever the problem arises, you are more prepared. It's kind of different from planning, and it's kind of different from the documentation work. It's an anticipatory anticipation work. I bet there is a word for it, and I bet it's different from planning. So I'm gonna give the anticipation idea a score of 2 out of 5. Because majority of it could be thrown away. So it feels like you're doing all this work that's a throwaway work. That's what it feels like. See, I'm having a problem of coming up with ideas that are gonna score 3, 3.5, 4, 4.5. I don't think I can come up with an idea that's like 5 out of 5. So I don't know. I'm kind of stuck. I have to think some out-of-the-box ideas, and I don't really know. Another idea that I am thinking of is, doing the projects, there is this really big problem of follow-up. Oh, let's release this and let's not do this right now, and let's release the feature and then we will follow up. Let's follow up after re:Invent. Let's follow up in a week. Let's follow up this Sunday. Follow up is the biggest lie in universe. That's how it feels like, at least. Most of the people never follow up. By the time something gets released, all those things that you were promising to follow up are no priorities no more. And you're not going to follow up. So maybe, what if we do it in times of the dependencies? In the times where you're waiting for your dependency to get resolved, you push, you pull those follow-up work and make it a reality right now. However, someone might say that if it was pushed back as a follow-up work, then maybe it was not even important. It was not meant to be. So why are you even wasting your time and effort on a follow-up work that nobody was going to implement, nobody was gonna make the work happen? So I guess nobody even cared about it no anymore, right? So why are you even bothered about it? And I don't have a good answer to that. However, I feel like not all follow-ups are equal. Maybe some follow-ups are much more important and they need to be front-loaded. But overall, this is where I'm at right now. And this is where I need more ideas and more practical examples and more practical, human-understandable examples. So continue writing an article based on all this information that I'm giving you and help me brainstorm these unknown ambiguities and blind spots that I have and give me examples, practical examples in human-understandable senses without too much jargon. So that I wanna see your opinion and I wanna hear what you think and what you have to say about all of this. I don't want you to just, like, keep poking questions at me anymore. I want to hear what you have to say at this point, and then I will judge or criticize or... Double down or agree with you and say that, Oh, that's relatable to me. You just uncovered my blind spot, and stuff like that. So continue writing the article, continue shaping the article. We are shaping the clay in this conversation, and the more time we spend, you should be shaping this clay into the article more and more. That's the main objective, and secondary objective is to help me so that I can provide more material, more and more material, so that we can shape the clay more and more. But I don't need just questions. I need also help to uncover my blind spots.

The constraint has to permit the answer that there is currently no worthwhile next task. Otherwise, it forces you to manufacture work. If a bounded examination finds no consequential gap, returning to genuinely useful testing improvements could be the right decision. Your mentor’s advice can still be valuable without making every switch a mistake. My working interpretation is that you want to interrupt the automatic move from this project has become quiet to I should start something else. Staying briefly might reveal work you were overlooking. It might also confirm that waiting is appropriate. We haven’t earned a stronger conclusion yet. Yeah I agree to the above, i feel like this is a good way to put it afterall. The resolution doesn’t sound sexy but thats beyond the point, it is what it is. And partially this might not be resolved and we should be okay to live with the unresolved conflict and acknowledge that it will take time to resolve it and for know its better to keep the pressure unresolved than manufacture a fake resolution. So i guess we can close the article with an unsexy half closure and half unresolved tension. I don’t want to be a know it all person and resolve something when I don’t feel like it. And this article essay has now been completed, I don’t see a reason to keep waiting until the resolution hits my mind. Whenever it hits I will be inspired to write a followup article from a mental state where I will resolve this tension. For know this is as best as it gets and we need to be okay with it all. Lets finish the article and publish it.

I want that to be a new main featured article