Apprenticeship Patterns, first impressions

 My software dev capstone is a few weeks in, and I have been tasked with reading a textbook titled 'Apprenticeship Patterns', written by Dave Hoover. The book reframes software development in an interesting way; it structures it as a craft, with the necessary skills developed through an apprenticeship as if it were a conventional trade. The apprentice has a master they work under, who acts as a goal to work towards, with the intention of becoming one themselves. Importantly, it presents this not necessarily as a rigid structure or protocol to follow, but more-so a mindset to inform your decisions. Instead of seeking out a specific track to follow, it suggests you try to turn your day-to-day operations as opportunities to learn, by seeking feedback or mentorship. In other words, it encourages you to actively look for improvement. 

I haven't read the entire book, so far I have only read the first chapter and the introductions of a few subsequent chapters, but it is pretty interesting. Barring the novel "apprentice", "journeyman" and "master" system, what stuck with me was the mindset and ways of thinking its promoted. Being a college student, I am very used to structured learning. In terms of my academics, until recently it has really been the only thing I've known. However, I have also been a member of a research team at my school for a while now, and have gotten a sense of how relying on this structure can fail you when you are under time constraints. Adaptability and being able to quickly solve problems is very important, and potentially going into a software dev job I'd imagine this would be no different. You need to quickly educate yourself on new issues that could arise and be able to solve them as well. This ties into another teaching the book brings up: exposing ignorance. You aren't going to be able to know everything, and you aren't going to be able to solve everything; it is okay to fail, but you should absolutely be taking "preventative measures", in other words trying to figure what you don't know so you can start fixing that. These teachings line up with the agile method my professors have been having us learn in my higher-level cs courses, and I agree after having some degree of "real-life" experience now that this way of learning is definitely worth thinking about, if nothing else.