Stepping Back

My thinking is threaded. I maintain lists (in a simple txt file and more recently, in Notes on the Mac) and add the tasks to it. Subtasks go into an indent. I have different notes for regular work/pet project/blog/learning/travel. priority-must-do-now/daily chores is separate one. Every morning I open my priority/daily chores stuff and try and wind that up. And then I just scuttle around the other lists and do whatever my brain tells me I can. I find that some days I do more from the blog notes and some days more from the regular work notes. The notes serve as goals for my brain and it invents/discoveres solutions in no particular order. This makes me more productive because I can switch when I'm bored (which to me is an indication that my brain needs more time to find solutions in this space). And if nothing is hitting the right note, I'll take a nap or read or watch a show for a bit or go for a long walk or hike - anything that's not in the to-do just to give myself the creative space. I find that giving myself problems to solve, and allowing my subconcious brain to invent solutions for it while I do other things actually works quite well for me and allows me to make steady progress.

Your fixation is a result of the fact that interacting with LLM coding tools is much like playing a slot machine, it grabs and chokeholds your gambling instincts. You're rolling dice for the perfect result without much thought.

I find it interesting that no one has created a better interface for these LLMs.

Two things that should be available by now in conversations are branching and history editing. Branching is somewhat trivial so let's focus on the history.

Now when I last used an LLM API, the whole context was still managed manually. Meaning I had to send the API the whole conversation history as one long text for every new query.

This means that I could technically change a part of the history directly. Manipulating the history though is not really a trivial problem. The LLM would need to re evaluate starting from that point.

But, the re-evaluation may result in something completely different... If there are branches, perhaps it would also be desirable to let it propagate into the branches.

Next, re-evaluate until where? We can assume a conversation happened until the present moment and the user may have changed their reality/state during the conversation before that point. For example, I may have changed some function based on a suggestion of the LLM. Now, for re-evaluation it would actually be nice if the LLM could also take that state change into consideration.

Here it would be nice if the LLM had the concept of certain logical facts and pieces of information and how they relate to each other but with an interface so that we could see that. If such a piece of information in the conversation is then changed, that would affect the information that is related to it. We could follow a sort of sequence of logical conclusions being made to verify what happened.

Just some thoughts with no conclusion. I think current LLM interfaces could be a lot better.

I’ve found this problem to be compounded by the use of stimulant medications — no matter how aware of the phenomenon one is going into a task, it can feel nigh impossible sometimes to avoid locking into whatever path I’m on as the drugs kick in. This seems true not only of the task itself but also of the individual decisions that can constitute it. I don’t think this is surprising or novel, to be sure, but frustratingly predictable.

I get relentlessly obsessed until the thing works, or at least until some major milestone is met and the big problems solved. Not just for five minutes but days weeks months even years.

It’s really unhealthy behavior.

Reminded me tangentially of the legendary talk “Hammock Driven Development”.

I enjoyed the article, and as a longtime developer. I certainly relate to being heads down on a problem, only to step away for a walk or a breather and realize I can maybe avoid solving the immediate problem altogether.

I also don’t think it’s possible to focus at 100% on a detailed complex problem, and also concurrently question is there a better path or a way to avoid the current problem. Sometimes you just need to switch modes between focusing on the details the weeds, and popping back up to asking does this even have to be completed at all?

What the author is describing isn’t my experience at all. I tend to operate from a lens of asking for increased feedback as my work takes me further off the “beaten path”. There’s essentially zero chance I’m going to go off screwing around porting code with an LLM unless I already bounced the idea of doing that off of another person or two that I trust.

In my hobbies I think going off on tangents _is_ the experience, so I have no qualms about doing it. But when I’m working I’m almost always thinking in terms of stewardship. Is what I’m doing good for the business, our customers, my coworkers, my own professional development, etc.? Any sort of fixation on minutiae is just subservient to those questions.

That said, I don’t think of a 5 minute tangent like the author describes as a heavy investment. If anything it’s just a happy little side-journey taken to better understand the nature of the problem space. For me the threshold of “this may be a waste of time” is more measured in hours than minutes.

Great article and I think of this phenomenon by the term of my pilot friends, “Target Fixation”.

https://en.m.wikipedia.org/wiki/Target_fixation

After taking a break I often realize I can delete all the code from the last hour and either define away the problem entirely, or fix it in a much simpler way.

But it’s so scary to depend on that flash of insight, after all it’s not guaranteed to happen. So you keep grinding in an unenlightened state.

If there was a Reliable way to task your subconscious with working on a problem in the background I could probably do my job in a third of the time.

I read somewhere that the subconscious brain continues "working on problems" even when you are not actively working on it consciously. Hence the expression to "sleep on it" when faced with a difficult/big decision.

I am not sure how much I believe that or how true it is, but I have found that many times I have come up with a better solution to a problem after going for a run or having a shower. So there might be some truth in it.

But yeah it is hard to know when you are in too deep sometimes. I find that imposter syndrome usually kicks in with thoughts of "why am I finding this so complex or hard? I bet colleague would have solved this with a simple fix or a concise one-liner! There must be a better way?". TBH this is where I find LLMs most useful right now, to think about different approaches or point-out all the places where code will need to change if I make a change and if there is a less-destructive/more-concise way of doing things that I hadn't thought of.

