Hi everybody and welcome to another blog post for CS 448 Individual Apprenticeship Patterns. Today topic is going to be about one of the patterns in Individual apprenticeship patterns which is your first language. I learned a lot from this pattern like obtaining my first job will depend on my proficiency in a specific programming language. I started after reading this pattern to focus on one specific programming language which is swift. I chose this language because I been reading other articles and pattern that say to work on something, I going to be passionate about which is creating a fun application. The pattern advised me to become fluent in it, so I been coding problems and reading more about the language daily. I also feel more comfortable after reading this pattern when asking for help. I have always been too embarrassed in the past to ask for help because I felt like I should know how to solve the problem but now I will try to be more open with some of my programming errors but only if I desperately need it. The pattern talks about playing around in an environment with topics that I’m unfamiliar with which I totally agree with. XCode has an IDE call playground where I been just messing around with unfamiliar features and language. I have also been reading more about a testing framework after reading this pattern. I found this pattern helpful because I realize that there are many ways, I can improve in my programming skills. I learned that my first language is very important as a beginner programmer because the first language is going to be my building block for my career and foundation for future language that I will soon be learning. I think after reading this pattern your first language I really change the way I work and code. I have been more motivated to get a strong understand of the language I decided to invest in the most. I found this pattern interesting and I never knew the importance of the first language before because I been using every language and wasn’t focusing on a specific language which causes me to be decent in all of them instead of being proficient in one. All in all, this pattern was very inspiring.
For the second week of reading, I chose to read the pattern, A Different Road. This is a continuation off of Draw Your Own Map and discusses an issue. The issue is when you have followed your own path as a software developer and hit a road block. This road block is not about whether or not you could become better and rather that of a change in interest. It details the possible outcome of leaving the industry to pursue another interest and what could happen upon returning. There is a chance that the gap from working in different industries could work against you in the end. It is said that some organizations will deem the inactivity from the field as suspicious and will question your return. The risk is big, but it is still important to follow your road map where ever it leads.
What I found useful about this pattern is that it encourages others to follow their hearts or road map that led them up to the decision where they might be leaving the profession. Everyone only has one life, and usually the saying is to do what makes yourself happy. Sometimes, people need a change of pace and it’s important to recognize that. However, I am not surprised that some organizations will question your absence from the profession if you chose to leave for a while. I’m sure many of us who chose to study computer science has realized the type of field we are going to throw ourselves into. Another interesting part of this pattern is about the work experience between two different jobs can sometimes be used effectively. Depending on the context of course, one experience in a separate field may be used to fix or provide a solution to a problem in a different field. This also goes back to the organizations who might disregard any experiences that an individual has that isn’t related to the experience needed to fill the desired position. I feel that the only choice after leaving the long road for a while is to work twice as hard to get back in. Lastly, I do believe there are probably plenty of ways to accomplish that and it’s not a lost cause overall.
From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.
As I mentioned in my last blog post, I have a bad case of impostor syndrome and oftentimes get discouraged when comparing myself and my work to more experienced developers. This week’s apprenticeship pattern helped me understand that being farther behind on a stronger development team with intent to catch up (a small fish in a big pond) can be more beneficial than being more of an outgrown member of a team that doesn’t challenge me as much (a big fish in a small pond).
“Be the Worst” describes the problem of plateauing in new knowledge, as the apprentice continues to work in a team that doesn’t push them to challenge themselves. As a result, the apprentice may start to grow out of the team. The solution is simply for the apprentice to look for opportunities in stronger teams. By establishing themselves in such a group, the apprentice should be more motivated to work harder to catch up to the level of their teammates. While this poses a risk of potentially falling even farther behind, it has the immense reward of learning more, at a faster rate.
This section definitely reassured me that even if I am farther behind than my team members, it just means that I have more room to improve, as long as my teammates are supportive of my growth, in spite of me not being as strong of a team member (yet). I’m sure that initially, I will have difficulty removing the feelings of intimidation of working in a more challenging group. One of the additional risks of joining this kind of group is the possibility of feeling incapable or under-performing. However, as the section explains, I would be able to recognize how much I have truly advanced in skill when self-assessing.
This section also changed my thinking regarding comparing myself to other developers. With my current mindset of impostor syndrome, it may not be best for me to compare to those who are more experienced than me. But, as my attitude towards my own skill improves, it’s not a bad thing to look up to those people as an example of what I can also achieve. By seeking out more challenging opportunities, this comparison to other developers is also necessary.
Thanks for reading!
The apprenticeship pattern “Your First Language” is a pattern that specifically focuses on people who are just starting out and only have a shallow understanding of one of two programming languages. For people in this situation who don’t feel like they have very in-depth knowledge in any particular language, the solution is simply to pick a language and become fluent in it. However, what language should you choose?
I think that this pattern pretty interesting and still somewhat relevant even to people who are comfortable in a specific language. For me, even though I feel that I’m pretty comfortable with writing in Java, I can say without a doubt that I’m still very inexperienced and will run into problems that I’ve never encountered before. According the the pattern, one of the most fundamental ways of improving your experience with a language is the solve an actual problem with it. Being able to encounter roadblocks naturally and discovering a solution to it is something that you won’t be able to effectively recreate through learning from small, self-contained examples in learning resources.
One thing that stood out to me in this pattern was what was considered the most important factor in choosing your first language. It states that you should choose a language that someone around you is an expert in. By having someone with that expertise within reach, you are able to learn at a much faster rate than if you were trying to learn it by yourself. Preferably, you would be able to work on a project with them using the language regularly, but as long as you can get feedback from them, it will still be immensely helpful. While I think that this should definitely be the major factor in your decision, I’m sure many people may not know an expert of a language that they would feel comfortable enough working with or seeking feedback from. For those people, it’s important to seek out those opportunities and expand your network, but I suppose that’s easier said than done.
Overall, I feel that for those in that situation, this pattern is something that should definitely be followed if you want to learn as quickly and effectively as you can.
Learning is something that you should never stop doing. The more you know the more you will feel the independence in you workplace. As you go through the college you learn e lot, but nothing compared to what your career needs. It is instinctive to show more than you know when you stand in front … Continue reading Confront Your Ignorance
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?
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.
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.
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.
When I look for patterns to read and write about in Apprenticeship Patterns, my interest is first directed at the context and problem sections of the text. Naturally, I’m drawn to patterns which most directly apply to my position right now. In this pattern, concrete skills, the context and problem could not be more true.
I am in a position where I begin my apprenticeship in a scrum team full of skilled programmers. I will be the intern and as such will have the least knowledge or experience out of anyone in the group. This pattern offers actions and solutions I can take so that I won’t need as much as what the authors put it “day care”.
I appreciate the simple wisdom of the advice the authors give. If I am worried about not being able to meaningfully contribute, learn a few concrete skills that will help me take on a few responsibilities, easing the burden on the team to train me.
A few actions I should take to achieve this goal are to make demonstrative applications using the concrete skills needed, as well as looking at similar code from other people and trying to figure out their logic and methods to solving the problem.
In my case, reading this pattern helped me decide a concrete skill that will help me be more of an asset to my future team. I know that we will be working with Spring, so I will try to learn about making components with spring and creating a simple program or two, so that on my first day I am already equipped with some kind of knowledge that will get my foot in the door and make me useful.
From my limited experience reading this book so far, I have already started to change the way I view how to take the first steps of my career. Up until this point I felt as though the wider your experience the better, but the examples the authors use really illustrate how much more value I can get by focusing on a few things, and taking small steps to build concrete skills which will be a bigger benefit for me and my future team.