Category Archives: Week-14

Apprenticeship Patterns: Sustainable Motivations

The ‘sustainable motivations’ apprenticeship pattern discusses the realities of beginning a career in software engineering. In the process of developing your skills, you may be stuck working on projects with obscure specifications and fickle clients. This work can be, as Hoover and Oshineye describe, “rigorous, sometimes tedious, sometimes exhausting, often frustrating, and frequently overly chaotic or constraining,” and it may start to wane on your motivations. The trick is to not become wrapped up in your motivations; you should recognize that some days will be harder than others. You should not be driven by a single desire; if you are motivated only by money or a desire to build your reputation, you might burn out and lose that motivation. Your motivation should also come from wanting to master your craft

I thought that this apprenticeship pattern was really interesting. I think it highlights how easy it can be to become disheartened with your work, especially if you are not properly motivated. It can be devastating to invest time and money into a career you wind up losing interest in, and it is helpful to see advice on avoiding this.

I like the suggestion to have multiple motivations for working; obviously, if more factors are motivating you, you are less likely to lose interest in your work. The suggestion to, in addition to your other motivations, be motivated by mastery to avoid stagnating your skillset seems very useful. I also like the advice in this apprenticeship pattern to maintain a good balance between your work and your life. I think a healthy work-life balance is so important; your work should not demand so much of you that you are unable to enjoy other parts of your life.

I don’t agree with the first example discussed in the ‘solution’ section of this apprenticeship pattern. The person in this example hates the programming that their job requires, but they like the money and the reputation. The solution to this example is that they endure the job until it improves. I think this solution sounds absolutely miserable. I realize this is not as realistic a suggestion as it should be, but you should probably switch professions if you hate performing the main task your profession requires.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

Familiar Tools- blog 9

This week, I read a pattern called Familiar Tools. This pattern happens when you feel hesitant to let go of some familiar tools that will soon become obsolete at some point. Through this pattern, I can understand that everything has two sides, even familiar tools are not an exception. As the author said, familiar tools can help you solve problems quickly, easily beat another candidate in an interview or increase your productivity at work. However, if you stick to what you already know and ignore the changing of the world, your career will be in jeopardy. That is because over time, many new tools will emerge and some existing tools will become obsolete and lose their effectiveness. If you cannot throw away a part of your toolbox to discover something new and update your toolbox regularly, then it is like you are wielding a sword to battle in a world where everyone uses guns. There is no way for your existence in that world. Therefore, to solve this problem, besides constantly looking for new tools to update your toolbox, you need to face the challenge of giving up some familiar tools that will soon become obsolete to reclaim space for other new tools .

In my opinion, this pattern is really not difficult to implement. In other words, as an apprentice, I understand that it takes a lot of time to learn and get used to a tool, so letting go of what you are already an expert on can be described as feeling loss. However, I wonder what if I keep a tool that I will no longer need or use in the future? Or what if I use a tool I am familiar with, but it does not help me; on the contrary, all it does is make me feel like every problem is suddenly getting harder and I cannot solve any of them? For myself, those familiar tools have now become obstacles in my long career path. So, I never hesitate to replace outdated tools from my toolbox with new ones. In my opinion, throwing away my familiar tools, it may not be something I can choose, it is something that I have to do to advance my career.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

The Long Road

The pattern I’m going to look at today goes like this: Our culture is fixated on success to the detriment of true understanding of the work behind it. Consequently, there is pressure to abandon the craft at the first opportunity in favor of chasing success. The authors argue that you should push past that pressure, with the understanding that if you keep at it there’s no one you can’t eventually surpass.

I think the initial point about how our culture values fast, seemingly effortless results is insightful. In my experience, this is a pretty significant hurdle to get over to get good at anything. It can be difficult not to compare yourself to an imagined prodigy out there.

Broadly, I think it’s good to set your own goals, rather than chase illusory culturally-defined ones. I already have my own goals in mind that aren’t exactly things everyone wants, although I have a slightly different outlook than the authors here.

