Hello!

For the final pattern blog of the semester, I decided to close off with the “A Different Road” pattern from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. 

This pattern is related to following your own map but straying from the Long Road in the process. As you spend time following the Long Road, you may come to see that your values have changed. For example, you may value family or money more than before. Your goals may not align anymore and this may cause you to leave the Long Road. However, what you have learned along the way isn’t rendered completely useless–they can be applied in other ways to whatever you choose to do. 

You may realize after leaving the Long Road that you would like to go back. There may be some organizations that would give you a tough time for that gap in your resume, but there are some organizations that aren’t as bothered by that and may welcome your perspective of leaving and returning to the field. The pattern encourages you to not be afraid to go for something different, and either way, your skills can be utilized in a different way. You can take action by making a list of what you would do if you were not a software developer, and what you may enjoy– and reach out to people who are doing those jobs to learn what their experience is like, and compare it to what you like about software development.

I think this was a useful pattern to read. It is recognizing that some people change, and they may shift what their focus is on. I think it’s reassuring to see that it acknowledges the industry may be tough on people who have gaps in their resume but that wouldn’t be a complete set-back. It wouldn’t be the end if we can’t exactly make it back to the kind of position we were in before, but some important skills we gained along the way can be transferred to something new. There’s more flexibility than we think, and I think that I would definitely have this in mind going forward. Sometimes it feels like I may be reaching a dead end if I don’t meet certain deadlines, but of course, we all have different timelines and paths. I don’t have anything I disagree with for this pattern as I agree that diverging doesn’t mean the end of everything or means that everything would be wasted.

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.

Hello!

Welcome back to the blog. This week I am discussing the Craft Over Art pattern from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye.

The context of this pattern is that you are being paid to make something to solve a problem for a customer. The problem is that there is already a solution for how to fix that problem, but you would be able to come up with something creative to address the problem that would impress your coworkers. 

The pattern discusses that being a craftsman is impacted by relationships we build with others–we should work to build strong connections with customers, making sure we deliver to them something of quality. We shouldn’t aim to focus on our own interests. You should be working to the best of your ability but also keeping the customer’s best interests in mind. Part of our growth is being able to give up the opportunity to make something beautiful and instead create something useful when needed.

The pattern advises that in the next 24 hours you work on something to be useful rather than beautiful, and to think about what you should be focusing on while you make the decision on making something useful. You should also reflect on your past experiences where you tried to do something creative rather than follow an already-made path for solving a problem and the result of it, and what would have happened if you chose to use a previously established solution.

I thought that this pattern was an interesting read. Throughout the patterns, I’ve been seeing that we should work to hone our skills and not get too comfortable with certain activities–try to branch out some more or we may get stuck. And this pattern is saying that although we should exercise our skills, we need to find a balance between creating something ingenious and creating something based on an already existing solution. I think this is important to think about when doing work. Of course, I think it would be great if you could figure out new ways to do things. But it’s also important to deliver products to the customer in a timely manner, and it may be too resource consuming to create something from scratch as the pattern mentions. I don’t have any disagreements with this pattern. It would be great to develop the ability to know when to sacrifice utility vs beauty and it would definitely be on my mind when I need to solve a problem in the future. I usually tend to look for any known solutions and make slight adjustments to the solutions when necessary.

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.

Hello!

Welcome back to the blog. Today I’m discussing The Long Road pattern from the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye.

The context of this pattern is that our culture values quick rises to fame and holds material values.

The problem relating to this pattern is that we have a main goal for what we want to become–for example, a master software craftsman–but there are other people and outside factors that expect differently from you. You may be offered a great promotion and are urged by others to go for that rising opportunity, even though it would derail you from your “end goal”.

The pattern brings up as a solution to recognize that it might not seem like you would match with your end goal, and to also keep looking forward to your end goal. You should prioritize learning opportunities and any other growth opportunities that would help in the long-run rather than taking the higher-salary position or a leading position. For people hoping to hone their skills for something specific, they should be prepared for it to be a lengthy process.

For action, the pattern discusses thinking about your future–what role you may have a decade from now, and what experiences you want to have under your belt decades from now. Imagine you have to write about your professional history four decades from now, what would you want to see? Use that to plan out your career path. 

