Hacker News Reader

Comment by revskill | Hacker News Reader

For most of technical works i do, concentration only happens AFTER i figure out what i need to do to solve the problem.

Else most of the time, the "researching phase" is the most daunting task.

I have the exact same problem. When I know what needs to get done, even if it's tedious, it's not so bad to put my nose to the grindstone and work through it. But when I'm not sure how to approach a task, suddenly every distraction in the world is more appealing.

You often see the suggestion to break up big tasks into smaller, baby step chunks to avoid this analysis paralysis. Doesn't help when I'm not even sure what to do yet.

From my experience, try having enough projects in your belt that at least one of them has something actionable to do, and work on that while you ruminate on the other problem for a few days/weeks/months. Don't worry about getting anything done soon, prefer getting them done correctly and pick something else up when you get stuck. Also, don't forget that "staring into space for an hour while you think about a problem" is also a valid form of working.

This is my solution, but it feels like there should be a better way.

I have replaced 'staring into space thinking' with taking a walk outside my office.

Unless you are rich enough to have chosen it, or maybe a prisoner, you always have more than one thing to do. Laundry, groceries, complex engineering, it all needs to be done.

I think our minds evolved to track all these things and, probably in a time sensitive way more than projected future value, to prioritize them. For this reason, I think having multiple projects is the natural state as the mind is optimized for this. So maybe this is the "best way" and explains a lot of the strange ways in which putting a problem aside can help solve it.

It's hard to do laundry or grocery shopping while you're at work.

I like to work like this as well. Which is why a lot of technical tests seem quite nonsense. For complex problems I have stuff running in the background of my head for a day or two, weighing up the advantages and disadvantages of the various options. The best solution usually becomes apparent at some random time, like when I am cooking dinner, not concentrating on it for 5 minutes after first seeing the problem. And as you say there is usually plenty of other work that needs done in the meantime.

I struggle with this too, and two things that help me are:

1) Start screen recording software and dictate your thoughts as you go through the research/brainstorming phase. Don't often go back and view the recorded sessions, it's the act of recording and speaking out loud that helps.

2) Comment driven development. Stub out functions just with comments, write deeper comment blocks inside a procedure where you have a rough idea of what needs to happen. I paste in table and API definitions as comments too, to avoid having to flip to a different screen which inevitably leads to distraction. Once the program is completely laid out in comment form, and compile/runs with just "STARTING" and "STOPPING" displaying, then I start implementing what's in the comments outside-in (from highest to lowest level). I run the program frequently while doing this, each successful compile/run is a small dopamine hit. As I'm going through, remove any comments that are duplicated by code - all that should remain are comments explaining "why".

I also the second approach a lot and it's helped my focus immensely. Sketching things out in comments and detailing / changing as you go along first helps curb that initial perfectionism of feeling like you need to write the right code on the first try. YMMV, of course, but worth trying out.

Thanks for this comment -- I'll put the second strategy in effect (the first one perhaps I'll leave for later as I currently work in an open plan office).

I wonder if this "comment driven" strategy has potential for applying NLP+code generation. I'm sure this is a common enough thought but I'm not aware of the research, does anyone here have pointers?

What I mean is: use NLP to extract intent (where feasible), and then offer possible implementations of the intent.

Microsoft is investing quite heavily in generating code from requirements. So far, iirc, they're able to generate simple programs no bigger than 10 lines of code. A good start, though: https://www.microsoft.com/en-us/research/blog/learning-sourc...

Your advice about comment driven development is similar to how I felt when I first started writing unit tests. I'm not even very good at them yet, but trying to write the tests before the code exists is immensely useful in trying to work out what I want that code to actually look like. Before tests, I would often stub out functions with console logs before writing the body, just to get the high level structure worked out before I got lost in the details.

There's probably a few different methods to do this (some of my friends swear by pseudo code, others have personal white boards) so it might be worth trying a few different approaches to get over your writers block more consistently.

That second approach has been crucial for me when I start large projects. I usually use a mix of comments, pseudocode, and semi-correct actual code, then go back and fill everything in one-by-one.

Figuring out how to approach a task is a problem that can be broken down all on its own. Make a list of possibilities (even if they are “dumb”). Work through them. What happens for me is that either one of them is right or (more frequently) I suddenly “get it” and it’s off to the races.

We're all different... I enjoy figuring out the things, but when it's time to start implementing it I've already lost my grit partially and that's when I start procrastinating the most. Once I move past that milestone and start doing the actual work it gets much easier again.

I found a tactic that tends to work for me for the researching phase. I just use OneNote, but there are some tools under the label "mind mapping" that try to explicitly cater to this approach.

Since research for me usually works like traversing a tree or directed graph, I take notes in that style. Usually one concept depends on another, or one problem must be solved before another problem becomes relevant.

At any point, when I'm wondering where I need to look next, I look at the leaf nodes in my graph, rank them by how important or promising they are, and then I have a TODO list with plenty of notes for context to jog my memory.

I've found that by leaving myself those breadcrumbs, I am much more organized and fluid about "executing" on my research, and when anyone asks, I have a good idea of what I know and don't know.

This absolutely. Right now I'm reflecting on a couple of my own projects that would have been completed much sooner if I had planned things out more effectively.

Don't let your boss jump out from behind a bush and hand you a task and run. Corner them and determine together exactly what the deliverable is. Define terms of reference, get specific details and get them to name the standards, otherwise you'll be stuck trying to guess.

If you are stuck at a critical juncture, list all the options and get your boss to choose the best one (let it be the course of action you recommend).

Absolutely, it can take hours to learn how to do a very straightforward 5 LoC or less task, especially when you start off not knowing what the "task" even is or what your goal/aim even should be. Much of this planning/research is implied in every knowledge job, and the ambiguity and vagueness of instructions/someone else's plans often feel like they are a Valles Marineris away from your input/starting point. Someone can tell me "Just join those values onto our data, easy left join" and 2 weeks later it is finally done.

Reply on news.ycombinator.com