Christian Shadis

In the apprenticeship pattern Nurture Your Passion, Hoover and Oshineye explore the importance maintaining an interest, curiosity, and passion for computer science despite hostile conditions. They discuss the ways hostile work environments, boring projects, and cynical coworkers can bring down the morale of programmers, especially those in a developer position rather than an engineer position. They discuss the ways in which the developer can resist these negative external conditions to maintain their passion for the subject and continue growing as a developer.

This pattern coincides well with the Breakable Toys pattern, which discusses using interesting personal projects to supplement your development skills to avoid stagnation. Using this pattern would be an excellent way to Nurture Your Passion. Working on fun and interesting projects is an intuitive way to gain appreciation for a skill and spending the extra time working and learning on your own is an excellent way to supplement your knowledge in the subject; a win-win!

The pattern makes a lot of sense – in my non-CS jobs, I often felt uninspired and bored. While the work was not as engaging or creative as development, I was completely devoid of passion for my work. This made the day drag, led to resentment for the company, and caused an overall poor experience working. Working in a field that I am far more interested in will give me the opportunity to have passion for my work, but I must try my best to ensure it does not fizzle out due to stagnation. If I lose passion for coding, my development job will become as unfulfilling as my previous jobs.

I hope to use this pattern throughout my career, but especially so over this coming summer. I am likely most qualified to be a software developer, which is not as exciting a job as an engineer but using this pattern will ensure that my passion for development does not disappear before achieving a more desirable position. Specifically, I plan to rebuild my website in a full-stack capacity to fill in web-dev knowledge gaps, but also just to have fun working on a type of project I have not before.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

In the apprenticeship pattern Expand Your Bandwidth, Hoover and Oshineye explore the importance of learning as much new information as possible as a new developer. They talk about how many developers have relatively low understanding of programming concepts when they enter the workforce, and how these new programmers can take advantage of the wealth of knowledge available for consumption. They make the analogy of drinking out of a straw versus out of a firehose – increase the volume of information you consume as much as possible.

This pattern particularly resonated with me. I feel as though I have a very solid low-level understanding of several different concepts in the world of software development and data analytics. I lack that high-level expertise in all the subjects I have studied in the past three years. I have attempted to emulate this pattern before learning about it: I have a shelf stuffed with books about everything from CS basics to networking to Machine Learning, and I do my best to read as much as possible about the subject.

As mentioned in my previous post, I entered the Computer Science world far later than I would have preferred and faced the difficulty of entering a vast industry filled with passionate, lifelong learners as a programmer with absolutely no knowledge of anything related to computer science. I believe I have spent my time wisely, learning lots of information about several different subjects, and managed to build up a solid toolkit before graduating.

I hope to use this pattern throughout my career, but especially so over this coming summer. I will be seeking employment as a software developer or engineer, and I feel as though some gaps in my knowledge should be plugged up as soon as possible. I plan to do a deep dive on full-stack development and connecting the frontend and backend of a system and use my newfound knowledge to do a complete rebuild of my website (ctshadis.github.io) with a proper full stack and domain name. I believe this will require learning lots of new information and applying it immediately in a way that will make me more qualified for any full-stack development jobs I apply for.

Reference: Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

In the apprenticeship pattern Use the Source, Hoover and Oshineye explore the importance of learning from reading code from open-source projects. They start by explaining how young programmers often struggle to self-assess their code, since many have not seen enough professional-grade code to understand how theirs stacks up. Luckily, all the open-source code you could ever want is freely available to any developer. Hoover and Oshineye encourage the reader to use these resources as much as possible to gain a better understanding of code inside its context in a working software system.

This pattern closely resembles the advice I recently received from a software engineer family friend. She was transitioning from test automation to full-stack Python development and offered some insight into her job search process and some strategies to use for myself. Her main piece of advice was to browse GitHub for code written by other engineers – open-source projects, employees from the company at which you are applying, or anything else which could prove useful.

I started my Computer Science journey later in my academic career than I would have liked to, having switched into my school’s CS program toward the end of my freshman year in college not knowing anything about the discipline. I am still learning what good and bad code looks like, and how to take the concepts from classes and implement them to scale in deployed software systems. My time in a traditional classroom setting is quickly coming to an end, and I must transition my focus to self-education

