Breakable Toys

Success is often a tool used to measure how effective you are as a programmer, but this isn’t quite true. Failure is often referred to as the great teacher, as learning from mistakes that you make is great for improving yourself. The idea behind this is that if everything you make is bound to succeed every time then the process behind it might not haven hard. Things that don’t challenge you are not going to fail for you, but at the same time you are not going to learn anything from it.

This pattern is to take something, try to build it, and learn from your failure. You can be skilled and incredibly proficient in your strong suits but if you are not failing as you proceed you might not be challenging yourself. You might stagnate in your skill, and while you can be incredibly good at it, you still are not learning anything that is challenging you.

This particular pattern I agree with. Learning through adversity is often a great motivator. For some, time is an incredible motivator and through procrastination you have a literal time limit challenging you. For some, something new is an incredible motivator as it’s something utterly foreign and waiting to be explored. You should try something new to learn how your own skills are developing. Failure at first can deter you but taking this approach will teach you how failure will motivate you. You couldn’t succeed, but it doesn’t mean you cannot. You’ll find yourself thinking endlessly on that failure and seeing how others have succeeded where you failed will motivate you to think it has to be done. After all someone else has done it or likely created something like it. Take on a new library, build something that you never have before and let it break apart in your hands. Take the pieces and try building it again. In a sense you are letting yourself be broken by your broken project. Just challenging yourself will not be enough you have to learn from failure and learn how to fail. This pattern honestly should be called Breakable Self, as the learning portion isn’t the failed build, but rather using that failure to break a common mindset to succeed where you once failed.

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.

“Learning How You Fail” is all about realizing that you’ve grown in mastery but at the same time remain stagnant in other areas. Rather than trying to overcompensate for shortcomings, taking the same effort and seeking introspection instead seems to be more worthwhile. When I think about it that way it makes sense, although breaking out of the habits I’ve already formed will prove to be difficult.

I do agree with the sentiment of this pattern, but the thought of someone’s natural ability to either be great at something or bad at something comes to mind. Is it worth the energy to be less bad at a certain thing when you can excel elsewhere? At the end of the day, I guess that answer varies from person to person. But there is something admirable to say about someone who you’ve watched improve at something they were originally horrible at.

The “Learn How You Fail” pattern seems to be a preemptive strike of some sort. Figuring out how you will fail doing something allows you to do your best to steer clear of the pitfalls that lead you to your failure. Throughout my life, I have been one to make the same mistakes repeatedly. I’ve always said that I’m just persistent, and I am. But I would probably gain a lot more from my persistence if chose to analyze what had gone wrong, rather than to try and brute force my way through certain things.

The scenario painted in this pattern is to write some code that performs a binary search in a simple text editor and continue to fix the code until we believe it’s perfect. Once the code has reached our level of satisfaction, we also write test code from scratch. I think the point of this exercise is to realize that we ourselves may not be as perfect as we think we are. While I feel like this pattern can be applied to software apprenticeship, I feel like it’s more suitable “life advice”. Perhaps I’m not opening my mind enough and that’s a failure I could learn to learn more about.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

During the job interview that I have had. There is one question that I ask most recruiters which I believe is essential for job seekers who are looking for their first job. Deciding whether to work at that company, the question about the culture of a company is important. I think that if a company with a toxic culture and working environment, it would discourage the employees. There is this saying by Paul Graham “Nothing is more powerful than a community of talented people working on related problems”. In this “Kindred Spirits”, the author thinks that organizations’ cultures that encourage software craftsmanship are rare which I also think is true. Every day, tech workers complain about the working culture in big tech, that it’s not how they think it was when they first applied for the jobs, and that their jobs demand more time than just 9 to 5. So, I think that having a good culture is not only good for employees but also makes sure having better productivity.
The solution for those people who work in toxic culture is to be in frequent contact with people who are walking a similar road. Therefore, we should be able to seek out people like ourselves who are also looking to excel. The long road is not a road that anyone walks alone and especially in our early career, we should have a mentor. On the other hand, the culture encourages a safe environment for exploration and learning, a culture that does not limit its employees in what they should learn and that they can feel free to show each other what they’re learning to tend to attract more talents. Having no obligation to follow others’ lead would interest workers to explore and not be afraid of risk-taking. However, despite the benefits of a community of like-minded folk, we should be aware of groupthink. Avoid the questions that shock our community. Try to be respectful and use intellectual thinking to keep the community healthy. The culture and the community around us can be measured in the way it reacts to new ideas. Whether it embrace the idea after the intensive debate and experimentation? Or the ideas are quickly rejected? The most value we can provide service is defending it against those who believe that marching in lockstep is the price of membership.
To be able to do so we need to join the community where the people we work with, the blog we read, and the ideas we are intrigued by are respected. We can create our community but don’t be too strict on the ideas and topics too early. Advertise anywhere that software developers in our area might see it. Over time, these would pay off, as the group becomes larger and energetic enough, it will sustain itself even when we are not there. That’s when we have a community, good culture, and a non-toxic environment.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

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.

In opposition to my personal experience with almost every other pattern, this is one that I very much struggle with. I have enthusiasm for certain things, but I find my motivation and discipline to be very shaky in my average lifestyle. This might have to do with personal mental health struggles and general disposition, and to be fair I’m still young enough to be unfamiliar with a passion I could truly want to pursue.  

To be completely honest, I believe this is the most difficult pattern for me to grapple with. I’ve certainly been involved with different types of projects where I was more enthusiastic compared to my other teammates, but they are few and far between. However, something that I can aspire to learn is the freedom of my enthusiasm as a “responsibility of the apprentice.” I find this line to be profoundly interesting, as I would have originally thought that the more experienced veterans embodied this type of archetype. Upon reflection though, I realize how mistaken I was, as innovators can’t be pigeonholed into time spent in an industry; rather the fresh ideas that emerge from newly aspiring minds are the most important part of the process. Regardless, I’ve learned that despite age or experience, a person who’s passionate about whatever they’re working on has (somewhat) the inherent obligation to innovate in the industry they work in. 

Unfortunately, I’m of the mindset that one should do the bare minimum to pass as a competent employee; I don’t know if this is because I’ve worked enough minimum wage jobs to understand the dynamic, or if I’m a lazy person inherently. Not to say that going above and beyond is a bad thing, but that raising the expectations eventually leads to a standard for most people that is unfair and not an expected level of engagement with the job. 

Anyways, with the last portion of the “Action” section, I see a true position where I’m lacking in my work ethic. I’ve certainly been in the place where I’ve declined to present an idea that may or may not be applicable to the project in question. It’s not that I’m reluctant to share, but more so I’m not inclined to add an argument/idea where it’s not necessarily necessary. I absolutely contribute where I think an idea may be beneficial, but in my experience it’s not worth the hassle to say something that could be thrown out with a disregard to the necessity of the point being made. Regardless, I’m certainly going to take this advice to heart and implement it in the future.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.