I think the authors, although probably not intentionally, frame things that everyone should expect from full time employment as either incidental and unworthy of consideration, in the case of money, or even a form of failure, in the case of retirement. If it were up to me, I would be content to do any type of work, with honing my software skills as a passion project. I unfortunately need money to live though, and the easiest path towards it is to leverage my interest in technology. The authors seem to view the need to make a living as incidental and irrelevant, but I don’t really think it’s harmful to your skills to not dedicate your whole life and career to honing them.

The authors also have a kind of competitive edge to their idea of personal development, suggesting that through devotion to honing one’s craft it becomes “realistic rather than vain to think about surpassing people like Donald Knuth or Linus Torvalds.” First of all, I don’t think realism and vanity are mutually exclusive. And furthermore, I don’t think this is really a healthy attitude to have. Why should you care about your skill relative to other people? How would you even be able to tell that you’re better than someone? Speaking from personal experience, I think the need to be better than other people has the potential to be really harmful to your own development. At least, it was for me. To “surpass” someone isn’t really a concrete, actionable goal, and I think it’s illusory in the same way as chasing success in general. I think it’s better to instead focus on what you actually want in your life, and on the people in it as much as possible.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

CS 448 Post #7

I continued through chapter 5 and wanted my next post to be about the pattern Share What You Learn before moving on to chapter 6 because it interested me most out of the other patterns. The previous patterns and chapters have mainly been about our own growth and journey, so it was interesting to read about how we can help others grow. While some patterns partially touched on this by talking about teamwork, this pattern isn’t about working with others and improving yourself and them, instead it is about you becoming one of the sources of research for others to learn from. Overtime as you grow and learn more, you will have more that you can share and pass along to others who want to learn from you. This can be done by starting a blog, making a book, or some other way that you can share your experiences and work. The blogs that I and other students have been writing is an example of that too. I like that it was also mentioned that even the people sharing with and teaching others also learn from those experiences, similar to teamwork. It was also important for the book to mention that some things should either not be shared, or should be shared by someone other than you depending on what it is, like personal information or secrets.

One experience that this reminds me of is when one of my teachers in school would ask about my work, specifically math in this case. The journal I worked in for that class would sometimes have messy work when I was going through the math problems, and I wasn’t thinking much about how the work looked. The teacher for that class mentioned to me that others may want to see my work and learn from it, whether it be other students in the class, or even other people who may come across it after I’m done, so I should try to make the work more easy to understand. At the time, I didn’t think anyone would want to look through my work or think that it would help. Part of that was doubt in what I was doing. I’ve been considering it more in recent years, especially after reading through this book, that others will want to see my work and that some people may learn from it.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

The problem being discussed here, like many others in this book, is something that I think is intrinsic to any kind of professional development. It’s the sensation of being out of depth in your work, a feeling that creeps into your thoughts, slowly atrophying your confidence.

At first glance, it seems like something that shouldn’t matter. You either know what you’re doing or you don’t, right? Why should your feelings about yourself play a role? That’s how I used to feel, and I also used to be pretty abysmal at putting in the work to get anything done, whether professionally, academically or personally. As unpleasant of a reality as it is to deal with, we are not machines that can churn out code like a printing press so long as things are physically working. Something I’ve learned the hard way, which this article touches on, is that you need to be firing on all cylinders emotionally as well as physically in order to actually do your best.

The solution proposed here is to prioritize something you know specifically for the sake of rebuilding confidence, rather than simply productivity. This could actually mean sacrificing productivity in the long term, but the feeling of competence is critical. Even if you don’t think this would work on you, you’d probably be surprised.

You will not be an expert at every problem. The key to building your expertise is to connect things you can do well to things you can’t, and sort of expand your understanding from there.

For example, I struggled quite a bit with Thea’s Pantry when I was getting started with it. The whole ecosystem of tools seemed extremely unintuitive to me. The turning point for me came when I realized that everything my project was doing started with running the index.js file, similar to how in most programming projects you have a main file where the execution begins. First, I started familiarizing myself with Node.js, the runtime for the project. Then I started looking at the other tools we were using, listed in the documentation, and trying to see how each fit into the flow of the program, like how external libraries fit into a more conventional application. This took time out of my work, but that time was critical for building my understanding.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