I hope to use this pattern throughout my career, but especially so in the first few years. Since I started my CS journey, Git has been a good friend of mine, and I have always been interested in getting to know how it works so well. As such, it would be fitting to start by looking at the code for Git, focusing on the use of data structures. I still feel as though my biggest weakness as a developer is understanding how small microservices and programs interact in a much larger environment. Looking at the source code for distributed systems will give me valuable insight into how the puzzle pieces fit together.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

In the apprenticeship pattern Concrete Skills, Hoover and Oshineye explore the importance of developing discrete, demonstrable skills with specific technologies. This is an important pattern to implement as a young programmer because often in the hiring process, your skills are often more surface-level, and your value lies in your potential. Developing concrete skills makes you a more valuable candidate and thus more likely to receive an offer.

This pattern makes a lot of intuitive sense. My skills (outside of specific languages) are top-level, and I do not have a lot of projects to demonstrate specific skills and value that I can immediately provide to the company/team I am joining. Currently, my appeal as a candidate lies primarily in my successful academic career and ability to quickly learn, and secondarily in the skills I already possess. In order to successfully find a job, supplementing my portfolio is necessary.

This pattern coincides well with the Breakable Toys pattern in that building those personal, low-stakes projects will allow the developer to demonstrate their skills in a discrete, specific, and demonstrable environment. The toy can then be used in the hiring process, or to develop a demonstration for the hiring process. Having that project available to demonstrate during the interview process will reassure employers that not only does the candidate have potential to contribute greatly as time passes but can also contribute immediately.

I hope to use this pattern throughout the next several months while trying to secure my first career position. I have identified the biggest weakness in my resume to be my lack of full projects to display my skills. I have worked on multiple programming projects that I can use, but they all seem too simple to truly impress a hiring manager. I have a great academic record, but little to concretely prove my development skills. In conjunction with the Breakable Toys pattern, I will look to develop a full-stack project over the coming months that I can add to my portfolio and increase my chances of being hired.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Emptying the Cup. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

In the apprenticeship pattern Stay in the Trenches, Hoover and Oshineye explore the importance of maintaining a development position in the face of success and the opportunity to progress into management. This is a very important topic, since many developers (and employees of other types too) have their careers reach stagnation once they make the leap into management due to their misconceptions about career progression.

This pattern is counterintuitive to me, as historically I have considered management positions to be the goal of any employee, and the thought of turning down a promotion would not seem to propel a career forward. Upon further reflection, the benefits of the pattern are more apparent. If a developer commits to remaining a developer throughout their career, they remove limitations on their potential growth as a developer and employee. They will continue to grow and evolve with the industry and become masters of their craft. Conversely, a developer who accepts a promotion into management may stagnate quickly. Management is a completely different occupation than development, and the recently promoted manager may find their skill set does not transfer. Similarly, the organization may not have much room for progression beyond middle management.

Remaining in a development position instead allows the programmer to spend their entire career mastering their development skills, increasing their capabilities and qualifications for more intense, higher-paid, senior-level programming positions. The programmer can advance and progress with development-based promotions, but staying out of management lends a significant advantage for attaining more prestigious programming jobs in the future.

I hope to use this pattern throughout my career. Once I had aspirations of progressing through management positions until I am high up at a large company, but progressing through management positions won’t be possible by virtue of programming skills – instead, a more attractive plan is to progress through the levels of development and engineering to finally land at a senior position. Not only will this maximize my potential as a coder, but remaining in a position interesting to me instead of stagnating in a more boring occupation will maximize my job satisfaction.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Walking the Long Road. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

In the apprenticeship pattern Breakable Toys, Hoover and Oshineye explore the effectiveness of learning through failure, and the dynamics of doing so in a workplace where failure may not be embraced. Essentially, they advise the developer to work on projects on their own time with the important distinction that they can safely develop without harming any other developers with breaking changes. They refer to these projects as ‘Toys’ because the developer should work on projects they find interesting or fun, which will make them more motivated to continue working on it.

This pattern, unlike some others in the book, is perfectly intuitive. “Practice makes perfect” is one of the more well-known clichés we echo, and this pattern is based on constant practice. In fact, much of the information I’ve learned about programming thus far has come from troubleshooting code I’ve written and figuring out why it doesn’t work. The only problem with constantly practicing a trade menially is a blurring of the lines between work and free time; however, developing projects of personal interest to the developer would make the practice far more engaging and feel less like work.