This reminds me of the discover and defend modes from Jonathan Haidt's latest book The Anxious Generation.

On taking a break, I've often found it difficult to stick to the pomodoro technique because the breaks seem too frequent. But those breaks help avoid going down an unfruitful path for too long.

I use pomodoro, and I think it helps with that problem. Every break, I also add a short record in my “log” file. I can still become obsessed, but happens more rarely, and I am more aware of the obsession, because it usually means I start ignoring the timer.

I have to assume there are some other obsessive engineers out there with reflections of their own. I'm curious how people approach the challenge of staying focused while keeping an open mind about the futility of a particular direction...

Previous discussions on psychonetics and deconcentration of attention seem relevant, e.g. https://news.ycombinator.com/item?id=10028317

Personally I've found a continuous open awareness style of meditation has really helped me balance things out, as I went from someone with very little doggedness to e.g. being two weeks into cataloguing all my books with Delicious Library before realising it was kind of pointless. The open awareness practice (very different from focus-on-your-breath and also the visual deconcentration discussed in the link above) is about encouraging the recognition of this-is-how-things-are as it naturally and spontaneously occurs; doing this more and more also builds confidence in one's intuition about (in this context) whether to persevere at the current task or whether to step back.

I don't think there is a foolproof system that can be developed as a substitute for this kind of intuition. Speaking for myself I can and will continue to second-guess over time any external system that may feel definitive when it is first established. But I can learn to trust the (unfortunately) indeterminate part of myself that tells me I'm doing the right thing.

It's also important (I would say essential) to set a hard stop time every day. No matter what you're in the middle of, no matter how close you think you are to a breakthrough, you stop for the day at that time. Tomorrow will always be there. Whether that's the traditional 5:00pm or some other schedule you need to give yourself time to relax, step away, spend time with family or friends or pets or just yourself, and keep up with all the other demands in your life.

This reminds me of Richard Hamming's practice of spending time every Friday to consider the big questions of his field. Here's the first summary I found: https://nobaproject.com/blog/2018-11-01-tough-questions-and-...

The main Hamming materials I'm aware of are:

"You and your research" https://www.youtube.com/watch?v=a1zDuOPkMSw

and the course, "Learning to Learn" https://www.youtube.com/playlist?list=PL2FF649D0C4407B30

The original course notes are online somewhere, can't find right now.

And I just found that there is a book: https://gwern.net/doc/science/1997-hamming-theartofdoingscie...

A serious talk by British comedian John Cleese "Creativity In Management" is also relevant https://www.youtube.com/watch?v=Pb5oIIPO62g it touches on switching between "open" and "closed" modes of thought. Perhaps this is what we'd call switching between the DMN and TPN. Neurotypical exclusive switching between these networks is a function that is theorised to be impaired in ADHD.

I write things down and it helps, esp. when I manage to keep it minimally structured: write down a question, then write an answer, split different topics.

Generally I think it is a question of method. If I was to produce a physical thing I would know the steps. One of steps would be a drawing in a known form, with known ways to indicate what is important. With software there is no such a standard form.

All great programmers are exactly like this. We have a relentless insatiable desire to always be fixing problems, solving challenges/mysteries, and/or just creating. When you mix those psychological tendencies with the other aspect many of us share, called HFA, you end up also with extremely focused and narrow interests, as well.

What I tell myself (which is true) when I notice I've perhaps done something where the effort might not be worth the pay off, is that life itself is about the journey not the destination. As they say "The Journey _is_ the Destination", which applies to my other hobby, riding motorcycles. You can always get anywhere "better" in a car, but it's more fun on two wheels.

If you want to reach the full potential of your brain to solve a specific problem, you'll need both hard focus during intense sessions and "background" work, and yes taking a step back (during a walk, shower, coffee break or bathroom visit) is a way to trigger the switch.

The key is to care deeply about solving the problem, not simply looking to get rid of it for a quick win, if you are immediately thinking about something else as soon as you can, you'll never get the best results.

When using code assistants I found that a nice way to take a step back is to use the Socratic method, chatting with it about the design instead of trying to force it doing it for you. It is like chatting with a well informed but not too clever normie colleague, it can help taking a step back.

One of the ways pair programming can be effective is one of the pair keeping more of the big picture in mind. Either thinking about alternative approaches or at least spotting the escalation of commitment to current approach and calling a pause to reflect.

Been there.

I often talk about how I think people should learn to code not to get a job but for the mental models it gives you.

Similar to how learning a musical instrument enriches your life.

Or art.

And one example that feels particularly apt here is that in my art classes in college, my drawing professors really hammered-in the habit of stepping back a few feet from your canvas.

It might feel like it's applicable specifically to that context, but it's amazing how much that voice comes back even when I'm working on code or 3D modeling: "take a step back."

It's often just as difficult to make a good decision of "no" as it is to say yes and build the whole thing. By the time you understand the problem space well enough to have a somewhat confident answer, you've done a decent bit of work. It's also difficult sometimes to admit that something could be better, but we can't do it now, so we'd better come up with something that works within our own limits.

I chuckled because stepping back is exactly what some thinking models do with their "Wait... aha!" dance.

It’s why companies don’t want you doing a sabbatical. Poor return rate.

To grind or not to grind?

[dead]