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.

This sprint ran more smoothly than Sprint 1 did. As a result of having obtained a more detailed specification by coordinating with the goals laid out by Dr. Burge from Nassau Community College and having obtained a better understanding of the individual skill-sets of our team members, we were able to produce an OpenAPI specification that defined 8 of the 9 requested endpoint definitions. The yaml file containing these definitions was then used to write, build, and test these endpoints in our back-end container. These methods were then tested internally within the container by using the Visual Studio Code environment to launch HTTP requests from 2 files (guest.http and qs.http). “Swagger UI” was used as a VSCode extension to facilitate this process.

It was easier this sprint to distribute work among the team, because the Open-API spec was available shortly after the start of the sprint, enabling back-end code to be written and unit tested. As testing progressed, we would modify the spec as we made changes to the back-end code to fix bugs.

Although we did a better job at keeping the Git-lab Epics and Issues boards properly in place than in the prior sprint, this may have been the weakest area of our efforts. Our intention is to improve the ongoing modification of this Scrum material as we progress to sprint 3.

We improved our use and efficiency of GIT to Git-Lab coordination, were able to build semantic versioning, checked the structure of the Open-API definition with Swagger Preview, and started looking into using a secure key. This key will be coordinated as a priority in the sprint 3 effort through communication with the IAM team.

I was able to set up a fork of the NEST Android application with the intention of doing system testing of the REST API. By using Android Studio, my prior knowledge of Android development with Java, and the help of a guiding YouTube video, along with general help from stackoverflow.com community, I was able to write 6 classes in an isolated namespace to the project. This code uses an android library call Volley to facilitate REST API development. This code launches an activity from the main NEST activity which allows the user to make requests to the remote back-end MongoDB database, and returns responses, which are then displayed in a scroll-able text view component.

The layout used by this activity used a relatively new UI component called a Constraint Layout, which improves the efficiency and maintainability of its XML code with the support of a sophisticated design tool allowing “drag and drop” of components, allowing them to effectively present a user interface which will scale properly over the hundreds of different android devices, all with different screen resolutions, aspect ratios, and device sizes.

The system testing was burdened by the fact that calls from Android were producing a Timeout Error on every attempt. With the help of Dr. Wurst, I am in a better position to get these calls working by the first week of the upcoming sprint.

I was impressed with this sprint, because our team accomplished the 2 main goals of this classroom effort, the first being to improve the skill-set of the team members in a “real world” development effort, and secondly, to help with the general progress of the LibreFoodPantry work to produce a product to help those less fortunate than ourselves.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.