Apprentice of the code

While reading these chapters, I realized what it meant to be a software developer and how you have to evolve and change as things in the field change. I really agreed with the thought that developing code is like a craft and you need to hone it through learning from people that are more experienced in the topic or language you are trying to learn. when I did my final project for my CS-348 class I needed to learn other languages and things that weren’t explicitly taught to me and at that time I knew I would need to continuously learn in the field of Computer Science. These chapters said the same thing and reinforced that idea in my mind and I agreed when they worded it as “He’d no longer be a grade-motivated person. He’d be a knowledge-motivated person”. Chapter 3 really resonated with me cause it talks about a feeling that all people in Computer science feel which is that they feel out of place or that they haven’t done/learned enough to be in the same space. I felt like this for a while and it really made consider changing majors for a while when I was really having difficulties with certain projects and assignments. One thing I do disagree with is Chapter 4 in which they try to warn people to not be content with their situation, I think its important to take a breath and enjoy how far you have come and what you have done. I agree that its important to continue improving and learning more than you knew before, but if you constantly push yourself in an unhealthy way, you will find yourself in a deep hole of “I don’t belong here”. People need to be able to enjoy the success that they have created for themselves and worked hard to achieve. The thing that I feel applies to me the most at the moment is how Software developing is a craftmanship, perpetual learning, and not getting stuck in your first language. I think the idea of getting stuck in the mindset of your first language is a common one because its easy to think in a language that you understand fully and apply that as a learning style. reaching out and getting involved in other communities is also another great way to learn and hone your craft because it allows people to communicate their interests to one another and ask for help and advice on things that they might not get or are having trouble with. I want to continue to learn about computer science so the chapter on perpetual learning was really interesting to me and helped me learned new ways to learn more about how I can learn more in the field of computer science.

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

Thoughts on Apprenticeship Patterns at first glance

Apprenticeship Patterns: Guidance for Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover is a really fascinating book that I’ve read throughout the weekend for my software development capstone class. At first, the book seems to be a lot more intimidating as I did not know what to expect from it, but while reading the first chapter and the introduction of five other chapters, there are some interesting contents that I found.
For the first chapter, or the introduction for the entire book, it starts off with the author of the book trying to tell how he started with BASIC and Java afterward and failed to find any interests in them due to the fact that they are not really beginners friendly and I think this applies to a lot of new developers that are constantly trying to get into the field but unable to do it by themselves. He then proceeds to move on to tell about how he found his success years later in Perl and use that leverage to dive deeper into software development such as Extreme Programming and Agile, which I think would encourage new developers to be patient on learning the basic and reading through this book may put them in the right path. I really like this story as it holds true for myself and it reminds me when I failed to learn Pascal, which in that time was described to be one of the easiest languages to start, when I was younger, and it really made me question myself to fit in this field. The author goes on to explain what apprenticeship and craftsmanship as known by everyone and how it is applied to software development. I honestly like how he ties this concept into software development to describe it to be a really long-term process, as we have to learn from other people through being an apprentice and a journeyman to be able to “masterwork” their ability, not just putting together codes and it is certainly not common to think software development in this way.
When I read the second chapter introduction, I think that it has a really great story in the introduction to make help us put aside everything that we know, or empty our mind and be exposed to the material of this book because we might be able to learn something new, whether we are new to software development or not. It is a good transition into the main content of the books that can either help beginners to understand further about concepts of software development, or veteran to solidify these concepts.
With chapter three, the message from the author is pretty clear that it can be really scary to not know a lot at first and we can also find it intimidated to know that there are a lot of people that know much better about what we are doing and it is important to be able to learn from them.
For chapter four and five, I think the authors are trying to say that there will always be more to learn and improve even when we excelled in a lot of fields. I think these chapters should be the most relevant one for graduating student like us as we might know a lot already and even be very good at it, but there will also be a lot more to learn when it comes to work in a real project for a real company.
And finally, with chapter six, the authors suggest that all developers should have their own curriculum to always expand our knowledge in the field. It is important to be able to find resources to read and learn on our own time and it is up to us to catch up with never ending developing technology. It is certainly an interesting chapter to read about to be more efficient on improving ourselves.
Overall, I think it should be a really useful book to read and it certainly be useful with a lot of aspects that it covers for each chapter. I am pretty excited to read more about it.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: First Impressions

