Main Area and Open Discussion > General Software Discussion

Awesome article re: organization and notetaking

<< < (9/11) > >>

mitzevo:
wow nice find, very good read. I've had my time with thinking about good orginzation methods, etc. file hiearchirse, the use of tagging, how to categorize by, type, company name, software name, task description, etc. and have spent quite (probably too much) time worrying about how i organize my files instead of getting shit done.. so in the end i think orngazingin is overated, and people these days have too much data than needed.. any thing they really need is close by in their memory (head)..


if u wanna get too carried away with heierachy, its never gonna work, you wont be able to sort the files.. u have to put into cosideration the file type (mpg, mp3, doc, zip, jpg, etc.), weather it is actual "working data" or program setup files.

And then you have the filesystem limitations on Windows for example, if you are organinzing by file purpose



symlinks, hardlinks, etc. ofcourse on *nix, it's not much of a thing.

u also have to put into considerationm, are you catergorizng for your self? or others? very important question in terms of sorting alot of content.. are u sorthing this repository for your self for the future for easy retrieveal when you need it? or away you think some day some one might find your collection of things useful.. people organize things differently,

this is a rough draft.. will clean up later (missing parts of text). it's what ive come to find any ways while orgnazing, software, source code, backups, media, etc.

Paul Keith:
Paul, thanks for that, still not fully sure what "Faceted" is - but I get the gist I believe-tomos
--- End quote ---

Yeah, I didn't know why they used that term either. I know it's not mentioned anywhere else that I know of.

I think "faceted" is simply another term for what PPLandry calls "fields" in Infoqube. It basically means this particular section here is classed to this element and this purpose. An even simpler model would be to use Explorer's Thumbnail or Tile view.

Once you renamed something as a picture folder. It's facet or it's element is that of a folder and it's classification is that of a folder leading to pictures. Hence it's called a faceted classification: an area where you declare "thou shalt be used for this purpose and this purpose only" even though it's really just a piece of land you drew imaginary borders on.

wow nice find, very good read. I've had my time with thinking about good orginzation methods, etc. file hiearchirse, the use of tagging, how to categorize by, type, company name, software name, task description, etc. and have spent quite (probably too much) time worrying about how i organize my files instead of getting shit done.. so in the end i think orngazingin is overated, and people these days have too much data than needed.. any thing they really need is close by in their memory (head)..-mitzevo
--- End quote ---

I agree and I think you'll be surprised that many productivity experts agree with you. To paraphrase David Allen (the writer of Getting Things Done)

You know what's one easy way to get rid of stress and stay productive? Simplify everything.

That's it. Simplify everything. There are lots of stuff that you do day by day that you don't really need to do.

Doesn't mean you have to do it this way, but it is one easy way to become productive.

YOU and I both know though that you aren't here because you want to become productive. You want to become productive because the things that you are doing in life, the things you want to do, the things you are currently enjoying led you to this un-productive life.

To add to that: (he was addressing this to a corporate crowd)

You and I both know that the reason you are here is to get farther in your career and still have time to enjoy the things you want in life. You remember that guy who just came out of college and said "Boy, I can't wait to get promoted."

Yeah right. "The grass is always greener on the other side of the fence."

You know that right now, you are paid and are going to get paid more for your capability to handle a large size of load and still not break down. To become more productive isn't to get rid of stress. No, alot of times stress is good. Stress helps you become more alert. Stress means you're doing lots of stuff currently.

Stress becomes bad when you're stuck in there because you either don't know what's bothering you or you don't know how to get rid of it. That's why you stay organize.

To paraphrase Leo Babauta (Zen Habits blogger) - Being productive isn't when you're getting lots of things done, it's when you have done the things you need so you can start doing the things you want.

Regarding our problem with organizing and notetaking, this is why David Allen often emphasizes:

"It's not what's on your to do list. GTD isn't about your to do list. It's about having a system you can trust."

That's why you often see applications based on GTD having separate categories for reference files and to do lists.

Most sites talking about GTD rarely point this out but David Allen explains this simply as: "a system you can trust"

