Manage Your Code with Philosophy

I had this idea for a diagram from maco, we were talking about Religion and got to discussing this. I wanted to explain it and I was being casual. But take a look at my diagram and you’ll see there is a very strong pattern which is used for both resolving idealogical conflicts and resolving code/patch conflicts.

And just as we as programmers need access to lots of good and bad code to build our skills and patterns of how to program in the best way. We as human beings need to experience lots of thoughts, feelings, cultures and conflicts in order to build wisdom and insight in our human problem solving.

What are your thoughts?

2 thoughts on “Manage Your Code with Philosophy

  1. Wonderful job at boiling this iterative process down to the essence. When you converted the programming jargon to generalized concepts, it now can be applied to a variety of real-world applications. Fitting that Google is celebrating Edison today, as his inventiveness wouldn’t have been possible with a similar process he used. Try a little tweak to something that’s working and judge the results.

    Once you have this process applied to the thing you’re working on though, now you’re in for a lot of drudgery if you’re not thoroughly motivated. A flash of insight, and unless you’re very well disciplined, you get tempted to skip right over a bunch of steps.

    This pattern seems to me that you start with raw materials and work towards a finished product. Sometimes you know what you’d like the end result to be, so you start working backwards from a mockup until you arrive back at the raw materials you have available. I believe that calls for a different model.

    Within the open software community, you have unique opportunities to build on each other’s work. Generalizing these patterns is a generous thing to do, so other design communities could benefit by opening their techniques to the world. I’d love to see even more collaboration possible in my other hobbies, woodworking comes to mind when I look at the generalized flowchart.

    I think this is only the center of the big design process picture, though — it will be complete when there are labels and connections for You and Me.

  2. Never mind the religious comparison, I just benefit from finally seeing how open source software actually works, after using and advocating it from a non-developer perspective for over 5 years! Thanks!

Comments are closed.