I found the readings from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye to be enlightening. I have liked the idea of apprenticeships and the varying stages of skill for a long time, but I have not thought of it as something to consider using in my life before. Considering my CS skills as a craft to be honed is fun and energizing. It reminds me of a game. Starting as an apprentice, learning and improving skills. Making your way to journeyman by fostering connections with others and finally becoming a master and contributing to the industry.

I found the section in chapter 2, “Exposing Your Ignorance,” to be particularly useful for me. I frequently find myself in situations where there are one or more areas of a project that I do not know adequately. It is important to remind myself that most people feel this way at times. This section describes that it is better to be transparent with your knowledge, or lack thereof, than to feign competence. Let colleagues know that you are learning what you need to learn to complete your tasks. This is a bit of a challenge for me. “The need to appear competent is ingrained into people of most industrialized societies.”(Hoover & Oshineye, 2009) Thankfully, this section has reminded me that while I have a lot to learn, it is okay if I am willing to learn.

Another section I read into was chapter 3’s “Sustainable Motivations.” This section is about holding on to motivation through the good and the bad. I empathize with Hoover in “Dave’s low pain threshold.” I too have difficulty with working jobs that I have no passion for. This is what lead me to computer science in the first place. I quite liked this line from Hoover, “While many programmers could probably find higher-paying jobs in the short term, the money that follows from doing what you love will pay off handsomely in the long run.”(Hoover & Oshineye, 2009)

The last area I focused on was chapter 5, “Perpetual Learning.” This chapter’s introduction is about how you must continuously learn new skills or improve old ones to be an accomplished developer. The first section, “Expanding Your Bandwidth,” is about expanding your knowledge through widely available resources. The book recommends following software blogs and “software luminaries.” With the internet, there are countless communities for developers to share knowledge. This section does warn not to constantly use this pattern. Developers should switch between research mode and development mode.

These readings have helped me re-frame the way I view my future career in a more interesting way. I am sure that the rest of the book will contain similarly useful information and I look forward to reading more of it.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

A series of relatively unconnected thoughts about the Apprenticeship Patterns readings

This blog contains mostly random thoughts as I did the reading. Nearly each paragraph is a new thought, but they all build to a whole that is effective strategies I hope to adopt or observations about the way the contents relate to my current place in school and work. Please take note as you read this.

I find it interesting that not only did they take the time to address what you should expect to do as an apprentice, but in outlining how your responsibilities change as a journeyman and eventually master they set you up for what you should expect from your mentors and what to strive for as a mentor. They do make a point of saying it is not their intention to write this book to make effective mentors, but I think despite their protestations it does provide a decent lens for the breadth of experiences, however brief their descriptions may be. While I may still be hardly able to envision my life as an apprentice let alone something higher, I hope to remember at least some of these lessons.

As well, one portion stood out to me very specifically as in the process of writing internship applications I had a cover letter I was very confident in, but realized that I could come off as too confident in it and had not emphasized my willingness to learn and accept new techniques. As a result, I will be going back to revise that letter again.

Unsurprisingly, much of these introductions is spent telling you to get out of your comfort zone for a deeper learning experience, but this should be understood innately, so it feels redundant. However, one good idea was to pick up a lesser documented language and try to write the documentation on your own. You could even do this exercise with an already well-established language to solidify your knowledge of it. In fact, more than just languages this is a great idea for any subject, as the old adage goes: “the best way to learn is to teach”. I have found for myself that tutoring a class while here at school was an amazing refresher for the material that I had forgotten since I had taken it so long ago and I picked up new knowledge that I had missed previously.

One thing that did confuse me a little was these chapter’s seeming insistence on remaining a developer rather than moving on to a leadership position or some other “higher ranking” position. Or rather, the utility of this book to those who wish to remain in software development, which makes a little more sense. With the mention of difficulty in keeping or finding good developers, despite a deluge of mediocre ones, made me worried about proving I am worth hiring or having a team that is uninvested in the work or does not possess anything close to mastery over it.

