CV Notes

Builder/Architect - publications are my works, software, systems, etc.

Order of presentation - - The majority of resumes focus on  "experience." These resumes are not much more than lists of jobs and employers in reverse chronological order, beginning with the most recent job and going backwards. On the other hand, a CV protable is more "biographical" and needs to tell the story of your life course.

Basic outline:

Objectives section (but recast as in "New Directions" below. Maybe have several to use with different opportunities). Should reflect projects (Peer production ... development of social arch. and currency systems for ... Continuing work towards a comprensive theory of meaning grounded in biology, action and semiotics)

Education: MIT, ODC (This is where Christopher Alexander and Pattern languages come in as well as Maturana, Varrella and Hiedegger), "Independent Studies", Pierce, Semiotics and Biological Cybernetics and so on.  Bucky and Universal Design Science, Englebart and bootstrap

Experience: Software engineering (methodologies and architecture), Hardware, networking and comprehensive experience with "how things work"

From PA resume (integrate in top sections)

Objectives

To teach by learning and developing new social architectures for collaborative learning environments. To mentor people in organizations to apply these architectures and social processes in their work. To produce leaders who will design and build the open future.

New Directions - 21st Century Husbandry

I have worked for over thirty years as a software and systems engineer. At the start I was enchanted by the technology and learning about system structure from transistors to operating systems, but I was also inspired by leaders, managers whom I worked for or with who touched me on a deeper level.  I began to understand that it might be possible for me to contribute more by learning how we work together in groups.  I also began an inquiry into topics directly or indirectly related to organizations, and what makes them work well, as well as what makes them survive and thrive.

I have a traditional resume that goes from systems engineering to systems operations, and my experience with process design on both the systems and social levels is harder to document as it involved much more personal work and research.  The thread that weaves through all of this is my love of design and architecture, and it goes back to growing up in a home filled with artwork just a few miles from Frank Lloyd Wright's home and studio, dreaming of becoming an architect some day. I also learned to make things with my hands, first at my father's side around our home, then in shop classes at Lane Tech.

I have returned to making and building things in contrast to much of my life's work which has involved the creation of nonphysical things such as system architectures, computer programs and natural language texts. This is where I started; first learning to master physical things, applying paint, cutting wood, designing and building treehouses and much more. I still take things apart to see how they work. Sometimes I take things apart, and now more often than not I can put them back together. Sometimes I actually improve the objects as well as fixing them.

In the course of my technical career, I have used many computer languages and systems, but to list these and emphasize the specific ones would miss the forest for the trees. Most recently I have been learning go to work on currency protocols and Ruby on Rails for content management systems. I have always been self-taught, I first learned BASIC to get a summer job when I was still in high school. I learned Ruby and now Go in order to contribute to Wagn to further currency projects. When I was in high school, I learned  Fortran  and was able to learn enough BASIC from a book to apply for my first job as a computer programmer. Although the motivation was different, the languages acquired have been just as marketable. I put myself through MIT on the money I earned programming in BASIC, and most of my recent paid work has come from learning Ruby and Rails in my work contributing to Wagn. Studying electrical engineering and computer science at MIT, I had a big advantage over my classmates from my early professional programming work.

More important than where we have been is what we are moving to. As our material culture changes at ever increasing speeds, what one needs to know how to do changes. Horses and carriages are no longer day to day technology, now only of historical and recreational interest, but smartphones, clouds and the internet is. Knowing programming, HTML and CSS are just as important as shoeing a horse was in the past. In ten or twenty years you will need to know a host of new technologies and languages that are yet to be invented.

Although the work experience on my professional resume is largely confined to software development and systems engineering and administration, even there my interest in whole systems knowledge can be seen. Because I came up in the hobby computer era before PC when the Apple II was born, I had to learn about hardware and systems on my own in order to assemble a computer system from kits. This gave me the hardware background required to work in the PC industry. I started at Victor Business Products at the same time the first IBM PCs were shipping.

I have a prototype Victor 9000 in my office. This machine could become a learning by doing project to see if it might run again. Imagine a team of learners and doers powering this computer on for the first time in thirty years. One team could be making sure the boot floppies are dust free and the drive is clean and ready, and another team could be taking videos and learning to produce web content to document the process and teach others.

I am even more interested in the social architectures of learning and production. An integral part of any software development effort are the development methodologies used and recently many teams have moved to what are called agile processes. Not a one size fits all methodology, but a set of social processes that are evolved in practice into working norms and process architectures that are matched to the team and its work. I am not interested in abstracting or separating this work in process architecture from the work being done. This meta-work must serve our ends, not only to make the work more effective or efficient, but to serve our human needs to work in supportive communities and to be invested in our work and the outcomes.