The Deep End

As the title describes the deep end is like the deep end of the pool when you are first learning to swim. While of course you need to learn the basics before you reach the deep end, the question then becomes do you make that jump when you have the necessary skills?

The answer is yes of course, and like the deep end of the pool as a young child it can be scary sometimes. I remember when I was younger and had learned how to swim in the deep end as well. I came to another kind of deep end at a local beach by a pond. Just swimming out into the deep wasn’t enough there was a fairly high tower that you could only jump off of if you could swim in the deep end. The only way to advance further was to take that leap. I unfortunately hit my arm on the way down and had it gotten stuck it definitely would have been broken. Luckily I made it just fine with a scrape, but the fear of taking the jump again was gone. I had made a mistake that I wouldn’t make again.

This particular pattern is one that I should really utilize, often you can get to a point where you may not really know where to go next or what even to do when you jump. Placing yourself into a situation that is more difficult than you have been before is critical for improvement and certainly applies to software development. With software development though you can know what you are likely going to face when taking on a new project to grow and adapt yourself. With any problem there is the general assumption to be made about what the solution is. The real challenge is in how you’ll solve it when you arrive at problems that present themselves while you have no solution.

I don’t find myself disagreeing with anything in particular about this pattern, unlike the previous one. It summarizes a problem and gives a solution that is a common theme in life. Sometimes to improve you need to take on a bigger task or place yourself in competition against those who you know are far better than you.

As for applying it towards my career as a software developer, there really is only one thing to do. Find a deep end and go for a swim. Worst case scenario is I’ll not achieve my task, which is only another opportunity to try it again.

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.

In many crafts, an apprentice’s main goal is to gain the experience and knowledge necessary to succeed in the craft of their choosing. Whether it is art or programming, an apprentice goes through the process of learning not only what techniques exist in their craft, but also how to acquire the techniques they learnt to achieve their goals. Though I personally cannot speak about art due to having no prior experience, I can say that in the field of programming I am aware that I will often be tasked to work on creating solutions for people. What I am also aware of is that we may almost never be on the same page regarding what customers want and what I may think is best for them. Though I personally may want to give a customer a product of code that balances functionality and aesthetics, it is this focus that may hinder the development process rather than help it. This situation is an apprenticeship pattern referred to, aptly, as “Craft over Art”.

A craftsman may encounter this patterns when they are put in a situation in which they are tasked with creating a working solution for a customer, though they may use this opportunity to show off their knowledge of the craft rather than applying the appropriate skills in order to create something viable and useful. In the case of a software developer, the craftsman may choose to put more emphasis on aesthetics by implementing functionality that may look fancy rather than using the proper functionality and techniques in order to deliver a working product that meets the customer’s specifications. Some developers may fall into this pitfall because, they believe, that the quality of the product is best shown only through how “fancy” the implementation looks and not through how the final product itself performs. This pitfall may be especially evident in software development, where the product itself may have to be maintained by other developers in the long run but may struggle with by virtue of how the original developer approached the implementation in the first place.

Though I personally may want to show off my skills by making programs in a creative way or to refine an existing piece of code by implementing fancier algorithms or optimizations, I understand that there is a time and place for that, oftentimes away from the professional environment. In fact, I strongly believe that having useful code to work with as soon as possible is far more important than having code that looks fancy and intricate that fails to deliver on its specifications.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern urges apprentices who are going to be entering the workforce to take on the tasks that nobody else wants to do. The tasks on the edges of the project, like documentation or code refactoring. It explains that this is a good way to help out the team without much experience, to ingratiate yourself with your teammates, and show everyone that you are capable and a useful member of the team. It will also help you gain some humility, by doing the tasks nobody else wants to do and learning the importance of these tasks.

I think that the real strength of this pattern is in laying down expectations for apprentices about to start, or just starting their time on a real team in the real world. We have to humble ourselves and realize that when we first start at a project, we are new and we haven’t earned our chops, or shown anyone what we can really do. By choosing to take on the menial tasks that everyone else has pushed aside, we are choosing to show everyone that we are willing to get our hands dirty, dive into a new project, and prove that we can be valuable besides just as a workhorse on these tasks. Showing the team that you are ready and willing to contribute to the project in whatever way you can shows that you aren’t someone to shy away from a challenge. The pattern also warns about the pitfalls of this though, and they are good things to keep in mind so you don’t get stuck doing menial work forever. I had kind of planned on this since the beginning, I think it is vitally important to show people that you are willing to do what needs to be done, and this pattern has reinforced the need to be ready for that and reminded me that while I am willing to do it, I also need to advocate for myself and make sure that I am getting what I want as an apprentice: the opportunity to learn, and to work on something bigger.

I don’t really disagree with anything from this pattern. I honestly think that it is all just good advice, it is important to be able to earn your place as a valuable team member, and it is equally important to remember that you are valuable, and to use it as a learning experience, and as a way to show your skill. It is a valuable part of being new to a project and is a great way that we can gain experience outside the classroom, and apply what we have learned to something real and tangible.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

