Are Your Lights On?
How to Figure Out What the Problem REALLY Is
Donald C. Gause, Gerald M. Weinberg
Dorset House Publishing
<< I just blew up a few PARAGRAPHS by accidentally clicking the Google button on my Google toolbar!
Desperately hoped the content would remain while pressing Alt-Left, but to my despair everything was gone.
How come web applications do not restore the content or provide an auto-save? Well, maybe they do in some other applications.
<<
I have been trying to read this book since quite a while ago, but never was much into 'execution'. Finally I managed to order this book with several other books at Amazon. It was only the second English book that I read completely (the first one was 'the elements of style') among 50 other books that I have read this year.
This book is about problem solving. The authors are famous for their great insight in computer programming and problem solving. Rather than stating the 10 Commendments of problem solving, the authors took a long but more effective way. They tell a story in each section to end up with a sparkling insight. The book is very unique in the way of presenting the idea and insight - An illustration in every couple of pages, bold and capitalized texts all over to emphasize, a list of possible actions or solutions along with multiple choices, a brilliant sense of humor, etc. What they accomplished with such attempt is readers' attention and impact on their lessons to give. Let's have a look at some of these insights this book guides its readers to:
Part 1. What is the problem?
'A problem is a difference between things as desired and things as perceived.'
Part 2. What is the problem?
'You can never be sure you have a correct definition, even after the problem is solved.'
'But don't ever stop trying to get one.'
Defining a problem is sometimes harder than solving it.
Part 3. What is the problem really?
Each solution is the source of the next problem.
I totally agree, especially in the field of computer programming where it's all about side effects and ignoring/avoiding them.
The trickiest part of certain problems is just recognizing their existence.
If you can't think of at least three things that might be wrong with your understanding of the problem,
you don't understand the problem.
Once you have a problem statement in words, play with the words until the statement is in everyone's head.
This is very similar to lateral thinking.
Part 4. Whose problem is it?
If it's their problem, make it their problem.
This part brings up this story of the tunnel. Since there is a warning stating 'the tunnel ahead, lights on', all drivers turn their lights on. But what happens is they often forget to turn them off, later to find the dead battery. So what shall the designers do? 'Turn the lights off' wouldn't be wise because then the drivers would turn off at nights. (Common sense might lead them to leave the lights on, but anyway this doesn't sound like a perfect solution.) How about 'if daylight & lights on, turn it off. if night & lights on, leave it on. ...' Cars are surely going to crash with drivers reading this epic. The point of this situation is that the problem is not of the designer, but of the drivers. They don't need all that much details. What not just 'Are your lights on?' It's their problem. Let them solve by themselves.
Part 5. Where does it come from?
The problem actually comes from the problem solver 53.27% of the time.
(Don't tell me you want the source of their 53.27% research figure)
Who sent this problem? What's he trying to do to me?
Part 6. Do we really want to solve it?
Not all problems require solutions. There are time people don't even know what they want, and other times they just want the problem unsolved and eke out.
We never have enough time to consider whether we want it, but we always have enough time to regret it.
'The fish is always the last to see water.'
알기 쉽고 싶다
오늘 업무 인수인계를 하다가 느낀 점.
생각해 보니 주변에 일이 참 많기도 하다. 다양하기도 하고…
내가 관심있고 알고싶은 일들을 체계적인 자료로 정리한다는 것은 사실상 불가능하다.
다양한 일들이 서로 맞물려 있기 때문에, 그리고 그때그때 다른 변수들이 너무도 많기 때문에.
결국 중요한 것은 이런 것들이 얼마나 체계화되어 있느냐 인 것 같다.
사람이 아닌 시스템에 의존할 필요가 있는 것이다.
또 하나의 문제는 Knowledge Representation이다.
알고 있고, 행하고 있는 것들을 다른 사람이 봐도 똑같이 할 수 있기 위해서는
지식을 어떠한 형태로 표현하는가가 중요하다.
예를 들면 책처럼 목차를 두고 Tree형태로 지식을 분류해 놓을 수도 있고
Tag를 두어 이슈별로 다룰수도 있고 랜덤하게 배치할 수도 있다.
이렇듯 정보의 제시는 다양한 방식으로 이루어질 수 있다.
문제는 이를 얼마나 효율적으로 이해하고 활용하는가이다.
인터넷을 쓸 때 필요한 즐겨찾기 기능도 마찬가지이다.
나는 기존에 브라우저 내부의 즐겨찾기 기능을 쓰다가 여러 컴퓨터에서 sync가 되지 않아 불편을 느꼈다.
그래서 Google Bookmark 나 del.icio.us와 같은 웹 기반 즐겨찾기로 옮겨 갔다.
그 결과 한결 관리가 쉬워지기는 했지만 둘을 동시에 쓰다 보니 관리가 어려워졌다.
각기의 장단점이 있는 데다가 제대로 활용도 못하고 해서 정말 필요한 정보인데도 outdated 된 경우가 많다.
그리고 아직 나는 Tag 기반 자료를 잘 활용하지 못하겠다.
아이디어가 좋다는 것도 알겠고, 그 필요성도 알겠지만 잘 못 쓰겠다.
하나의 자료가 하나의 범주에만 국한되지 않고 복수개의 자료가 복수개의 범주에 얽혀있는 구조.
선형적이고 단순한 내 머리 속에서 이러한 자료구조가 파악되지 않는 것인가.
아니면 Tag 형태는 충분히 직관적인 인터페이스가 아니라는 것인가.
직관적인 인터페이스는 내가 아무리 바보같아도 알아먹을 수 있어야 하는 것인가,
아니면 어느 정도의 지식이 있을 때 진정 편하게 쓸 수 있어야 하는 것인가.
정말 쉽지만 불편하면 좋은 인터페이스일까?
조금 어렵지만 알게되면 정말 편하다면 좋은 인터페이스일까?
다시 원래 이야기로 돌아와서,
자료의 홍수속에서 나는 점점 길을 잃고 있는 기분이다.
자료 surfing에 나서면 항상 기분이 좋다.
좋은 정보를 잔뜩 사냥한 것 같아서.
그러나 이를 어떻게 archive하고 consume 할 것인가를 생각하면 막막하다.
찾기는 했는데, 어떻게 써먹을 것이냔 말이다.
이에 대한 나의 대답을 이제 찾았다.
내가 길을 잃고 있는 것은 정보의 위치에만 신경을 썼기 때문이다.
단순히 정보의 양에만 몰두했던 탓에 양만 많으면 된다고 생각을 한 것이다.
그러나 정보의 속성에는 위치나 양만 있는 것이 아니다.
바로 시간이 결부되어야 한다.
즉, 정보의 위치도 중요하지만 (know where) 언제 이 정보가 필요한가 (know when)는 더 중요하다.
좋은 정보라도 필요하지 않으면 버리자.
쌓아두어도 결국 다시 새로 찾게 된다.
나의 Inventory는 한정되어 있다.
인터넷이 가져온 공간의 무한확장이 나의 Inventory의 무한확장이라고 생각해서는 안 된다.