I was particularly struck by the quote at the beginning of Chapter 6, as I have a lot of trouble finding personal motivation without the structure and reward of grading found in school. Therefore, the advice of keeping a reading list is very pertinent to me as perhaps one way of building my own internal mechanisms for remaining engaged in my field and becoming self-motivated.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 1 and Chapter 2-6 Introductions

               Today, I read through Chapter 1 and the introductions to Chapters 2 – 6 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman for CS-448. The authors, Dave Hoover and Adewale Oshineye, wrote the book as a guide for “software apprentices” – people who have had some experience developing software and want to further their skills. I think this definition fits me pretty well, and this book seems to contain many useful tips that might help me improve my ability to create software.

               The first chapter is the introduction, and it explains the authors’ perspective on software development as a craft. Hover and Oshineye’s idea of “software craftsmanship” is inspired by the typical craftsmanship structure from medieval times, in which craftsmen would fit into a hierarchy made up of apprentices, journeymen, and masters. However, they admit that this system is impractical in the modern world, and they propose a new set of values to improve upon it. This results in a system that encourages developers to work as a community to continuously improve the skills of themselves and others. I think this is an interesting perspective on software development. It takes the familiar structure of medieval craftsmanship and replaces the goal of becoming an expert in the field with a new set of values that encourages continuous learning. One of the values that stands out to me is for developers to have a willingness to experiement and be proven wrong. I personally have become discouraged in myself in the past whenever I have done something wrong while writing a program. I think that using a system that encourages developers to be wrong and be open to trying new things will help relieve some of the pressure I place on myself to do everything correctly.

               Of the remaining five chapters, which I have only read the introductions to so far, I think Chapter 5 seems the most relevant to me. Chapter 5, titled Perpetual Learning, is focused on the process of learning how to learn. Because software developers must continuously learn new skills, even after reaching the journeyman and master stages, it is important that we have techniques to help us learn effectively and understand our weaknesses so that we always know what to learn next. As I mentioned, I have put a lot of pressure on myself to always know the correct way to do things while writing a program, and I often become discouraged when I do not know something. This chapter’s introduction has indicated to me that even a master developer must learn new skills constantly, and that it is more important to be able to learn well than to know everything. This introduction has already given me a new perspective on the process of becoming a great developer, and I think the learning techniques it introduces will help me improve my skills more effectively.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Ugh A Textbook Reading…Or?

Ugh A Textbook Reading…Or? Wait what’s all this!

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

The beginning of this book really made me feel comfortable with the reading to come. To be honest I was dreading this assignment because of the reading. However, it really reassures the reader of the purpose of the book and kicks the basic textbook mantra. Something I found quite interesting about Dave’s story was that he had failed multiple times and he still found his way into the field. He actually had help from others but it seemed to be that the most help he got was going out on his own and finding a source of his own that he could understand before he could understand the sources (or basic textbooks) that were given to him. As a new programmer myself I like this idea, sometimes your own path is longer, but perhaps a smoother one for your development. 

A great thing about this book and chapters 1-6 is it’s romanticism of the future of programming and programmers and the formulation of a guide for them. They want to see the future ‘emerge’ without repeating past mistakes just like in the medieval Europe example, the past was riddled with abuse and mistakes. I enjoy the many examples of authors who express the ideas that failure and new ideas are key in this industry, in anything really. The best thing you can do is give the effort and use failure to formulate a map and acquire a “growth mindset”. It really has the sense of a pep talk in it, it not only inspires me to keep on reading but to remember to push myself in my efforts in software development. Sharing of knowledge also seems to be a key trait to have in this industry. Helping others to grow can also help yourself to grow, I like the idea of swallowing pride and asking for help or opening up to another when you are asked for help.

Emptying the cup Chapter 2 was probably the most interesting and simply eye opening chapter for me. It was like seeing someone else get slapped for doing something that you are also doing. I see the same mistake in me as I do in them. I have learned Java and C and whenever granted the possibility of exploring something new I have always chosen to be a creature of habit and to recede into what I know best. Well maybe what I know best isn’t what is best for me. At such an early stage in my development I should certainly explore more, even just the introduction of this chapter was powerful in making me realize that.

I also really enjoyed chapter 4 Accurate Self-Assessment. I often use the term big fish in a little pond when discussing one of my other personal interests, music. Performing music pays to be a big fish in a little pond but at a certain point one will realize they’re pond is tiny in comparison and therefore so are they. It’s okay to be content with that but I find success in growth. I think it’s important to outgrow your pond and move on to another. I think it’s important to ‘be the worst’, you can only go up from there and mistakes and failures will help you grow! I’m glad to see I can  relate more of my personal self to this reading.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Beginning Apprenticeship Patterns