Nurture Your Passion

This week I decided to right about Nurture your passion. As I finish my academic career and move into the professional world, nurturing my passion is something I will be conscious of.

The problem laid out in this pattern is that the craftsmen is working in a workplace where his passion is stiffled. I think that everyone will experience this. For my part, I have gone to long team meetings that felt like they could have been half the time. And that is one of the best problems to have. Work places can be toxic, or there could not be oppurtunities to learn and grow. With this problem explained, Dave sugguests that the craftsmen should look to nurture his passion outside of his job.

There are a few ways to do this. One is my making interesting side projects or Breakable Toys. I could see this being a nice change of pace, where I could focus more on learning instead of meeting the deadline. Another solution is to meet kindred spirits. Dave suggests meet up groups. One thought I have here is that if I am coding for six to eight hours, five days a week. I may not feel like building breakable toys, or going to meet ups. I like writing code, but not everyone has time to write open source in addition to working a full time developer job.

The action Dave recommends is to write three positive ideas down to bring up at work everyday. And bring one up if things turn negative. Finding happiness and positivity at work is important for anyone. So I think is is a very meaningful pattern.

I think the best advice here is that if the craftsman finds himself at a firm that stiffles his passion, it is time to move on. This piece of advice is very relevant now as we are in the midst of “The Great Resignation”. I think finding a job that a craftman can at least partially nurture his passion is very important. We spend so much of our lives at work. So it is very important to find happiness there, if possible.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 4 Part 2

Sweep The Floor

A common stereotype amongst movies and literature when an apprentice first begins their work, they are handed a menial task and told to perfect it. Often sweeping or “wax on, wax off” from the movie Karate Kid, the task being grueling and numbing in a sense. This task assigned to you wasn’t to demoralize you or just give you something to be distracted by, it was to get you ready and perfect a skill by practicing frequently.

As an apprentice you are nearly always going to be on the lower rung of experience and will find yourself doing work closer to your skill level. With programming the metaphorical broom might not be clear, or obvious. Instead of waiting for instruction you should take the initiative and volunteer for things. Take a task that you can complete or learn to complete and lighten the load of others.

This won’t necessarily seem like sweeping the floor but in a sense you are taking the tasks that will help yourself and the team you are aspiring to become an essential part of. I understand this aspect fairly well absorbing this concept through admittedly far more media than I should have, but I agree with this pattern pretty much wholeheartedly. Being apart of the group and not being as skilled as them is fairly demoralizing, but taking the lesser tasks can still make you a vital part of the process while you make the effort to become as skilled as your group members.

While learning and developing your skills you do have to step back and learn the basics. Focusing your skills and learning the essentials is integral and necessary. It’s also usually the tasks that most don’t want to work on. Mind numbing maintenance and formatting is one task that higher level workers dread maintaining. These tasks are necessary and vital to the projects success and someone needs to do it. You might as well put yourself into the problems you can solve and along the way you will learn things vital to improving the project and increasing your skills. To learn the basics is to master them. Sweep the broom before you place the first brick of the new structure. Stack bricks thousands of times before you can build a sturdy wall. This pattern is to take the mindset of the novice within your group and how as an apprentice you can learn while also helping out your group.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 4 Part 1

Find Mentors

When first understanding how you learn, and the general experience of how human beings learn, you’ll find yourself in a situation where you want to learn something, but you don’t know how to go about learning it. You take your first stab at it and find that you are learning some things but not learning constructively. You blunder around accumulating random knowledge and at some point, you might experience some success and get lucky. But more times than not you’ll blunder around and this effort might demoralize. The fault was not in your but your methods.

Mentor-ship and finding mentors is critical to learning something more specialized within your own skill set. This apprenticeship pattern perfectly describes an issue that I have frequently run into myself. It describes this path as exploring a blind alley, and this is an apt description. During my first sprint during my computer science capstone I made an effort to try and learn HTML. I looked over some example code and learned generally how to write it but fundamentally I didn’t understand how to structure it. I was blindly exploring the learning process and was failing.