The pattern I decided to read is titled “Record What You Learn” from chapter 5 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts out by giving context of a situation I know I have found myself in multiple times. This situation is one where I am relearning the same technical lessons over and over again. The proposed solution to this problem is to keep a chronological record of the lessons I’ve learned. This record can be made in the format of a blog or wiki, to name a few options. Additionally, these kinds of records can be made public or private. Public records are good for building connections since others can read them and private records are good for being painfully honest with yourself about your progress. The last section of the solution ends on discussing how your record keeping tool can be an example of a Breakable Toy and how this Breakable Toy can help you extract lessons from it as one grows from a novice to a more experienced developer. The actionable item this excerpt ends with is encouraging its readers to start immediately because these entries can become the basis for books, magazines, and blog posts in the future.

In response to the question, “Will this pattern cause you to change the way you will work?”, my answer is a resounding yes. I’ve read this pattern multiple times before writing this blog post and have slowly been successfully developing my own personal journal/“Breakable toy”. I think one of the reasons why this has been so effective for me has to do with the following line I found interesting while reading this pattern, “The private record allows you to be painfully honest with yourself about the progress you are making”. In my journal, I get to reflect on how well I truly know certain technologies and what I still want to learn. And whenever I learn something new, I write about it in a way that is meaningful to me (as opposed to doing work for a class deadline). Therefore, I completely agree with the information in this pattern. It has been a super beneficial process for me so far and it is rewarding to physically see the evidence of what I’ve been learning in one localized place. I’m happy that if I have taken anything from this book, it is a journal/“Breakable Toy” I can continue using in my career and life.

From the blog Sensinci's Blog by Sensinci's Blog 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.

Breakable toys is an apprenticeship pattern similar in spirit to Be the Worst. They both encourage us to improve by failing in one sense or another. While the Be the Worst apprenticeship pattern focuses on joining a team where you are the worst in order to learn from others on your team, Breakable Toys emphasizes working in an environment where failure is not only possible but even encouraged. Such an environment usually means working on your own projects where any mistakes you make have little to no consequences and allow you to learn from them.

Overall I think that this pattern makes sense, and is a good way to improve ones skills as a developer. I whole heatedly agree with the idea that failure is integral to improving in anything, and especially when applied to programming. I know that whenever I make a mistake I tend to remember that mistake and in most cases I am able to learn from it and improve myself. When writing code for class projects or assignments I frequently screw up certain feature implementations and as a result I learn of a better way to do what I failed to do. Be it through personal research after the fact or direct guidance from someone more experienced than I.

Personally I haven’t really created an environment for myself where I can comfortably fail. While I definitely learn a lot from mistakes I make at school, I wouldn’t go as far as to call that a safe place to fail frequently. Ive had a few personal projects in the past, but I never really thought of them as more than things to slap on a resume or to pass the time. Having read this apprenticeship pattern however, I definitely have a different outlook on those past projects, and will also have a different outlook on future ones. I will likely try to work on projects that heavily involve tech stacks I am not familiar with in order to attempt to learn from my failures working with them. It will be difficult at times as I can be impatient, and the slow initial progress with some of these projects might be discouraging, as well as any screw ups that might come along. But since I will be more aware of the fact that these setbacks are actually helping me in the long run I hope it will help me keep pushing forward.

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

For this week, I am going to cover another type of “new material” that I have learned within my software design class. This “new material” is known as the REST API. As per usual within my blogs, I always try to find some connection to a past experience or previously learned material; for REST APIs, the closest materials would be other web design tools such as HTML and JavaScript.

In a nutshell, APIs are used as a way for clients and servers to interact with each other; these interactions can involve exchanging data or performing behaviors with that data. Languages that involve APIs are: JSON (JavaScript Object Notation), Python and HTML, to name a few. The interactions that APIs perform with these languages are often done in class using modules called “endpoints”.

These endpoints are “sub-containers” that perform interactions with items or collections of data. Examples of endpoints include: GET, POST, PUT and DELETE; whether or not the endpoint works with a collection or a single item is dependent on additional parameters (such as an “id” for an object). Connecting REST APIs to additional parts of the class, API “calls” (similar to functions in other languages) involve setting up ports to connect to a host server; once connected, the call will attempt to perform the requested endpoint interaction with the data found at that port/container.

Linked below is a website that will get anyone interested in REST APIs up to speed on how they work, why they’re important, and other applicable knowledge about the topic. I chose this article, as well as the topic of REST APIs in general, due to the fact that I still struggle with the process of working with them; I hope that with further study, I can become proficient with the material. It seems as though REST APIs, alongside the other material within this class, follows a similar theme; in addition to being based around software design, these topics are related to creating “inter-connected” projects. This makes sense, as very few projects are done in isolation nowadays.

When moving forward, I hope to gain two benefits from learning about REST APIs. In the short term, I would appreciate using this newfound knowledge to help complete my homework assignments. As for the long term, it has been discussed that REST APIs are a profitable market in the computer science field; by being proficient in this aspect of programming, I will be in a class by myself among other programmers.

Link: https://www.edureka.co/blog/what-is-rest-api/

https://www.redhat.com/en/topics/api/what-is-a-rest-api

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.