Apprenticeship Patterns Blog 6

 Chapter 6 of the Apprenticeship Patterns titled Construct Your curriculum was very insightful to me. It teaches ways on how to keep track of the progress that an aspiring software craftsman is making over a period of time. I believe that perhaps if I had received the knowledge shared in this chapter, I would have been better organized and learned much more than I currently do. The chapter starts off by recognizing that one can learn everything at once but instead by making smaller progressive accomplishments to achieve a huge task.
 
The first concept shared was creating a reading list. This helps the apprentice to keep track of the books they’ve read, currently are reading and what they plan on reading next. Personally, I’ve read several programming books but never really thought about keeping track of them, however, I plan on maintaining a reading list so I can plan systematically and be able to test myself on the knowledge I acquire in the material read.
 
The author also encourages that we read constantly and focusing our thirst for learning on consuming as much of the written word as possible. Blogs, podcasts, audio books are also good, but emphasis is highly placed on the physical books. I believe having a book in your hand reduces the chances of distraction compared to the other forms especially audiobooks where the listener is tempted to multi-task on activities. This eventually reduces productivity and retention of the information being shared. This concept coupled with creating a reading list look like a great way for me to go.
 
Moving on to digging deeper, I agree with the author that we live in a world of tight deadlines and complex software projects that use a multitude of tools and we find ourselves not having enough time to learn enough a given platform that we are working with. Instead, we resort to selecting a handful of tutorials and libraries to come up with a solution. This works most of the times, but we’re actually limited when other issues arouse from the said solution we created. An example I interfaced was when I worked on a project where we had to access data using an id of the object in the database. The id would be passed into the URL of the http request in plain text which was a security vulnerability for the database. We were successful in accessing the data but exposing the id of the data object was not a prudent idea at all. This amount of technical debt is dangerous but happens too often as project managers want to quickly ship products to the client. The major problem, however, is the difficulty that comes with maintaining such code as it may turn out that corners were cut and simplified complex issues, the author noted. I agree with this, and that things could also turn out worse in case of clients’ data being leaked resulting into unfavorable situations such as lawsuits.