Giving Appreciation to the Patterns

For this week, I have been tasked to read Apprenticeship Patterns written by Adewale Oshineye and Dave Hoover.  What I read from the book was the whole chapter 1 and the introductions of chapter 2-6. They were pleasant to read and they taught a lot of things greatly.  Each of the chapters starts with a general scenario that speaks to the subjects discussed.

What I find useful from reading this book are the general advices we usually hear in life that have been rephrased and it works effectively. These advices really helped my perspective of what to do with multiple languages for my career like for example, finding the time to have a moment of reflection. In some time, when there is a point we feel really stuck in our path, maybe it’s time to step back and reflect on what we can do with the languages we gave effort towards. Reflecting might bring new light to which what you want to pursue next and sure, it can be longer to reach goals from it. But the more we learn, the more potentials we will be able to show to others and ourselves.

Reading this book has changed of how I will now work towards my career. Not only I will try to continue on improving the languages I already know from classes and on my own, but also I will find what languages that are new to me and explore what potentials it can bring if I desire it. I don’t disagree with any of the chapters I had to read. This is because they expressed the scenarios and questions that were simple but well thought out in a sense.

To me, the most relevant chapters would be Chapter 3: Walking the Long Road and Chapter 4: Accurate Self-Assessment. For chapter 3, it definitely gives an understandable perspective when it comes to pursuing a career in the world of technology.  It is true that awards or certificates show that you come far to make a good starting point. But this is only one of the things you can show easily and it’s not everything you can do just by having it. What we want to do is not only appreciate in doing the steps like training but also continue the journey of the path we chose to walk on.  When it comes to Chapter 4, it reminds me of how I tell myself thus far to get where I am today. There is nothing wrong with saying that we want to be better. But comparing ourselves to others, it won’t make a difference unless we put the efforts in and shape our own abilities. What matters is that we show we can improve and become who we want to be.

 

Link to the book: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/#toc-start

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance|| Sam’s Ships S.S.2

Sams Ships (1)For this next installment of the Apprenticeship Series, I wanted to discuss Expose Your Ignorance. This apprenticeship pattern involves being more direct with people to have the faster route on the road to journeyman instead of protecting one’s pride to find other ways to obtain the knowledge they are seeking. When someone exposes their ignorance, they will be able to learn more quickly instead of trying to appear like they are capable.

Based on what I have learned of this pattern so far, my reaction is that it was useful seeing examples of how this happens in real life for people. To me, this was something I thought of before without putting it into a framework of sorts. I found that this was interesting because of the way they explained it saying, “One of the most important traits that a craftsman can possess is the ability to learn, identifying an area of ignorance and working to reduce it.” It shows how ignorance does not necessarily mean they are at fault of something, it just means they are willing to work to move past it.

Taking this as a lesson to think about, the way I work will be pretty much the same. I once almost made a task over-complicated because I wanted to find my own way to work on it instead of just asking another developer for their opinion on whether I was doing something correctly. After deciding to ask for help thought, we figured out that there was a much more simple way of going about it instead of changing a whole system of developing a certain feature. Due to this, I have gained more confidence to ask people when I am uncertain about something because in the end it would save a lot more time and avoid confusion.

I did not disagree with anything brought up in the pattern so far because I believe people should be able to communicate when they are not confident about something or at least ask for clarification. After some thinking, I realized I’ve never expected anyone to know everything so why should I feel like other people should expect the same from me?

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

The White Belt || Sam’s Ships S.S.1

Sams Ships.png

So you either want to or have already been an apprentice for software development huh? I just read the section on the apprenticeship pattern for The White Belt and it was a nice beginning to approach what we are doing. It reminds me of a quote: “In any given moment we have two options: to step forward into growth or back into safety.” This is us stepping out of our comfort zone as we approach real-life situations and try to help them by starting our journey into development.

A summary of the pattern would be after some time of developing skills, someone may feel that their growth has plateau-d, however there still remains confidence in their abilities to do something. I found that this was interesting because as someone approaching a career where I will be a life-long learner of technology and ways to develop it, I never considered getting stuck or feeling like I was not getting somewhere.

Based on what I have learned about the pattern, I think it will change the way I work based on their advice to set things we have previously learned aside in order to “unlearn what we have learned.” I like the idea of approaching something that is new to be able to fully appreciate it.

I could relate to the situation they describe about sacrificing productivity in order to improve our skills. From on-boarding as a junior developer, it was a different experience trying to do self-learning while getting assigned tasks to work on at the same time. It was interesting trying to find a good divide between learning something while trying to develop things compared to using internet references.

I agree with how they mentioned not basing everything you learn in other languages based on comparing it to a base language that you know. This made me realize how I have been doing this for a while; I sometimes forget that not everyone knows Java or a language that would seem “universal.” It would help take away the stress of thinking in a certain language’s syntax or process; allowing people to just code something that would work more efficiently and effectively.

Overall, I would say that this pattern is nice to hear about in the beginning so people can approach it in a way that allows them to learn things with a fresh start to programming. I also just liked how they called it The White Belt so people can level up.

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Apprenticeship Intro

As you decide to follow a Software Development or Engineering career path, you should consider this path has lot of knowledge that need to be accumulate in case you want to move forward. You could be a Computer Science student or an entirely self taught developer, you should learn how to take advantage from other … Continue reading Apprenticeship Intro →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Expose Your Ignorance

To start off with Apprenticeship Patterns, I’m going to look at Expose Your Ignorance from Chapter 2. This pattern jumped out at me largely because of something I brought up in my introduction post regarding “putting on airs” in order to appear more qualified than you currently are.

The problem that this pattern is looking to solve is for when external pressures are demanding that you deliver high quality software. This often becomes an issue when you’re unfamiliar with a required technology. Sometimes you’re brought onto a team for a particular skill and you haven’t expanded your skillset to encompass all of the team’s work. Or, perhaps, you’re the only one that they could find to do the job, even though you may not be as qualified to do it as they’d prefer. Those around you are relying on your ability to perform in the face of inexperience.

The solution that is offered is to approach the situation humbly. Accept your inexperience and seek the answers. “Putting on airs”, as I said before, will only make your job harder. If you convince those around you that you’re more experienced than you are and you end up delivering a subpar product, your inexperience will be exposed. On top of this, you will have inadvertently rejected learning opportunities to maintain your image of expertise. Instead of this, aim to be open about your lack of knowledge in this area. This will allow you to perform better than you would otherwise, as you get to genuinely learn the technology on your path towards development. It shows those relying on you that you’re capable of learning and doing sufficient work (or better) in a pinch — and it’ll strengthen your bonds with them as well. We want to work with people who are capable, and including your peers on your journey in self development will show them exactly that. Not only this, but as the book says, rejecting this opportunity to grow can cause people to get settled into one particular niche and become experts in their area. That’s never a bad thing, the industry needs experts. However, an expert is not the same thing as a craftsman. A craftsman is flexible and always searching for the chance to learn and grow as opposed to locking themselves into one discipline and learning it through and through.

What action can an aspiring craftsman take to usher themselves towards the solution for this problem? Make visible your ignorance to your coworkers — the book suggests a list with 5 items on it that is in a visible place. Maintain that list well, update it and refresh it as you expand your skillset. It’s important to show others that you are constantly seeking growth in your craft.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

This blog post will be on the chapter “Expose Your Ignorance” in which the author talks about how, especially as an Apprentice, you should not be afraid to simply ask questions. I feel the author points this out with a very simply line “the need to appear competent is ingrained into people of most industrialized societies”. For myself I can tell you that this is very much the truth, I have been that guy at a job trying to appear competent when I had no idea what I was doing. But, just as the author puts it, you have to be willing to take a few hits to your pride, to progress as a person and ask for help from those you know can. Not only do you learn yourself from this experience, but those around you that you ask for help see you being humbled, and see you growing, in admitting that you needed the help. “Your instincts tell you to hide your ignorance, to feign expert knowledge, but this only stunts your growth and inhibits the work you are trying to accomplish” (David H. Hover). Something else that the author points out is the need to continue this learning process, because this is what it means to be a software craftsman. It is when people stop their continued learning from one subject to the next become experts, and while this is not bad it is not the same path as that of the craftsman. If you stop growing yourself, you can never progress to being a master, but rather you will be highly specialized in one area. This expertise is not a bad thing, but with how broad of a scope software craftsmanship has simply having expertise at one or two subjects puts you nowhere above a Journeyman. Overall I feel this pattern is a very good one for anyone pursuing any subject, because it reminds the reader to stay humble and to ask questions when you do not know. Trying to act like you know something that you do not, will only have other people looking at you like you are a fool, when instead you can show those people your willingness to grow as a person.