This weekend I have begun reading a fascinating book called Apprenticeship Patterns by Adewale Oshineye and Dave Hoover as part of my software development capstone class.

As I was reading through the first chapter, my initial impressions were this book would be helpful but I found it surprising that the authors state there is an actual “need” for books such as this one in order to be successful as new software developers. Before reading this, I was sort of under the impression that entry level positions would be more friendly to new developers with other more experienced developers helping you along the way.  I also found the quote from Pete McBreen to be rather surprising too, I never thought there was an “abundance” of developers, as most articles you read tend to give off the impression there isn’t enough software developers. This first chapter and the way this book is framed in the idea of software development being an apprenticeship has certainly begun to change the way I am thinking about the field and how its not just a job but a lifelong journey.

This section from the first chapter also has begun to change my thinking in how I view my early jobs in software development. I never really thought of the first job you have as a developer in terms of focusing and learning for yourself, I have always thought of it as starting position and performing a task for a company, but I do like this idea of “selfishness” in the beginning.

Chapter 2 seems like a good chapter to start with in this book and will be where I begin with reading and learning about the various patterns. I particularly like the idea of learning how to sort of reset yourself to be able to learn new information from others who are more experienced than you. I find this chapter’s introduction to be especially relatable as in learning I strongly prefer to listen rather than talk so I think chapter will have some good patterns to learn from to further strengthen my learning skills as a listener.

I am also interested in reading Chapter 3, as I find the story of Dave very relatable with having only a small amount of knowledge at the beginning and finding it daunting to know there are others who know so much more than you and how to learn from these people, especially during the beginning of your career.

I want to read Chapter 4 as I agree with the message and want to learn how to strive to continuously improve as a developer instead of becoming complacent and satisfied with the current knowledge of a skill.

Finally, I want to examine Chapter 6, especially with the idea of learning more by reading books and how to do this with regards to software development. In particular, I hope the patterns in this chapter helps elaborate how to find the time and motivation to do so when it is no longer “assigned reading”.

Overall, I am excited to begin diving into the patterns in this book, particularly the ones in the earlier chapters as these seem like they will be the most helpful to me right now with where I am as a developer.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns

This week we were tasked with reading and reviewing chapter 1 and the introductions of chapters 2-6 of our book, Apprenticeship Patterns. 

Chapter 1: This was a great introduction to a book. I am not a person who usually reads books because I usually find them boring, but I have to say that this introduction has really grabbed my attention. The parts that really stuck out to me was the very first paragraph, and Dave’s Story. I loved the first paragraph because it says that the book is for people who “have had a taste of developing and want to take it further.” This is an important quote because that includes me and every CS student at Worcester State. This capstone project is some student’s first taste of real development. I really liked Dave’s story too because it reminded me of myself, I have had trouble with software development in my time here at Worcester State, but through my classes, I have developed confidence in my abilities, and learned a lot. The description of apprenticeship also reminds me of my internship because that is what I am doing there. I am basically learning from my master by doing small projects that give me experience.

Chapter 2: I felt that this chapter was more irrelevant because most of us have already passed the step of choosing our first language. By first language, I mean choosing one that we will become fluent in. I have chosen Java as mine because that is what I have learned the most about, and it is the primary language that my job uses as well. However, this chapter did show me that you don’t have to be proficient in multiple languages, but you should master one of them. I also really enjoyed the connection between apprenticeship and the “Tasting a New Cup of Tea” story. It has a really deep meaning of getting rid of bad things, and learning new and better things. I will also be using that empty java class technique for when I need to test unknown features.

Chapter 3: I felt as though this chapter was a direct attack on me. Honestly, I am one of those people that is in this field for the money, and I will probably be taking the job that offers me the highest amount of money. However, after reading through this I will be thinking about learning more about the long road as it could help me enjoy what I do and make a lot of money along the way.

Chapter 4: This chapter was great. I love the “Be the Worst” mentality because I do think like this, but unlike these other people. I haven’t been using that to better myself. I always just assumed I wouldn’t be as good as them, but I should be using that as a way to learn more so I can become as good or better than them.

