Underrated programming techniques: name something (a step definitions file, a class, a directory, whatever....) "junk drawer."
Not "util" or something else that kind-of means "junk drawer" but pretends to dignity.
Be bold. Admit what you're doing. Do it with joy.
Not "util" or something else that kind-of means "junk drawer" but pretends to dignity.
Be bold. Admit what you're doing. Do it with joy.
Calling it a "junk drawer" tells us the following:
1. If you can find stuff, there's not too much stuff in it.
2. If you have a sudden insight as to where something in it ought to go, move it there!
3. If you can't find stuff, do the bare minimum to organize & move on.
1. If you can find stuff, there's not too much stuff in it.
2. If you have a sudden insight as to where something in it ought to go, move it there!
3. If you can't find stuff, do the bare minimum to organize & move on.
All of our instincts about junk drawers are appropriate for programming situations where we don't necessarily know that much about the problem.
(Hint: this is most programming situations, whether we think we know stuff or not.)
(Hint: this is most programming situations, whether we think we know stuff or not.)
(Pssst: if you think this thread is Good Twitter Content, consider signing up for some Good Workshop Content with a similar philosophy: eventbrite.com/e/uncomfortabl…)
Also! There's been some confusion in my mentions between what I meant by "junk drawers" and the "shame file" pattern. I think both are valuable, and go more into the distinction here:
