In the chapter Emptying the Cup, I chose to write about the apprentice pattern Your First Language. This pattern discusses picking your first language and what practices to develop to enhance your understanding of it. This pattern stood out to me this week because I relate to the fact that I only really know one language, Java. I have dabbled in other languages like Python and Vue for other classes, but a majority of my college education was in Java. I have had worries looking at job applications where the employer requests that the individual that applies has knowledge of different languages such as C++. The section explains however that if an application calls for experience in a different language, then to create something in that language and learn, and build something that you can show off to employers.

The article explains that different languages have tools that can help individuals learn that specific language, such as Ruby having an interactive command-line tool irb. The pattern ensures that there are tools and help available for individuals in case they need a little extra push in learning a new language.

Another important point that the pattern points out is to ask an experienced individual in your life for help when struggling with a new language, but not to become completely dependent on that individual. Working through struggles on your own will ensure that you learn more throughout to process. I have had experiences like that through my education, where I have been stuck on an issue and I needed to lean on my professor to help out. Instead of just giving me the answer however, the professor would ask questions that would help guide me towards the solution. This is an effective mentorship trait.

This pattern really helped comfort me with the worries I had regarding job searching when I graduate. I want to be able to perform at my new job and become a helpful member of the team, and the worries of not being proficient in a certain language holding me back was hindering my confidence to achieve that. But the article reassured me that if a job asks for proficiency in a certain language, it’s just an excuse to mess around and learn in a new environment and adapt.

From the blog CS@Worcester – Noelan Chabot's Blog by nchabot1 and used with permission of the author. All other rights reserved by the author.

Greetings!

This week, I wanted to kick off with the pattern “Retreat Into Competence” from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye. 

Retreat Into Competence relates to scenarios when you realize how little you know or you’re facing a challenge that’s making you reflect back on your knowledge, and you feel overwhelmed. The solution to this is to give yourself a moment–or a little longer, and step back from the challenge you’re facing. Then, take some time to work on something you’re familiar with or know that you’re capable of doing. 

The pattern touches upon how you may feel the thrill of learning new technology along the way of your journey, and the satisfaction of delivering things to customers. And then, you meet more experienced people along the way who make you feel that you really know nothing, and you can also feel this way when there are fast-approaching deadlines and product issues. And sometimes, to deal with this, you need to go backwards to move forward again.

The book warns to not retreat too far back into what you’re comfortable with if you’re afraid of failure, because what you’re comfortable with may no longer be used in the future and the extent of what you know is very limited and you may need to face the consequences of that. Therefore, the book says to use this pattern only as a little pick-me-up, and not to use it for too long because it can be a double edged sword. For action, it’s suggested to pick up something you are well acquainted with and work with it once again. 

I find it interesting that I have utilized this pattern with my internship. When given a new task to code for something in a report, I often change the report template and form corresponding to that report. My biggest challenges come from changing the code in the report, so I sometimes find myself taking a break from that and moving to the template or changing the report form–tasks I find more simple that I have a better grasp on. I agree with the book that it is a short-term fix and should eventually move forward. I’ve recently realized how much I’ve learned from my internship when I took a step back to work on the form and template. It had been something that I had no idea how to handle not too long ago, and now it’s something I’m most comfortable changing. And that’s what made me feel so accomplished and happier to move onto the report code, knowing that I’ll eventually be able to consider the report code something not too difficult to handle. There wasn’t anything I disagreed with.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Learning a language is really difficult, not only is it really hard to get started with one but once you have a good understanding of the syntax then learning certain methods of how that language can be used can be quite time consuming to learn. The problem I tend to have is that it can be difficult for me to implement a specific method in my work. For example I could go in and look at an example of a design pattern like the factory method, and I could know how it works and what it does, but I would have a hard time trying to implement it in my work.

Now, one of the first patterns that is introduced in Apprentice Patterns puts the reader in the context that they are starting out as a programmer and that they have a shallow understanding of the languages they know. The problems that we are introduced to are that since we have such an unlettered understanding of the language, it is difficult for us to create quality programs and solve problems. The solutions to this is that we must pick a language and take the time to become fluent in the language. The drive of wanting to learn and solve solutions for that language should be enough to guide the learning process.

While reading about this pattern, It was safe to say that this wasn’t the first time I’ve been exposed to this information of how to become fluent in a language. What really captivated me was how the author made a good point in learning the fundamentals and not just syntax, I feel that at this point in programming journey I could string a couple lines of code together because I’m to familiar with the syntax of my language, but the potential that I can create in that language is close to none. I wouldn’t know the first thing to do to start a project. The author put an emphasis on learning fundamentals, learning how to solve solutions with the chosen language, and how to use testing to your advantage. It’s important to open every and any feasible avenue when working to understand the language. As the author mentions, it must click. There is a difference between learning how to write a piece of code and absolutely knowing every purpose of that code. My goal is to find someone that knows more about the language I’m trying to become fluent in and to learn as much as I can from them, almost like a master. It’s a lot easier for me to acquire someone else’s wisdom rather than figuring it out on my own.

Sources:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Hello! 

For the grand start of my discussion of apprenticeship patterns from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, I wanted to begin with the pattern Expose Your Ignorance.

Expose Your Ignorance is related to the notion that managers and team members expect you to know what you’re doing. For your position, you may know most of what is expected for your role and overall what you need to be doing. However, there are some components that you are bound to not be as familiar with, or have no experience with, like some new technology. The solution to this is that you should reassure them that you’re learning how to deliver to them what they want, and not to pretend that you know how to do it. You would be able to form a reputation of having a great learning ability rather than playing on with fake expectations of what you know.

One way to expose your ignorance is to ask questions. It may be difficult to do so at first, but eventually communicating with team members who are very knowledgeable about the topic won’t be such a tribulation. This would be helpful to give your team members a scope of what you can do and learn, and could also help them understand more about the topic as they explain things to you. The book suggests keeping a list of things you don’t understand related to your work in a place others can see.

I appreciate that this pattern addresses my concerns as someone new and heading into the workforce. I often feel pressure that there are some things that I probably should know how to do, or that I need to do something but it involves something I have not heard of before. But as discussed with the pattern, I do know a good chunk of what I need to be doing, and what I don’t know are just some gaps between them, so I don’t need to feel so pressured. This reminds me that team members I work with have been using this technology and certain methods for a while now, and I just haven’t learned them yet, so I am not too behind. 

 I’m very open to learning and I can reassure them that I’m studying and practicing what I’m learning from them and other sources. I also shouldn’t be afraid to ask questions, because asking someone for help can help put me on track faster to having a better foothold on the technique/technology I’m working on. Of course, I still try to solve things on my own for as much as I can so I won’t have to repeatedly ask for help, but I keep in mind time constraints. I definitely agree that I shouldn’t just specialize in one thing, but aim to branch out and learn more to have a better foothold in different components of technology. I don’t think I have anything I disagree with for this pattern.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.