I think this was an interesting pattern to read about. This is meant for someone really dedicated to having a specific range of skill sets rather than someone aiming to quickly get promoted and become managers or someone higher up. I was thinking about what I would do–do I have a specific thing I want to become, like a master software craftsman? Not really. But it was interesting for this pattern to get me thinking. I do agree that if I wanted to become a master software craftsman, it would be important to not take on a role that is unrelated to using skills relevant to programming or being hands-on with software utilization. It could make you stray away from your path too much and could take away major opportunities for your growth for your career goal. If I end up having something in mind that I really want to become, this pattern will surely be on my mind–to make sure I stay on a path that will help me hone my skills and gain experience necessary for my career plans. I don’t disagree with the pattern since it’s meant for a specific end goal in mind.

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.

Hello!

This week, I read about the Sustainable Motivations apprenticeship pattern from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye.

The context of the pattern is that while we’re still starting out as an apprentice, we have to explore many different things to expand our skillset. Because of this, we come across a rocky path of handling new projects with tough demands to address and things we are unsure of how to approach. Even though you have some love for your job, this exploration gives you troubles and you find yourself feeling pressured, stressed, and even doubtful of your career path.

The pattern also brings up an example of some people being trapped, wanting to move on to something else, but being held back by their motivation of money–they want to switch careers but their current job pays well. It spotlights the importance of matching up your motivations to those that will help you in the long run– to reach mastery.

The action you can make for Sustainable Motivations is to concoct a list of things that motivate you. You should then leave some time to write some additional motivations later on. You should also take the time to reflect on the motivations that you yourself really want versus what other people think. Analysis of the motivations should be done to figure out how much of these are truly what you want and which are the five most important motivators of your life. The list can be referred back to when you find yourself struggling again. 

I think that this was an interesting pattern. I do find myself doubting where I’m heading at times, especially when I face some difficult new tasks and need to branch out to something completely new to me. I like that this pattern brings up that we do find ourselves loving/feeling passionate about our job/what we’re working on, but there’s also a mix of that and being unsure of what we’re doing anymore. I find that more relatable because there’s times where I find myself loving how everything gets put together in the end, and working on certain tasks, but sometimes the process feels really discouraging. From now on, I think I’ll make a list of motivations to keep me going and know that I shouldn’t let my motivations keep me from growing as well. I think more self-analysis wouldn’t hurt. I don’t disagree with anything in the pattern. It’s a good reminder to prioritize your values and where you want to go.

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.

For this week, I wanted to read over and discuss the Deep End pattern from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye. 

The Deep End pattern can apply when you’ve only taken safe steps or have only worked with what you’re comfortable with, and you’re starting to feel that where you’re at is hurting you. You feel that you need to expand your knowledge and what you can work with. So, this means that you have to start working on more complex projects or tasks, maybe more high-stakes projects. You shouldn’t jump blindly into a complex project, but you should first prepare or gauge what you’d be able to do. If you take on something unprepared, it could just have a negative impact on you. The pattern gives a warning to make sure you don’t take on something that you may have no foothold in at first–with an example of Enrique Riepenhausen moving out of the country to act as a consultant for a client in Nigeria, but knows the language and someone who lives there.

To work on this issue, the pattern says to think of the projects you have worked on. Then, write about the scope of the project–complexity, how many lines of code, how many developers, etc. From these answers, you can give projects a rating or make a general scale of their complexity and compare new projects to the scale and use it as a tool to help you reach your career goals.

I thought that the pattern was useful in the way that it says you should measure/compare complexity of your past projects that you can use to then compare to future project opportunities. It would be a good way to see that it is complex enough to boost your skills instead of being something on the lower end of complexity that wouldn’t launch you forward. I do agree that we should take on something more difficult so we can learn more things–for example, I knew how to do little tasks for my internship, but I hadn’t written code for a report before and worked on a template nor a form–basically a bunch of aspects I had not touched before–and had the task of working on them. And I’m glad I did, because I learned so much from that complex project that I can now apply to so many more. I also did not step into it completely blind, because I had coworkers who could help me if I really needed, and a knowledge database available. I think it would be interesting to think about my portfolio this way moving on. I do not have any disagreements with the 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.

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.

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.