I felt how I was failing and I knew I needed to reach out to something far more similar to a teacher. Some see the name mentor but what is a mentor but a highly skilled teacher. Yes of course there is more to teaching than just knowing the skill but they have the knowledge of learning the skill you are trying to and the path that helped them succeed. You need to find yourself a path that has been traveled by a human instead of blindly traveling that avenue.

I sought an actual HTML course that is commonly available in YouTube format and learned in a structured manner from a person who understood it as a whole. Now this isn’t to deter you from learning something new without a mentor as you do need the ability to learn new things without help, but something completely foreign to you requires a teacher. Mastery of a subject will require a mentor. Both require a desire to learn and to realize when you should seek other’s help.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Breakable Toys

Summary:

I have chosen breakable toys for this weeks Apprenticeship pattern. Breakable toys pattern is about learning through our mistakes. The pattern explains that we work in a high pressure jobs and environment and understandably success is expected or at times even demanded of us. However, pattern also recognizes that failure is the key to success. By failing and discovering our faults, our flaws is a crucial step in the process for us to grow, learn and build on our experience which all in turn eventually leads us to succeed. Pattern emphasizes the importance of step one for any work we are attempting to complete. First step needs to be just that, the first step – a simple README file in Gitlab with a rough structure what we are working towards is as important as every code we write and every feature we experiment on.

Why this pattern?

This is one of the most important if not the most important Apprenticeship Pattern I have come across. There many external factors affect the work that is being done like time restrictions and financial restrictions which prove to be nothing but a hindrance. This year, I had to keep learning new languages like R, python, JavaScript, mocha and chai and services like docker, R studio, VS code, Jupiter, anaconda, etc. I cannot count how many times I have been stuck on some piece of code, spiraled down because I knew failure was unavoidable and start feeling the paralyzing fear take over.

Knowing and remembering that failure is as important as success in a learning environment has helped me lot. Organizing my failures as a software developer proved to be as important as completing building our backend because It’s not wrong to make mistakes, it’s wrong to repeat them. Pattern suggested that we should work on our smaller projects because it gives us the time to learn our tools and a safe environment where we have our freedom to fail. I have written simple codes for calculator and tic-tac-toe in python. Deployed a simple ‘Hello world’ website using AWS. To quote Thomas Edison, “I have not failed. I have just found 10,000 ways that won’t work.” The trial-and-error process has immensely helped me grow and then further implement that knowledge in my projects.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Blog 6: Share what you learn

The context given here is that You have been an apprentice for a little while. You know a few things and people are starting to look to you as a source of knowledge. Up until now, you have focused exclusively on your own improvement as a craftsman. To become a journeyman, you will need the ability to communicate effectively and bring other people up to speed quickly. A good way to prepare you for that is to develop the habit of regularly sharing the lessons you have learned. This may take the form of maintaining a blog or running “brown bag” sessions amongst your peers. You can also make presentations at conferences or write tutorials for the various technologies and techniques that you are learning.

The books highlight that Being part of a community of individuals where both learning on your own and humbly sharing that newly acquired knowledge are valued is one of the most powerful aspects of apprenticeship. It makes otherwise-esoteric fields of knowledge suddenly accessible, and provides apprentices with guides who speak their language. That being said some lessons should not be shared, and it’s important to keep in mind that there is an ethical dimension to knowledge. Before sharing something, consider whether that lesson is yours to share. It may be a secret, or it may harm others. Things that seem obvious to you because of your current context may in fact be your employer’s “secret sauce” and it is all too easy as an apprentice to overlook the consequences (legal, financial, and political) of sharing that knowledge.

I can personally relate to the content in this pattern because I have worked for 2 years as a tutor for introduction to programming class (java) and it has helped me on so many levels. I remember my first instinct was to decline the job when the position was first offered to me. But then I took “a risk” and started working as mentor and all of a sudden, my understanding in the class material got better. I got comfortable sharing knowledge in an effective way, and I got great public speaking skills

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.