From the blog CS@Worcester – James' Blog by jdenesha and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns CH. 1 & CH.2-6

Welcome back to Dcanton’s Blog, today I will going over my takeaways from the Apprenticeship Patterns book by Adewale Oshineye and Dave Hoover. The reading described the 3 roles in software craftsmanship, these roles are the apprentice, the journeyman, and the master. Reading about this helped me realize the depth and responsibilities that come along when going through each role. I think the role that intrigued me the most was the Journeyman, it seems like the most challenges are encountered at this stage. Oshineye says “he moves between projects and masters, seeking to diversify and deepen his portfolio; he seeks to elevate his status within the community;”. From the reading I gathered that this role takes up the most time and that this is the role that many people can get stuck on but the reward of making it to the Master role is worth it. All 3 of these roles play off of each other and chapters 2-6 give insights to some of the problem people might encounter and solutions to help improve in different areas.

In Chapter 2 ’emptying the cup’ it talks about having one solid programming language under your belt to solve problems. This is something that I completely agree because with the amount of languages out there, it can be daunting and make you feel that you need to know a lot of these languages to solve a problem. When I first started learning to program I had the mindset that if I try to learn multiple languages then the problems I run into will be easier to solve but I have since learned that sticking to one language at a helps you grasp and apple more techniques about that language.

Another chapter that I learned from is chapter 4 ‘Accurate Self Assessment’. This chapter talks about the problem that affects to many people which is, the rate of learning has leveled off. Finding motivation to strive to get better is only half of the battle because motivation can only take you so far, Its discipline and drive that are the key to constantly improving. The chapter also says its better to be a small fish in a big pond than a big fish in a small pond. By surrounding yourself with developers better than you, you can learn much more and see yourself grow to their level. That is why it is crucial to not get complaisant when you reach achievements, keep setting goals and record the milestones. An issue I struggle with is that after I solve a problem or finish a project i’ll get laid back and try to ride the success for as long as possible and the result is I get too comfortable. This chapter gave great advice and I recommend you check it out.

Overall the content in the book is great for developers of all different levels. After only 6 chapters I have taken a lot away and plan to continue reading. I plan to apply what I learn on my road to becoming a master! I will link the book below, Thank you for reading and I will be back again next week.

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/

 

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

B2: Concrete Skills

            The “Concrete Skills” pattern is described as a way be able solidify and maintain skills that would be helpful in a work environment. The book explains that many teams don’t really want to hire someone who won’t be able to help with the workload. There are too many situations where you would be a detriment with the lack of experience and skills. The books then goes on to talk about the possible solutions, one being to gain the ability to learn quickly. This can help show the team that you can be put to use in a working environment and not need to be supervised. It can also build a better relationship with the team by reassuring them that their efforts and time are not being wasted. Another strategy that is important is a great understanding of your first language since it can help you create a starting point within your first job. The book explains that communication and professionalism can be a strong driving force that accent your skills within your first language to better show off what you learned to employers.

            I found this pattern to be interesting in the sense that it relates to many new software developers looking for jobs. The through-provoking idea of being thrown into a software dev team that took a chance with a new developer is daunting to me. I find that if I was in that situation, I would need to work twice as hard to prove that I’m worth keeping on the team and that I have skills that can benefit everyone. This pattern shows me that concentrating on my programming skills and knowledge will be useful, but I will also need to have good communication skills as well to make sure that the team understands my viewpoints. I haven’t really thought about how important these communication skills and professional attitudes interlock with each other, but this pattern has shown me the importance of both. I agree with this pattern for the most part, however I found that it didn’t seem to give enough information about how someone could find their concrete skills in a team setting where many team members are already much better than you at your own language. Overall, I found this pattern interesting and very insightful.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Bringing Back the Apprenticeship

