I have been using Leo for many years now, and I love it. I use it for a couple primary purposes. First, I use it as a PIM, both for "administrative" information, as well as for "archival" information where I keep virtually all the code I've ever written in the event I should need something later (which happens surprisingly often). Second, I use it as a code development tool.
For both uses, I have been mostly a solo user, i.e., I have had very little need to collaborate with others, and therefore no need to coordinate my "Leo-nized" workflow with the non-Leo workflow of others. Until now, that is. I am currently working in a team to develop code, where I use Leo, and my team members do not. It's working pretty well, but it has led to some realizations about how Leo has affected the way I like to work, and how that subsequently affects my team's work. In short, Leo allows me to be a sloppy coder! Let me explain. 1) Leo greatly simplifies "trial and error" coding. I can implement experimental code blocks and routines, try them, and if they don't work the way I want or there's something I want to defer further work on until later, Leo allows me to quickly and easily "park" the code by making a note in the headline, commenting out the block with @ and @c, or moving the offending code node somewhere else. That means that my team members can sometimes find spurious code blocks with no obvious relationship to the rest of the code. I see why it is the way it is, because I see the structure, but they can't see that. 2) I tend to use fewer comments. This is because the outline structure of my code contributes so significantly to my understanding of the code that I don't need copious comments. And I like this, because, even though I know better, I have difficulty keeping comments and code in sync. But my team members don't see the structure, so it is not always obvious to them how things are related or what they are intended to do. 3) I tend to use fewer helper functions, and use nodes instead. This is great for me, because it provides better documentation, but for the poor coder who is looking at the text, my code can sometimes look like long run-on functions. 4) I use clones freely, including between files. This can conflict with non-Leo coders, who don't realize that a piece of code is common between several locations. If they make a change in a cloned section of a file, it won't propagate to the other files. If I make the same change in a cloned node, it affects all code using the clone. Maybe the common code should be broken out into a separate file or library, but that's not always practical. I use Leo because it fits my thinking style. I would say it has even helped me to be a more creative and innovative developer, because the ability to capture structure allows me to envision the code in a larger scope, and see relationships that I might otherwise miss. I am also convinced that my team members would find using Leo to be very productive. But I am not in a position to force others to use it. And every developer has his or her own favorite tools, so convincing them to adopt Leo would be difficult if not impossible. So, I would be interested to hear the experiences of others who are in similar environments. What workflow practices work best? What doesn't work? How do you resolve workflow conflicts? Thanks, Phil -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
