Tracing the long lineage of software that brought us Vim.
I have been hesitant to write about the details of the coding I do and about the decisions I make while developing software. I feel that very few people I know would enjoy reading that sort of content and therefore I hesitate to spend the time writing it. Instead I simply focus on the coding itself as time allows. Expanding the group of people I know and connecting with those that find these topics interesting was a primary motivator for me in coming back to blogging. Maybe ensuing conversations will make me a better developer and enable me to accomplish more. I like this possibility very much. However, in adopting the perspective of a non-developer using WordPress, I somehow fell into blogging from this perspective too.
Clearly, it’s not that WordPress is affecting me this way and I do not mean to say anything for or against this particular project or any individual that I have been chatting with on this. Rather, I see that by foregoing a journey of self-determination, making and using my own tools, I have rapidly arrived to a completely functional and reasonably well-appointed place which I was not in a hurry to be in. The journey continues to be the interesting thing for me.
I often encounter this mantra: don’t reinvent the wheel. I don’t like that there is no ‘depends on the situation’ disclaimer included there. Yes, in business, the rapidity of reaching the goal is a key quality to consider. I am not so constrained, 24×7.
Consider a farmer. The land is cleared, plowed, and planted. The crop is sown, nurtured, harvested, stored and brought to market. I expect there is more to it as well. I am not a farmer, but I expect a farmer to know these details. Consider now one who sells farm produce. I expect a produce vendor to not have detailed knowledge of farming. A junior produce vendor may hear from the senior vendors, “don’t reinvent the farm.” Makes sense if you are indeed pursuing a career in produce vending. A bit sad if the young person has the soul of a farmer, and stands at a fork in the path, where seeing clearly the farming and vending aspects coalesces to new and synergistic innovation in vendor-farmer systems.
It’s been my good fortune to secure a career which aligns with my lifelong pursuit and passion for systematization in computer programming. At work, I practice a disciplined approach to avoid costs: don’t reinvent the wheel. Outside of work, I pursue the goal of self-empowerment; of complete details as minimum viability. I study minor aspects of complex systems so that I might take personal responsibility for what I may recommend others to use, as components and dependencies. This naturally improves my day-to-day effectiveness. It is time consuming to do so, on my time, as desired!
In all the world of people in vocational specializations, when we go seeking the construction details of some modern, useful artifact, we must eventually find someone who speaks with authority, and does reference clear evidence when the question is asked: what is a wheel? I choose this vocation, software development. I think it reasonable for you to expect me to know the details.
This little funk I’m working through is all too similar to an earlier time, and to an important lesson I learned then – not to attempt to paint a picture of myself, based on what I think other people want to see of me, but instead to be genuine. It’s much easier.
Now back, back, back to knitting my own washcloth.
Some 4500 words after I decided to add a few comments and insights ... it’s a good idea to consider what happens when follow a handful rather simple and obvious rules of how to write code.
… concerned not just with the packaging of data (syntax), but the simultaneous transmission of the meaning with the data (semantics).
HTML and CSS have very good semantic compatibility, often appearing together in the same document.
This is on my mind lately as I consider the compatibility of web application sources with microformats, while building a utility to help identify any aspects of the web application sources which interfere with the desired interoperability embodied by microformats.
I currently describe my pre-release project as: “A utility which checks webapp sources for compatibility with microformats semantics”. Based on the foregoing, I’m considering changing the description a little. At the end of the day, the work is the program that helps find the issues in the code. I’m hopeful that someone with greater comfort discussing the topic will help me to gain some confidence in how I present the program. So long as it is providing some useful and desired outcome, I’ll be working on it for awhile longer. Hopefully work to benefit more than myself!