Good day again my fellow reader! Today, I have read a chapter and some excerpts from the book, Apprenticeship Patterns. This book focuses on changing the mindset of the reader in regard to learning the art of programming. The traditional mindset of learning programming is more of a being talked at model. A teacher will talk at the students, and the students will repeat what the teacher says through classwork, homework, quizzes, and tests. This method of teaching does not lend itself well to programming where problems can crop up out of nowhere, and curveballs are always just around the corner. Apprenticeship Patterns puts forward the idea that for software craftsmanship, the apprenticeship model is a more fitting model to create well trained software craftsmen.

The apprenticeship model that Apprenticeship Patterns champions, is the classic model from the medieval era of apprentices, journeymen, and masters. The apprentice begins learning and doing small tasks and over time, will graduate to bigger and larger tasks and responsibilities. An apprentice, when he is ready will graduate into a Journeyman. A journeyman studies directly under the master. In addition, a journeyman is tasked to travel from master to master, expanding their knowledge in the craft and learning multiple styles from multiple different masters. This rounds out the path of a journeyman and eventually, they will attain the rank of a full fledged master. They will then continue the tradition and take on apprentices and journeymen just as their masters before them.

This cycle of apprentice to journeyman to master is a cycle that worked well in the medieval times but in today’s world, this model no longer fits anymore. I do agree with the statement that the apprentice’s apprenticeship was the sole responsibility of the apprentice alone and their success ultimately depended on them. This holds true today for the modern student but to a lesser extent as a student does not learn in the same method as the traditional apprentice. For the traditional apprenticeship to be revived in today’s modern times, there would be a drastic change in today’s society and in how the educational institutions operate. I am not sure how a modern apprenticeship for software craftsmanship would look like, but I believe that it would definitely produce a high level of software craftsmen.

The other chapter introductions discussed patterns that a software apprentice would go through in their educational journey. The first few patterns form a solid base for the apprentice to learn and grow in their journey. The next couple chapters have patterns that continue to grow the apprentice and nurture them into the position of a journeyman. These patterns take the journeyman outside of their comfort zone and allow them to grow through agitation of what they are comfortable with. The final patterns take the journeyman into a master by having one constantly learn and creating a feedback loop to keep one learning. These patterns look very interesting and I do hope that I will be able to apply some of them to my learning journey as well.

Let us see where these patterns lead us and see you next time!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

The first chapter and the next five chapter introductions draw an outline for a general guide to how to learn. The relevance of software development or of the term “software craftsmanship” seems to go away after the first chapter, where the rest is just about self improvement and how to learn. I agree with the points being made in each chapter, but I am also recognizing that these ideas seem to extend to literally every field of study, and not just software engineering. Throughout most of the reading, I was actually thinking about mathematics and not software development, and the ideas apply just the same.

I think that chapter 5 seems to be the most relevant to me. I know that I have learned a lot already, and I am also aware that there is a lot more that I do not know, and even more that I am not even aware of. There is a lot of content to learn about that I find interesting, and I always seem to find that I am preoccupied with other tasks such that I am unable to spend as much time looking into new interesting material as I would like. I started reading the beginning of chapter five just as I was thinking this, and the chapter opens with a quote, directly relevant to that thought, about how there will always be some distraction from learning, so it is necessary to seek knowledge anyway even when the conditions are unfavorable.

I think the idea of “emptying the cup” from chapter 2 is also relevant. Chapter 1 mentions that somebody may recognize that they are at the beginning, as a newcomer to software development, even if they have already been programming for several years. I think it would be likely to have been exposed to some software development projects and practices during the “several years” of programming, so the term “beginner” does not seem to fit very well for somebody with that much experience. On the other hand, somebody who has been actively learning to the extent described within these chapters will definitely have transcended their level of experience. The idea of a “full cup” comes into play when an experienced person is not inclusive of further experience and knowledge. There is the expression about teaching an old dog new tricks. It is necessary, in order to learn, to actually want to learn.

I can see myself applying the principles in these chapters more so toward my mathematical education than my software development education, only because I am more aware of what I do not know in regards to mathematics. I expect that the focus should shift more specifically toward software development in later chapters; knowledge of careers and how software development works on the level of employment is much less familiar to me than the computer science component of software development, although there is still much more to learn in computer science alone.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.