Chapter 5: This chapter was less interesting to me because it told me stuff that I already know. I know that I need to expand my horizons when it comes to software development. Another reason I disliked this part was because it told me to do a lot of reading, and as I mentioned before I do not like reading. I’m going to use this section as my chapter 6 review too because they both have to do with reading. Chapter 6 was irrelevant to me because I don’t have an extensive reading list nor plan on having one.

 

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

From Apprentice to Master in Software Development

Having read and enjoyed other books written in the same “pattern” based format, I was excited to start reading Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. Over the summer I stumbled upon the Art of Game Design: A Book of Lenses by Jesse Schell, and after seeing how much Christopher Alexander’s books The Timeless Way of Building and A Pattern Language influenced him I decided to read those as well. Not only was Schell, a pioneer in game development, influenced by Christopher Alexander’s work but I have also read many other books written in a similar format such as the Gang of Four’s Design Patterns book. When Christopher Alexander wrote A Pattern Language he clearly stumbled upon a formula that works.

Humans have an amazing ability to spot patterns and using that ability to our advantage when trying to create guidelines for others to follow no matter the subject matter makes complete sense. A book like Apprenticeship Patterns hands the reader a bunch of scenarios where each pattern can be applied. Rather than going into a situation blind and, in hindsight, realizing the inefficient mistakes you are making , the reader can then pull a pattern out of their metaphorical “tool-belt of patterns” that fits the situation and use that to gain an advantage. These patterns are not picked out of thin air, rather they should be crafted from detailed observation of problems that seem to arise often and can be tackled using the same solution repeatedly.

While so far I have only read the introduction chapter and the intro to each chapter of patterns, it seems as though the authors have given the idea of apprenticeship in software development an extreme amount of thought. I have read other writings about software craftsmanship that seemed to have a romanticized view of the medieval model of craftsmanship in their head when talking about software development. As Oshineye and Hoover stated, “We do not wish to repeat the mistakes that moved this model to the margins of modern society”. There are clear reasons as to why this way of developing a craft no longer is prevalent in society today and it would greatly benefit us in our discussion of software craftsmanship to acknowledge this and instead take pieces of the craftsmanship model and the standard practices in the industry in order to build a hybrid of the two. Not only do I feel that the authors take a realistic approach to software craftsmanship, but I feel as though they also chose patterns that greatly benefit myself and others at the beginning of their journey as a professional in software development.

After reading the introductions to each chapter I feel as though all of the chapters will be highly beneficial to me as I become a software craftsman, yet I can’t help but feel as though many of my shortcomings as a developer are talked about in chapter 2 “Emptying the Cup”. Throughout my life I have always been afraid of showing weakness or ignorance, something that has definitely hindered my learning potential in the past. This chapter focuses on making sure your pride as a developer never gets in the way of learning. The patterns I am most interested in studying are “Expose Your Ignorance”, “Confront Your Ignorance”, and “The Deep End”. Learning how to be unafraid to show that I don’t know something and then moving past that in order to learn seems like it is one of the most important ideals of a true software craftsman. Not only that, but “The Deep End” seems to be a pattern that is relevant to me today. In my Software Development Capstone, the class I am writing this for, we are getting thrown into the deep end when it comes to the system we are developing. I have been having a lot of stress about not messing this opportunity up, but if instead I look at it as an opportunity to learn I feel like some of that stress will be relieved.

I am extremely excited to absorb as much information from Apprenticeship Patterns as I can during this class. Not only do I plan on reading it through, but I plan on keeping it in the stack of all of my other “pattern” books as a reference that I can look to if I ever feel lost or need help getting on “The Long Road” towards becoming a software master.

 

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Familiarize myself with LibreFoodPantry

For the project LibreFoodPantry, although it is pretty new, its main page already includes a lot of useful information about the project as well as related topic such as licensing, code of conduct, and the change log, which I think is really important for users, and developers, establishing professionalism.

What I found the most useful item in the website is the Principle behind the Agile Manifesto. This item provides a really brief, but essential core principles for developers to correctly used Agile. As Agile documentation can be a lot and frustrated to go through, I think that this would be an better way for the team to understand them and to make good decisions on the project. These principles pretty much emphasize the value of customer satisfaction, encourage the team to work together as much as the project requires, improving the work environment for developer and operation team, and at the same time cut major costs for the project.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.