Which tools/processes/media do you use to "approac...
# thinking-together
m
Which tools/processes/media do you use to "approach" a problem before starting to write code in a text editor/IDE?
c
• Google: To find out if it is already written, and failing that, to figure out the various ways to tackle the problem. • iPad with Concepts SW and Pencil for sketching the general idea (only if it is complicated) • Go away and code something completely different/sleep on it (because my approach is different if my subconscious/conscious brain has had time to percolate)
f
iA Writer where I write down the problem and how I want to approach it. Whimsical to visualise how parts of a system are connected. Codepen to sketch out code in isolation. Also: any form of communicating the problem to someone else. Verbalising it often reveals potential solutions.
c
Interesting tools! Whimsical in particular looks nice and simple.
a
Freewrite (stream of consciousness braindump) about the problem, usually in a plain text editor; yesterday I just did it in a comment in the source file I was working on. Paper if I need to draw something: I've never found a computer graphics tool remotely as intuitive. There's a good point about it being easier to fix mistakes in software, but for exploratory stuff there's a lot of benefit in redrawing it from scratch anyway. Similarly in writing I iterate though different versions of my problem or solution.
c
Almost always pen and paper
c
Sometimes still a text editor (Drafts iOS) to type notes (I'm too slow at writing, don't usually need to diagram) Usually a lot of Google to see what the noosphere's recent thoughts are I like to get into a REPL experience before too long, even just on the CLI with curl, jq, basic tools – to get some things functional to prove I know what I'm working with +1 to sleep, walking around, waiting until I feel latches click internally
d
I use a LOT of Miro for this; I also tend to add
// TODO: something
comments on a branch and then look it over in git
s
If a problem needs to be approached, I make a list of terms - kind of an ontology - for the problem/solution. Then I try to organize them in groups. Encapsulation is all about isolating concepts. So I try to separate system wide ideas from subsystem specific ideas, problem domain ideas from implementation detail ideas. This is neither rigorous nor exhaustive, but helps me think about the problem.
Oh another set of groups is "contextual" vs "new" - stuff that is in the problem context, and not negotiable, vs new stuff that is being invented.