First, he points out why you might distrust your system even if you like it. (Contrary to popular belief, notetakers can't stab you in the back)

1) You are putting stuff more than you are pulling out stuff.
2) You have a difficult time finding your stuff.
3) You're not really sure whether your stuff is there.
4) You don't really get any idea how organized you are becoming.
5) You feel more pressured because you see more and more stuff in front of you.

That is why you often can read some productivity article saying "Don't turn your to-do list/notetaker into a black hole!"

That's where the term came from. Allen pointed out how a system you distrust ends up becoming a black hole where it just constantly sucks matter in and you never get it back. That's also why his criteria for having a system you can trust is at it's core composed of:

1) A brain dump - A place where you write down or note down every little thing that comes to your head.

Why? Cause your conscious brain is better at remembering things it sees in front of it than when it's stored in your subconscious plus the confidence in knowing you can forget something because you have it stored in something you can return to helps you become more focused in what you're currently doing.

2) A place to store your notes - Basic notetaker concept

3) A to-do list - Basic to do list

Why separate it from your notetaker? Because our brains work more by association than by rationale. You want to avoid a situation where you are constantly organizing stuff because the things you want to do are being postponed in favor of the other thing stuff you want to store.

4) A queing system that you review weekly - Separate to do list

Why? Because often times when we write down to do lists we don't think on it. That's why we never get to do many of what's written in there. (For those of us with that problem)

According to him, it's not because we have many things staring in front of us. It's because we're not only not as confident that we want to do the things we want to do in that order but also because we're staring at many huge general things that we have to think on rather than little specific things that we've cut down from those huge general ideas.

Think of it this way: It's much easier for you to call a person who's phone number and exact message is written in front of you than it is to have a to do list entry of: Call Homer - D'oh!

The weekly review habit is also there not to pressure you to constantly organize stuff one day a week but so that once you get your system set up, you're not put in a position where you have to constantly think of how and where to organize your stuff.

You just put in your brain dump, store it in the ideal places where you think you may find it, write the ones you want to do in a list, schedule a time where you think about these lists, cut them down to smaller pieces, write it down in a separate to-do list (preferably written in active "actionable" form) and then you have organized what you want to do for the rest of the week until you repeat the process all over again.

P.S. I'm not a proponent of GTD and I'm hardly productive so I'm not saying this is how it should be done. Just trying to point out that while I agree with mitzevo, it's also partially a notetaker designer's fault as well as the wrong perception we often have of notetakers enforced by their structure that organizing sometimes becomes more tedious than it is and not because organizing or stuff you have on your list is always overrated and not really needed. In essence, it still agrees more than disagrees with what you said mitzevo (like with Windows way of handling things) but I also don't think Unix would help you much if your idea of organizing doesn't match up with Unix's way of doing things and that's where the category problems become a problem IMO.

When you're thinking *.mp3, *.docx, *.pdf rather than your own category then you have bought into another person or application's way of doing things and it's going to be a headache because of that. However all modern operating systems allow for copy paste so even without symlinks and hardlinks, if you have set up a system that you trust because you so get it and it's designed by you for your purposes (including collaboration, reference, backups) then duplicate files are often just a delete away. You'll even laugh at yourself for how these got left in there because you've already worked on it months ago and this happens because the other duplicate already got relocated to a place you are satisfied with and there's no pressure on your part to know where it's exactly at.

Note that I'm not a Unix user so my knowledge of symlinks and hardlinks is limited but I use Compendium and in it, it has a similar structure where it is called a Transclusive link where you can have two nodes synchronize between each other or have a List Node that provides an overview for the actual nodes you want to view.

Didn't see anyone mention yet that there is an interesting book called 'Dreaming in Code' which uses the Chandler project as its central theme. It's basically a case study that shows what can go wrong when developing a reasonably complex (open source) SW project, but also contains interesting historical information about SW development.
-phitsc (January 29, 2009, 05:35 AM)
--- End quote ---

Thanks for the book mention phitsc. This is stating the obvious but I remember why I didn't even bother remembering the book from Amazon's most critical review.

