The final pattern I will be writing about from Apprenticeship Patterns is “Retreat into Competence”.
The “Retreat into Competence” pattern describes how to solve the problem of when you begin having issues as you start working outside of areas you are comfortable in.
I like the ambiguity of the opening quote by Robert Pirsig, I find that it is comforting while being vague at the same time. I agree with the quote about not knowing where I currently am but what I’ve done so far seems to make sense to me. I like the idea and I think I need to think more about what I’ve done so far as a computer science student to find what my “pattern” is so I can use the advice Pirsig seems to suggest and apply my own “pattern” going forward.
The topic that the pattern covers is something that makes me think about what I’ve learned as a computer science student as I am reaching the conclusion of my work for the major. In particular, it makes me think back to a conversation I had with Dr. Wurst and especially when he mentioned the fears of not knowing enough as I approach graduation.
I particularly connect to the idea that the pattern mentions of a deadline problem. The deadline problem was something that I thought would happen on Monday with my work on the UpdateGuest project and I wasn’t completely sure if our group (and I) would be able to finish our project before our review meeting. Additionally, I was having a hard time figuring out how Angular worked towards the end as I was trying to finish the issues I needed to for the project to be done. I got past the problem though with the help of my teammates and one awesome article my teammate found which helped us to get our Angular form implementation working.
I think the advice offered in the pattern is important and I agree that it is good to occasionally remind yourself of what you’ve learned and what you can already do, especially when you can’t solve a problem you are working on.
I found the “Retreat into Competence” pattern to be a fitting final pattern to write about as I finish up my work in the software development capstone course and as a computer science student. I am making it a goal to finish the rest of the patterns in the Apprenticeship Patterns book over the summer as I have found the advice to be helpful and I am curious about the remaining patterns as they are frequently mentioned in the current and previous patterns I have read.
Today’s first pattern in Apprenticeship Patterns is “The Deep End”.
“The Deep End” pattern describes how to avoid getting stuck at the same level of being a developer and how to take risks to improve yourself.
As far as the “Context” area of the pattern goes, luckily, I don’t think I’m in a “rut” right now. Currently I’m still learning about lots of new things and tools at the same time and although I would like to make more progress, I think I’m still moving forward.
The “Problem” section makes more sense to me than the “Context” area and I agree, and I would still like to improve my knowledge and keep on learning about the tools I am currently working with. I agree with wanting to have additional projects I have worked on for when I apply for a job and I would like to have these shown on my GitLab account.
I think the part of the “Solution” for the pattern that describes “Waiting until you’re ready” is one of the most relatable parts of any of the patterns so far. I agree with that statement and I feel like I should just start learning new tools or adding work to a project instead of continuously waiting until I really feel like doing it. I feel that I should schedule regular times for learning or working on implementations to help avoid the problem of not feeling ready.
The example provided with Enrique’s email is especially impressive. I don’t think I’m quite ready to do something like Enrique did, however I do think that the email illustrates the success that following the pattern can get you and that there was a lot of value in including it.
Answering the “Action” questions I think the largest project I’ve worked on as far as team size goes is with my current work on the UpdateGuest project. As far as size goes, I think my own personal project might have the most amount of code (although the size may be tied close with UpdateGuest). I think the idea of different project “metrics” is interesting and I think some other useful ones could be total time spent working on a project and how automated the project is as far as CI/CD goes.
I think that the pattern offers valuable advice, especially with avoiding a “rut” and I would especially like to think of more and keep track of the different project “metrics” as I continue to work on old and new projects.
The second Apprenticeship Patterns pattern I looked at today is “Confront Your Ignorance”.
This pattern explains how to improve your knowledge in areas you aren’t as experienced in. The pattern also provides possible drawbacks of focusing too much on self-improvement.
The “Context” and the “Problem” sections of this pattern are relatable to me currently. I can clearly see that I have a problem with my knowledge of Angular and I need to learn more about this in order to develop frontend applications. I do somewhat disagree with the part of the problem area that says I “do not know how to begin”. I think at this point I have a decent idea of how to learn about new tools. Although maybe it is correct as I have still yet to feel like I have a good understanding of Angular after trying to learn more about it.
I do like and use both of the suggested methods for learning about new tools. Usually I like to read documentation and introduction guides on a tool’s website, but I also like to follow along with example projects. Additionally, I have found that watching a video tutorial series (mainly on YouTube) on a particular topic can help a lot with learning about something new. This is how I learned about a lot of the backend tools my team used this semester and I am especially a fan of the YouTube channel one of my teammates found. This suggestion is something that I feel should be included in this pattern as I have found this method to be one of the most valuable ways of learning about new tools, especially if there isn’t much documentation for it.
If I had to pick only one thing to learn more about it would be Angular. This is something I have consistently been trying to learn about for a while, ever since I first learned about it, and it has been something I’ve tried to improve on this semester but I am still not satisfied with my knowledge with this tool.
I did find the provided downsides to be the more intriguing part of this pattern as these are points I wouldn’t have thought to be in a pattern about how to learn new skills, but they do make sense after reading about them.
I do think that this pattern provides some good general information about learning about new topics, but for me I wish it was a bit more specific as I find that I was familiar with most of the information provided in this pattern about learning about new tools.
This morning’s pattern in Apprenticeship Patterns is “Expose Your Ignorance”.
This pattern helps explain to early developers how to get over their initial lack of knowledge in the field by asking questions and seeking out knowledge and the importance of doing this instead of pretending to know everything.
To me this pattern and especially the “Problem” area feels very relatable right now with where I am this semester, especially with another attempt at learning how Angular works.
I do find that this pattern provides me with some valuable reassurance, and it is more comforting to know that this problem happens to other people.
Lately with my work this semester I have apparently been following the advice this pattern gives and trying to ask others in my group for help when I don’t understand something that I have been trying to do. This is important in our group, especially as different team members in our group have their own areas of knowledge from what they’ve learned this semester. Reflecting back on this more I wish that I asked more questions (especially during meetings) and focused more about how something works instead of just the solution as this would have had a far greater benefit in increasing my knowledge.
I agree with the idea that answering questions helps to understand the problem better. I can think of many times this semester where I either asked questions that helped find errors in something or when answering someone else’s question made me think more about it.
I do like the idea that the “Action” section presents, although it does feel somewhat exposing to visibly have on display things I don’t know. I am trying to think of a good digital place to put something like this, perhaps on my GitLab account. As I’ve probably alluded to in my posts so far, I think my top items (although this isn’t five items as the pattern suggest, these are things that are particularly holding me back) with my current work would currently be: Angular (and specifically forms), HTML, and Jasmine (this is especially a rather new one for me). I would like to refine this list some more and pick more specific topics to work on learning in each one of these broader items.
This pattern provides helpful knowledge and helps explain the importance of learning from others. Again, as I said before in my previous post, I wish I read this pattern earlier as the ideas presented in this pattern would have improved my learning this semester.
Today’s chapter in Apprenticeship Patterns is “Concrete Skills”.
This pattern provides an overview to the idea of more specific skills developers should have as they start their careers.
I think that this pattern serves as a good introduction to this topic. This pattern seems especially relevant to where I am now as I will soon be looking for employment after graduation and this is a good general reminder of things that software development managers are looking for.
Although I think this pattern provides helpful information, I do wish that this pattern was more specific and detailed. I believe this pattern could benefit from expanding upon the information it offers. I also think that it would benefit from including an example CV showing how these skills are listed and defined on a real document. After reading this “action” section, I am now curious as to what the most important skills are for a starting position in the DevOps field and if I already know any of these skills. Again, I think this section could benefit from suggestions as to where to go to look for these besides people you may know.
Altogether I did find this pattern helpful and a useful reminder of what the most important parts of a resume are for a software developer. This is true especially as I move on to creating and refining my own resume in preparation for getting my first job in the software development field.
This evening I continue my reading of Apprenticeship Patterns with the third pattern titled “Unleash Your Enthusiasm”.
This relatively short pattern describes the benefits and possible disadvantages, along with how to handle the “enthusiasm” of being a new developer.
I both agree and disagree with both of the areas of this pattern that describe the “context” and the “problem”. In my current situation and from my memory of the time I have spent in the software development courses so far, I have found that the professors I have worked with and learned from can have more “enthusiasm” than I do. I think that this is one of my favorite parts about taking this track of computer science was getting to learn from people who enjoy the work and learning as much or more than I do. I think this was specifically the case last summer with my work on the LFP community which really helped to motivate me to contribute to it and kept me going. At the same time, I also agree with the idea this pattern presents that a rather unenthusiastic group can bring down the mood of someone excited about being new to the field.
I do understand the rather unfortunate idea of only being excited about projects outside of regular work. I personally find this to be true and that although I usually enjoy working on my project, it is not just because of the topic or the self-interest, but also because of the freedom allowed in the workflow when you work on your own project. I think this point about a group’s attitude while working is something I want to keep in mind when I begin looking for a job as a software developer, as I would prefer to have a job where everyone enjoys the work they do and encourages this passion in each other.
Overall the quality this pattern describes seems like one of the best perks of being new to this field. I do worry that for me this quality will diminish over time and I hope that I haven’t lost it already before I’ve even started. I think that this pattern does a good job of pointing out this quality of a beginner’s enthusiasm and that it is something I want to work towards keeping now that I am more aware of it.
Tonight I am continuing with my reading of the Apprenticeship Patterns with toady’s pattern being “The White Belt”.
This pattern helps to explain how to get over the obstacle of learning and implementing new information after mastering “your first language”.
This pattern feels applicable to me as I feel this is the stage I have reached with the first language I learned. I particularly connect with the problem area that describes a difficulty with learning new tools as this is something I feel I am beginning to run into (especially with Angular) while learning new tools for my work on the UpdateGuest project.
I do think that I try to take the approach mentioned in this pattern of forgetting what I know when learning new tools, but I think that now I am more consciously aware of the value of this I think it may further help with how I learn.
I also agree with the point this pattern makes about being afraid of looking bad when trying something new. I recognize that this has held me back in some of my work this semester as I did not want to commit code that I was unsure of. With the help of this pattern, I realize that I need to get over this fear and not let it hold me back.
One of my favorite parts of this pattern is the example code. I appreciate how the beginning of this is in Java, as this makes it easy for me to understand and it makes the comparison more meaningful. The real beauty of the example is how the multi-line Java snippet is condensed into one small line in the J implementation. This vastly condensed (and somewhat strange to me) implementation really helps me to appreciate and understand the point this pattern makes of needing different approaches when using new tools that are unfamiliar from what you already know. This example makes me want to take up this challenge of learning something that is new and completely the opposite from what I already know.
For me, I read this pattern at a great time, and I even wish I had read it earlier this semester as it could have helped me with my work developing for LibreFoodPantry. I am going to make a point of keeping this pattern (and the cleverly quoted advice from Yoda in The Empire Strikes Back) in mind as I continue to learn about new tools this semester.
This evening I began my reading of the patterns in Apprenticeship Patterns, starting with the first pattern “Your First Language”.
This pattern provides guidance in selecting the first programming language you will learn as more of a beginner and the importance of this first language. The pattern also explains how to move on from this first language to learning others.
I liked this pattern as it let me reflect about my overall usage of Java, the first language I truly learned as a computer science major. Reading this pattern has made me question my usage of this language and particularly if I over-rely on it. I am also wondering if this is the best language to continue using or if I should switch to another language as my primary programming language.
I agree with the advice given of picking a real project for helping to learn a language. This is what I would like to do more of with my side project, and I would like to use this project more for learning new tools and languages.
I liked the idea of using tests as a way to verify your comprehension of a language, instead of just testing the code. I particularly like how this idea is a different approach to thinking about testing and its usage and how to use testing when starting out with a new language. This point is definitely something I want to keep in mind when I learn new languages.
Additionally, I liked the idea of picking languages according to the knowledge the people you know have. With my experience, I agree with this sentiment and I think there is a lot of value in having someone you can go to that can help you get back on track with coding problems. At the same time though I do somewhat disagree with this idea and I think that someone should decide on which language to learn based more on the availability and quality of the resources available for learning a tool or language. The reason for this is that I would prefer to have a reliance on resources rather than having to rely on someone else.
I further agree with the notion of getting “stuck” in the first language you learn. This is something that I am afraid of doing, especially with the longer I use Java as my primary language.
This pattern has helped me to reflect on my current knowledge and usage of programming languages. It has increased my wanting to learn a new language and I will keep it in mind as I switch to learning and using new languages.