This pattern is not a particularly difficult one to implement, as developers are likely to build personal projects simply because they enjoy development. Yet if a developer uses their skills to build something they don’t care about, it only feels like work – instead, working on building ‘Toys’ feels more recreational and sustainable to implement in free time. To effectively use this strategy, the developer must emphasize the breakability of what they build and focus on using failures to improve both the project and their underlying development skills.

I hope to use this pattern throughout my career, but more specifically I plan to implement this pattern throughout my first development job. I will be exposed to many new technologies and frameworks in my new position. Using these technologies only at work would limit my comprehension of them. Instead, utilizing these new technologies in the failure-friendly environment of personal development projects will maximize my improvement as a developer.

Reference: Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

In the apprenticeship pattern Be the Worst, Hoover and Oshineye explore the dynamics of skill level on a team as a software apprentice. They assert that while it may seem counterintuitive, it is a better plan to not be the strongest developer on a team, for that situation yields less opportunity for growth and learning. However, if you are surrounded by accomplished developers who are more skilled, there is far more to learn from them, and far greater space to grow.

Be the Worst, like The White Belt, seems to go against the average worker’s intuition, and are somewhat related to each other. One might think that being the ‘big fish in a little pond’ is a surefire way to distinguish yourself from your colleagues and get promoted, or maybe compete for more prestigious jobs. However, being that big fish increases your chances of stagnation. If you are already at the top, there is nowhere to go, and you may find yourself plateauing as a developer. It is more beneficial to contribute to a big pond and be a little fish, because the little fish can learn and grow more, and eventually start to grow larger than the fish around it, and eventually may become the biggest fish. Combining this pattern with The White Belt by accepting new methods and techniques unfamiliar to you will maximize learning potential at any position.

This pattern is likely to be rather difficult to me, having gone to a small high school and university, and finding myself as one of the “big fish” in both. It would be very unnatural for me to be the worst member of a team, but it would catalyze the learning process and motivate me to become a better teammate (or even the best). In turn, that growth and learning will open opportunities for more interesting and lucrative positions in the future.

I hope to use this pattern throughout my career, but more specifically I plan to implement this pattern at my first development job. I plan to work at a large tech company, and that company likely would hire largely candidates from more prestigious computer science backgrounds, with more dense portfolios and extensive experience. I could perceive this as a disadvantage in the job market but utilizing this apprenticeship pattern instead would motivate me to improve my contributions and prove myself as a competent and evolving developer.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Accurate Self-Assessment. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

2/26/2022

In the apprenticeship pattern The White Belt, Hoover and Oshineye explore the importance of maintaining a beginner’s mindset even when already a subject matter expert. They attribute this largely to creativity and open mindedness in problem solving: a programmer who is an expert in Language A should act as though they are a complete beginner in Language B to avoid their prior knowledge restricting them from learning all techniques and conventions of the new language.

The whole pattern seems counterintuitive at first, but a small example illustrates the concept more clearly. If a Java programmer wanted to join two lists together in Python, but by only using their Java knowledge, their solution would undoubtedly be far more complicated than a simple list comprehension that Python allows. Putting aside prior knowledge in favor of re-learning problem solving methods would allow that same programmer to utilize Python’s list comprehensions. In a more general sense, by ‘taking off the black belt’ and ‘putting on the white belt’, a developer can learn best practices and technically efficient problem-solving techniques in any language, which will further bolster their overall programming skills and employability.

This pattern also shifted my perspective toward my education so far at Worcester State. Over the past few years, I had found myself frustrated with the methodology of the Computer Science department, which I believe is rooted in giving students exposure to as many elements in the software development world as possible. My frustration lied in the fact that we, for the most part, didn’t do very deep dives on any language or technology. After reading this pattern though, I realize this approach was about showing us as many different things as possible to prepare us to do just what this pattern teaches: learn new technologies and languages as your career develops, rather than becoming a subject matter expert and looking at the rest of your development career through the lens of that subject.

I hope to use this pattern throughout my career, but more specifically I plan to implement this pattern while I continue to learn Object-Oriented Programming languages, especially Python. Most of my OOP code has been written in Java, yet I consider myself fluent in Python. This is a clear example of letting my knowledge in Java prevent me from re-learning object-oriented programming in Python, which would harm my performance in a Python assessment or interview. In this case, and throughout my career, I will make the decision to set aside my knowledge to re-learn the fundamentals through a separate lens to enrich my understanding of the subject.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Emptying the Cup. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.