One of the most puzzling things about a lot of software doomsday scenario books is that, in spite of the fact that not all projects fail, they never try to figure out what made the successful ones work. Maybe nothing sells like a disaster. This book is no exception. Except for an occasional quote from Linus Torvalds about the need to start out small and fulfill an immediate need, the book never poses the question - `Chandler was by no means the first open source project, Why did it fail when many other user-facing open source projects have managed to get traction ?'
--- End quote ---

This isn't to say that I'm discouraging anyone from reading the book since I'm neither a devoted follower of the Chandler Project, a programmer or had read the book. I guess on my part it's just an initial over-critical bias to the generic comments I read about Chandler. I just feel that the open-source world is rooted in staleness and copycat-ness and Chandler brought the worst in those stuff. First time I saw the screenshots, deep down I was thinking, these guys so need to drop their Outlook man-crush.

Of course I kid the Chandler developers. Most full featured Open Source programs are slow. I think where they lost me was that they got the vision and the right idea of marketing an Open Source program, they just didn't have the focus. (I know: easier said than done) I just think Chandler developers should have respected the trend they were in and focused on their vision more rather than their blueprint. The way they wanted Chandler to be, they should have used an exportable hub to link several different applications together and have them reside within the cloud and only as fully functioning separate apps bundled in a suite.

The signs were all around them. OpenOffice not being as fast and responsive as MS Office. Thunderbird not comparing to Opera's E-mail client as far as load. Sunbird having so much trouble. ThinkingRock barely optimizing their memory with a to do list application alone. Hindsight is 20/20 but when you were dropped knee deep in the boom of productivity apps combined with the fact that you had potentially the best free, decently marketed app that's in demand, there were only two major courses you are left with: Stay with your vision or stay the course.

Chandler stayed the course. This isn't bad if they were a company and had a business model in mind and they just couldn't pull through so they settled for a lesser product but Chandler all this time was claiming and building itself up as an idealistic vision of notetaking. The developers wrote and painted Chandler up as Open-Source developers finally meets real passionate digital notetaking people.

When you convinced lots of people that the reason you are building this app is around a vision, at it's core, when the app fails it was because you just didn't step up to the plate enough. Chandler on the surface seemed like they decided they didn't want to even try to fail. It just wanted something out. When that happens, it's no longer an open source problem nor a software problem. Chandler developers either simply didn't really have that vision in the first place or they lost their vision. Dreams are given up everyday. There's very little thing to learn from those even for software engineers. Chandler, IMO has little to offer to software engineers because whatever correct and wrong thing they did never mattered once they grew tired and lost their vision. Once that happened, Chandler was no longer Chandler no matter how well they even build the first app. Upgrades will suffer. Apathy will reign. Features coming out slower. That said all of what I'm saying are still just from a surface impression of Chandler so there's a good chance that I'm wrong.

phitsc:
Well, I agree that you probably won't learn much about what makes a SW development project fail (or succeed) from 'Dreaming in Code'. Nevertheless, I found the book quite and interesting and enjoyable read. It reads and (feels) more like a novel than a technical book. Almost like a fiction book with well researched historical background. Only that it really is no fiction ;) An example of one thing that fascinated me (well, might not be that fascinating for the Americans in the DC community) was how people like Kapor, the main protagonist (speaking in novel terms) as well as some of the leading SW developers could spend their (working) lives doing almost whatever they pleased, without the pressure to make money to feed a family (well, most of them seem to only have dogs anyway ;) ). While Kapor had earned so much money in the beginning of his working career that he (alone) could fund a big multi-year SW project just out of ideological reasons, the others at least had made enough money in the first .com era to spend their lives doing what they liked most (programming) without actually getting money for it. Maybe the lack of pressure to actually succeed with what they were doing if only to make sure they could pay their bills at the end of the month was one of the reasons for the 'failure' of the Chandler project.

Paul Keith:
Thanks for sharing that perspective phitsc. I hadn't thought of approaching the book as a novel.

davidqxo:
DREAMING IN CODE: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software, by Scott Rosenberg, tells a wonderful - and cautionary - tale of struggles by ex-Lotus guru Mitch Kapor and his team to define and implement Chandler. As a Lotus Notes practitioner, a student of information organization, and an ages old programmer on projects large and small, I could relate to and enjoy the tale.

Navigation

[0] Message Index

[#] Next page

[*] Previous page