[afarrell]

I would like to know, when you run into the situation that you don’t know was is going on with what you are building and feel a sense of confusion, do you:

1) Stop and spend time trying to get a clear mental model of what you are confused about

2) Push forward and try to build despite not understanding

In the past, when I tried doing super-ambitious things, I used the second strategy. Many sleep-deprived (tip: “sleep is for the weak” is BS) nights in which I accomplished nothing left me with a strong feeling that I should not try to do impossible things. However, since I learned the first strategy and have been applying it successfully to projects at work, I am rethinking this. I have increasingly been feeling like I would be able to be surmount large challenges if I first set myself up for success in terms of resources and people to ask for help.

Questions:

A) Do you apply a “step back and study” strategy to tackle confusion? Have you found it successful?

B) Do you have any more detail you could add on how it works?

C) How do you set yourself up for success outside of a work setting? For instance, I would like to write a server-side debugger for nodejs that is independent of google chrome and works toward a pry.rb-like developer experience. However, I haven’t written C since by OS class in uni and I don’t know the internals of node.js. How would I go about building trustfull relationships with people who know the internals of node.js so that I can ask them questions in the style of https://jvns.ca/blog/good-questions/

[dmos62]

A heuristic I use that is very accurate for me is whether or not I can easily step away from what I'm doing (for a break, or just to finish the day) or do I feel a compulsion to keep going. If stepping away is difficult, I'm definitely in a "death spiral". At this point I can be sure that my productivity is already low, and it will just get worse. It's a burnout; a feeling that your problem-solving apparatus has overheated; severe tunnel vision coupled with impatience. It's weird that it produces such a drive to continue.

So when you pose the question, whether to push or take a step back, in my experience, it's better to pick clarity over aggressive pushing. It's subjective though. While I think there are overarching principles, I also think that different people react to these situations at least a bit differently.

To say a few words about confusion when confronting something you don't fully understand, I think the more confusion you can take, the better. Ideally confusion should be second nature to us, too often we jump to something prematurely just to escape it. When you think about it, we never fully understand all the things at play. It's about not being paralyzed by that.

[reggieband]

It is interesting because I went through this exact question recently with an intern.

My condensed advice is:

1. Are you still making progress? Keep going. Don't give up.

2. Are you spinning your wheels? Take a step back, re-evaluate what you know, investigate things you are not clear on.

3. Still stuck? Ask for help. Don't panic or be ashamed. Show the progress you've made in step 1 and share the things you studied in step 2.

[Serow225]

The Feynman Algorithm: 1) Write down the problem. 2) Think real hard. 3) Write down the solution.

http://wiki.c2.com/?FeynmanAlgorithm

[brrt]

These are all good questions, and not so easy to answer :-) Any answers I can give are personal, of course, and may well have no relevance to your situation.

a): 'Studying' is definitely very important to get an idea of the context of the thing you are trying to solve. (I did a lot of reading both before and during the project). But, it doesn't always relate easily to the problem you have right now. (E.g. I'm using linear scan allocation, and the papers on that method all glossed over the nature of a 'live range', which took me 3 iterations to figure out). And without a practical problem to guide you, it is easy to get lost in literature.

b): What I find is that before I try to do something, I typically put together a high-level overview of how I think I can achieve it (what stuff to change where, and what I will need for that, roughly). But I'd classify that more under planning than under studying per se.

What I also do is take lots of notes. I have several large org-mode files (big fan) and before that paper notebooks in which I write down thoughts as they come up. I think org-mode is superior because it lets me organize things after the fact. Notes are a crucial bit of making progress for me, because I don't need to revisit the same things over and over.

The other thing that I find helps very much (and which I wasn't very good in at first) is to do incremental, small-step improvements. Move a function here, change an struct there, change an interface, move some process earlier or later, split it up. Simple things that you can do and that you know will not go wrong. Many problems can be broken down in that way, and the few that can't can at least be 'isolated' so that you can fix them 'atomically'. I wrote a blog post about this some time ago, if you'll excuse the link: http://brrt-to-the-future.blogspot.com/2016/06/in-praise-of-...

c): I was lucky to be able to join the perl community as part of a GSoC project, and fortunate that the perl community is altogether friendly and welcoming. And I really can't speak for the node.js people at all. But what I will say that anyone with a genuine interest in contributing (as you seem to have) and a willingness to do the work to learn (and to listen) will find a warm welcome from nearly all open source projects, because all of them are relatively understaffed compared to their ambitions :-)

So in your situation, I'd start with checking out the node.js source, start with trying to figure out how a debugger could work (there is lots of prior art here, of course, so you can check out the chromium source as well), and ask your questions basically as the jvns comic demonstrates.

I hope that answers some of your questions.