Web development is a craft. For some, web development is a matter of engineering and there is nothing wrong with that; however, I prefer the notion of craftsmanship due to an admiration of community over academia, and a strong preference of the relationship between apprentice and master versus student and teacher. There are many similarities between the two paths of acquiring knowledge, but there are a few notable distinctions. The master teaches the apprentice practical knowledge such that the apprentice is able to sustain his/her life practicing the given craft. The teacher mostly injects theoretical knowledge into the student's mind, in hopes that one day the student will expand upon said theory in order to maintain the momentum of progress in a given school of thought.
For a period of time I had the pleasure of working as a bicycle mechanic. I could have chosen to study the theory of mechanical engineering, which would have left me capable of applying theory to cutting edge consumer bicycle technology, or rather, furthering the study of mechanical engineering. That was not a path I was interested in. My interests were more focused on supporting and empowering the local cyclists, be they children, the elderly, the disinterested, or the obsessed. This required little theory, and a large volume of both experiential and practical knowledge that had been passed down through a lineage of bicycle mechanics
I no longer repair bicycles, and have moved on to develop and/or repair software distributed on the internet. The target community has gone global and the number of craftsmen in the given occupation has grown larger. My ambitions haven't changed much, as my highest goal is still empowering others. Though there may be many who would scoff at the notion of a developer not classically trained in engineering, I remain grateful for the opportunity to be an apprentice; learning once again under those who have mastered the craft.
Fortunately, there are others who share a reverence for the craft of software development. Authors Dave Hoover and Adewale Oshineye have written a book which gives practical advice to those who choose to follow the path of the apprentice instead of the student. Aptly titled, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman reads like the classic Computer Science textbook, Design Patterns: Elements of Reusable Object-Oriented Software, in that it is comprised of a series of patterns discovered in its given domain. The book contains six chapters which logically group these patterns together, and many of the patterns reference each other. These bite-sized patterns are easily digestible, and one isn't required to read them in any specific order. One can read through a given pattern in a matter of minutes, which is helpful to those with shorter attention spans.
For those choosing to "Walk the Long Road" (ch. 3) of mastering web development, I highly recommend reading this book. Co-author Dave Hooper worked as a family therapist before moving over to software development, which gives him a unique perspective, not often found in technical writing, in that it tends to read like a Sartrean discourse on solving one's own existential dilemma. The patterns contained in the book encourage the reader to keep one’s motivations in check, find a community of others who use similar technologies, and constantly learn without burning oneself out. I found these and other gems of advice directly applicable to my own journey.
Two tips that stood out to me as an apprentice were the complementary patterns titled "Expose Your Ignorance", and "Confront Your Ignorance". In regards to exposing one's ignorance, the reader is told that:
The most obvious way to expose your ignorance is to ask questions. This is easier said than done, particularly when the person you're asking has assumed that you already know the answer. Press on! Sure, you could protect your pride and take less direct routes to obtain the required knowledge, but remember that your road to journeyman will be shortened by taking the most direct route available. With practice and time, you will find that asking direct questions to the most knowledgeable people on your team will become second nature. While you are exposing your ignorance, you are also exposing your team to your learning ability. And sometimes they will gain a new clarity about their own knowledge in the process of answering your question. (ch. 2, sec. 5, p. 8)
The authors then move on to say that always exposing one's ignorance must be met with confronting it. Essentially, one must learn alone at times, and by failing to recognize this, one may come off as dependent upon the answers of others. This may sound obvious to some, but there exists a fine line between drowning in work due to one's pride getting in the way of asking questions, and drowning others in a sea of questions because one lacked the diligence to pursue answers independently.
At face value these patterns may not sound like a breakthrough in career development, but I have certainly gained insight in sustaining a life of developing software. The eloquence with which the authors expound each pattern is certainly refreshing, and has left me thinking deeply about what it means to be an apprentice, as well as craftsman.