Unleashing your Enthusiasm

For this week’s blog post, I have decided to look at the apprenticeship pattern “Unleash your Enthusiasm”. 11this chapter is all about you as a programmer being very excited about the craft of software development. However, you find that you are holding back and being more enthusiastic about the work your colleagues are doing. Fear not, as your enthusiasm and love for the craft does not go unnoticed. Because of your inexperience, it brings some unique attributes to the team, including that infectious enthusiasm and an unfettered imagination. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“In any group setting, there is a tendency to conform to the norm, particularly for newcomers. Most teams are not hyper-passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain. Therefore, enthusiastic apprentices can often succumb to the urge to fly under the radar. They either repress their enthusiasm altogether or allow it to manifest only outside of their day jobs.” (Dave H. Hoover, Adewale Oshineye Pg. 22).

Essentially because of you being a newcomer you tend to try and acclimate to the rest of the group and start to lose that newcomer enthusiasm and begin to try and become unnoticed. The yare risks however that come from unleashing your enthusiasm. One of these risks are that if the morale is low or the team is not welcoming, you will likely get some eye rolling from your enthusiasm.  Another risk that could come from unleashing your enthusiasm is depending on the team, they may not enjoy that you are exposing your ignorance and where your knowledge stands.

From reading this chapter I found it to be an interesting take on when you begin working in a job setting with a new team. I liked that in the chapter it talks about both the positives and negatives of unleashing your enthusiasm. Although this chapter did not really change the way that I think about programming and my enthusiasm when I would get a new job. Knowing who I am as a person and my personality, I am not one to “unleash” my enthusiasm on a new group of individuals, so I don’t see this chapter as being helpful in that sense. However, if I were to train a newcomer and they brought this enthusiasm to the table, I now know what they could bring to the table, and I will not disregard it now.

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Sprint2- Retrospective Blog

For this sprint, my team, team-1, have worked with two epics, which are refactoring backend and adding commitlint to gitlab-ci.yml for all projects which are reportingAPI, reportingFrontend, reportingBackend. We have finished the epic of adding commitlint to gitlab-ci.yml for all projects by following the instructions. However, the most important goal that our team wants to achieve in this sprint is to make the backend work as expected. First of all, we checked the code to see how they were written, and to see if they were written correctly. However, after I found many errors in syntax and some logic implemented incorrectly in the old code. I decided to create the new backend instead of spending time to fix all of those bugs. As a result, we divided our team into three subunits to work independently with the backend. One would try to refactor or fix the old code as much as they can, one would try to create the new backend, and one would create the test for the backend.

My role in this sprint is to create the new backend and refactor it in the new style. I worked with a docker file and index.js to create a backend server. Then, I created a docker-composed.yml containing node image, mongodb, and rabbitmq, to ensure all the services work correctly. After that, I used javascript to generate all possible methods that can be used to make required http requests, endpoints. In the end, the new backend worked as I expected. It has Rabbitmq service and Rabbitmq functions used to receive all messages from a queue. Then, the backend will store those data into mongodb as two collections, guestInfo and Inventory. Finally, this backend will generate the .csv report when we send the required http request.

As for the results of this sprint, I believe our team has achieved its primary goal which is to make the backend work. However, it is not perfect. There are still some issues that we need to solve in the next sprint to meet the customer’s requests, such as creating a function that automatically consumes messages using Rabbitmq, adding some more required columns to the report, change the _id property in the fake data to studentID. On the other hand, we have also created a test for this new backend even though it is not completed yet. We are planning to complete it in the next sprint.

In summary, there are some differences in how things work in this sprint. We have worked independently on the same problems but in different ways. This sounds like we wasted our time having multiple people working on the same problem. However, for this project, I think it makes sense to do it this way. That is because we all do not have enough knowledge to solve the problem, so there is no guarantee that we can successfully create a new backend. So, we decided to keep it safe by preserving and refactoring the old code while working on the new code. I think this is one of the disavantages of this sprint and needs to be improved in the next sprint. In the next sprint, we will back to work with the regular way, each person should take care of different issues to use their time effectively. For myself and my entire team, we have made some improvements comparing to the first sprint. The only thing I think our team should improve more is that we need to communicate more to understand the project deeply, to be ready for the presentation.

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

Apprenticeship Patterns “Confront Your Ignorance”

This apprenticeship pattern describes to us how after being able to expose your ignorance, you must now be able to confront it. Once we are able to find the gaps in our skillset, it is up to us to tackle those problems head on. Confronting your ignorance does not mean to learn in isolation because doing that encourages us to create a standard where hiding your failures is okay. What we need to remember is that learning in public is always beneficial for an apprentice and that is what helps us move onto our next step of becoming better software engineers. What we worry about is when exposing your ignorance you become dependent on others as well as just creating problems for others when you don’t know something. That is why confronting your ignorance helps bridge the gap from between exposing your ignorance to being able to actually contribute to projects because confronting it is the best way to fill in your gaps.

What I have been able to away from this is that just because we don’t know something does not mean we should just constantly depend on others. If we fail to understand how to do something, we need to be able to ask for help so that hopefully next time we can do it on our own. With every project we take on in the future, it is obvious that we will need help in order to continue onward. We need to not work in secret to hide our failures and to use our mentors and peers as resources so that we grow and fill in those holes we all so definitely have.

After reading this pattern, it helped my reflect on a time where I created a Java application for work that would scan RFID badges of employees. I was tasked with this and initially had thought that if I could do it on my own I could prove I was capable and hardworking. In the end I took too long and did not have much to show for it, I was then partnered with someone who did have experience creating apps and in the end we were able to develop a functioning app. Pattern reminded me about this experience and that exposing and confronting my ignorance does not show that I’m weak, but that I want to grow as an apprentice.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

I think that in this sprint we greatly improved our workflow as a team, we knew what we were doing and were a lot more efficient about knowing what we were doing and completing it. We were also a lot better at communicating with each other this sprint than in the previous one, keeping each other updated on what we were doing and what we had to wait on in order to complete our section of the work. We just overall worked a lot better together and were able to complete things as a team as needed in order to get the job done.

Despite the fact that I think we did work a lot better as a team and we did communicate better, I think that it could still certainly use improvement. While we are better about it I still feel like there is some difficulty in communication about what each of us is working on at any given time, and we tend to just wait until class to talk to each other, other than the occasional discord message. We also still have trouble working on the technical side with git, making sure we are merging when we should and focusing on the epics, most of the time, at least for me, we just focus on the individual issues on the issue board and completely ignore the epics aspect of the project organization. Similarly, I think we are still having issues actually running the code with the backend in order to actually test things, but I think that is something we can definitely iron out in the last sprint.

To improve as a team, on the issues listed above, I think that we need to focus a little more again on communicating, especially when things are done and need to be reviewed, and then when they need to be merged. I don’t think we have huge issues in these areas, we just need to make sure we are letting everyone else know when we are done with things. We should also make more explicit what we are working on at any given time, only pulling things to in-process when we are actively working on them would fix this issue I think. Possibly we should focus more on completing epics than the individual issues, just to keep a little more structure to our workflow, but I don’t think it’s been a huge problem thus far, just something to think about. And lastly, I think a big focus of sprint 3 would be making sure we can actually run the code for testing and have the docker images work properly and everything. I think we have talked about it briefly, but getting that fixed I think should be a priority.

As an individual, I think I still need to be a bit more productive and involved in the actual coding process, a lot of what I have done this sprint was just refactoring the file structure and getting some documentation issues worked out (which come to think of it could probably use a little more work). Other than that I feel like I have done very little actual programming work in the past 2 sprints. I just feel like when it comes to doing things other than coding I have a little bit less interest and it is harder to motivate myself. This is a personal issue and I want to finish out the last sprint being as productive as I can be. I am definitely also a culprit of not communicating enough, so I want to make sure for our last sprint that I am keeping everyone updated on what I’m doing and when I’m planning on doing it.

Issue #18 Removed an old file that was a placeholder from a previous group called endpoints.js.

Issue #21 Merged the endpoints folder and the subProcesses folder to remove complexity within the system, keeping the endpoints folder as the main folder for the endpoints.

Issue #2 We discussed naming conventions as a group and I added a markdown file in the Documentation repository to keep track of any style conventions we want to keep a record of.

Issue #24 Created the endpoint for getInventory, using the endpoints from the API and the methods written in the Inventory.js file for functionality.

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.

Reflect As You Work

Reflect As You Work is a pattern which requires retrospection. When working it is important to actually gain experience and not just go through the motions. Quoted from the pattern, “The goal is to extract the maximum amount of educational value from every experience by taking it apart and putting it back together in new and interesting ways” is an excellent quote which I think encapsulates the entire idea of the patten. As apprentices we want to learn as much as possible since not doing so will start us on a road to complacency.

One thing that I will implement into my work is the idea of Personal Practices Maps. This seems like a very useful tool which will aid in retrospection. Right now I know my strengths, but I do not know my weaknesses. Using the Personal Practices Map will allow me to observe trends in what I do and help with my retrospection.

Another thing that I enjoyed about Reflect As You Work was that it mentioned how good experience directly leads to career opportunities. When Dave learned about a new pair programming technique it directly lead to him writing an column for StickyMinds.com. While I don’t expect to be writing any columns, I do hope that the skills I gain will lead to other employment opportunities in the future.

Reflecting as I work will help with Drawing My Own Map. While navigating the map I should be acquiring new skills which will shape the future of the map, which will lead to even more skills. Over time these skills will drastically improve my marketability, which will have a much greater impact on my map as opposed to earning a lot of experience at a single company.

Reflect As You Work is a good pattern which, while not flashy, is very important to remember throughout the entire apprenticeship. As an apprentice, the goal is to learn. It is important to always learn from your experiences and grow as a developer; if not you will become stagnant. My goal after reading this pattern is to begin reflecting on my work and actively try to improve myself, because if I don’t no one else will.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

I did the bulk of the work for this sprint in one sitting. I haven’t really figured out whether I think this was a good idea or not. On one hand, changing gears is something I’m not great at and I try to minimize it as much as I can. On the other hand, I wound up being pretty burnt out on the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/15

Here’s the first issue I completed. “Learning RabbitMQ” is kind of an ephemeral goal, so I decided to only look into what I consider to be the bare minimum of what we will actually need, which is essentially just the ability to put messages in the queue and take them out of the queue. I feel like I know enough about it to work with it and help get other people up to speed.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/16

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/17

I’m sticking these issues together because I wound up having to do them at the same time. To refactor things in the backend, I had to at least make sure it ran without errors, and to do that I needed to sort out the dependencies so that everything being imported at the top of index.js was either removed or installed.

It wasn’t until after I finished doing all this that I remembered someone had already modified the backend server to get it to work, only on a different branch. While that kind of tunnel vision is generally a bad thing in my opinion, doing all this work enabled me to actually understand how this project works. Specifically, I had a breakthrough in understanding that the server is actually just a program with its entry point being the index.js file. My previous experience with web development lead me to believe that the actual flow of the program logic was obscured behind all kinds of layers of indirection and it is in my opinion a little embarrassing that I didn’t see sooner that that was not the case.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/22

Finally, I deleted a directory containing a project from the previous developers that they were using to mess around with RabbitMQ. Not much else to say about that.

I also considered tackling the issue I wrote before about updating the documentation for every project, but I decided against it. Apart from being a little burnt out, I also figured that it’d probably be better to put it off as long as possible so that whoever tackles it can go into it with as much knowledge as possible.

Individually, I think my main issue is just a matter of setting aside time for this project. As a team, I think our biggest problem is the granularity of our issues, although it’s somewhat necessary considering our experience level and the nature of the project. While I struggle to put the work in, I don’t think the team as a whole has this problem. 

All that being said, I am kind of excited about this project now. I was initially skeptical of my ability to contribute to this project, but now I feel like I actually sort of know what I’m doing

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.

Draw Your Own Map

Draw Your Own Map is all about defining your career path and how it aligns with your values as a programmer. When working at any job it is always important to keep in mind your goals and aspirations; don’t let a company’s goals supersede your own. Sometimes it may be tempting to stay with a company that doesn’t fit your map since they offer promotions and raises, but it will benefit you in the long run to find a more suitable job.

I think this is a fantastic pattern for apprentices to learn since it is very tempting to stay with a job to peruse promotions. I worked at Taco Bell, a job I didn’t like, for four years because I accepted a managerial position. If I had learned about Draw Your Own Map before I began working I wouldn’t have stayed with Taco Bell so long.

When choosing between fast food jobs there is not much difference between work environments, but when choosing between software development jobs there is a huge amount of difference between two companies, let alone the entire industry. This is why it is so important to Draw Your Own Map wisely and choose the right path, because you do not get a second chance.

Your path compounds on itself, as shown by Desi’s experience. She began work as a system administrator, but found that she wanted to program. Few companies would hire her since she had a lot of systems experience, but little programming experience. This is why it is so important to always stay on your map and make sure the experience you gain is experience you want. Eventually Desi found a company which hired her, and is much happier at her current job.

Reading this pattern has definitely changed my perspective on my future career path. Draw Your Own Map suggests to set small goals for yourself since achieving these goals will help you create new ones. I’ve been debating if I should (professionally) hop around jobs, and this pattern has convinced me to do so. Hopping jobs will allow me to experience what the industry has to offer, and to decide what I want to do based on personal experience rather than my own thoughts about what software development is. I thoroughly enjoyed Draw Your Own Map and I think it’s insights are invaluable, especially to someone like me.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.

Sprint 2: Retrospective.

If I were to define this Sprint for our team, I would use the word “Progression”. That is a key difference I see within the team wrapping up our second sprint. In the first Sprint, I was personally all over the place regarding my focus and my steps in collaborating with the team. It simply felt like I just did not know where to start. This Sprint, I was able to lock myself down and work on something for a long period of time. Opposing to the first Sprint where I was trying to have an ultimate understanding of every key word in our epics. I was successful in building a good base of knowledge for myself during the first Sprint. But, as the second Sprint went on, I had a better grasp of how to prioritize myself and my work. I noticed it within the team as well. It seemed that during this Sprint, we were all one the same page. And if someone wasn’t up to speed, we often stopped what we were doing to help. Honestly spectacular work from the team. Anytime anything was uploaded, the teammate who uploaded the work always made sure to let everyone know and teach them about their work.

One huge piece of work I had during the second Sprint was my “NodeJS App Secured by Keycloak Demo”.

Gitlab Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/tree/KeycloakNodeJSAppDemo

Tutorial Link: https://medium.com/devops-dudes/securing-node-js-express-rest-apis-with-keycloak-a4946083be51

The primary focus of the tutorial was to secure Node.js REST APIs with Keycloak Node.js (Server-Side) Adaptor. The great thing about this tutorial is it did multiple things for me. It gave me an extreme understanding of how to work the Keycloak Administration Console. It turns out to be a super simple interface to work with. At first it was a little confusing but once you can understand the Keycloak lingo/terms it is a cake walk. I feel super confident within the Administration Console because of the tutorial. It also teaches you how to generate access tokens for users. Overall helping you build your Node.js application to be configured for a Keycloak Node.js Adaptor. I still have more plans with the tutorial. I got it to work. I got the correct output the tutorial outputted. But I still don’t have a 100% concrete understanding of how everything is working. I will be continuing to work with this tutorial as I believe it will be much more useful for us in our next Sprint.

It is tough for me to talk about things that didn’t work well for us this Sprint. Obviously, there is always room for improvement. But I really saw great work ethic from all my teammates this Sprint. From start to finish, we were working at a phenomenal rate. And we were communicating very well. We communicated much more this Sprint than the last one. Even creating days where we all met online outside of class to further our collaboration. I am very proud of the team. If I was to nitpick anything, it would be our Issue board. It is not easy making a board that flows. We need to work on breaking issues into smaller ones. And try to better define the issue. Some of our issues you look at and it’s kind of hard to decipher where you would start or how you would approach the issue. I must add, this was an issue during the first Sprint, and I saw much improvement during the second Sprint. It’s just simply we can continue improving.

One conscious effort I need to make for improvement during the next Sprint is my Gitlab Contributions. I just don’t think I have been working enough inside of Gitlab. There are so many small things that I can do for our entire Project page. From creating more issues, comments, fixing typos, etc. I just can do much more. Mike has been a great role model for this. His name is all over our Activity page. He actually has been doing a phenomenal job at that, and it motivates me to do more myself. To wrap my feelings about the sprint, I am proud of the team. We have provided 2 demos, and a Vue app build from scratch. The team worked tirelessly to make sure we all have these demos working on our computers. And helping everyone understand all the new information we gathered. I truthfully am excited to move into our next Sprint and keep the progression moving.

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.

Reflection on the Unleash Your Enthusiasm Apprenticeship Pattern

This apprenticeship pattern really tries to tell apprentices, relatively new software craftsmen, to allow their enthusiasm and new set of eyes to help guide older, more experienced members of a group. It encourages us to speak our minds about issues, and offer new solutions that may be looked over by the more experienced members of a development team, but that we can see with fresh eyes. It’s mostly about the value that new developers can bring to a project, and how at this point in our career we can gain a lot from suggesting things, whether they’re accepted or shot down, we will still learn something from the experience, and really there’s nothing to lose.

The thing that I found most surprising about this pattern was that new members of the team are actually pretty important, they cited a study about aircraft carrier teams being more effective with new members, and stated that it is similar in the software field. The new members bring in new ideas and a freshness that the more experienced group members have lost, and that it all creates an important balance between experience and freshness. It is important in the early part of our careers that we harness the new, fresh, outlook on the field in order to bring more creativity to our projects, find new ways of doing things, and are given the opportunity to advance and learn from people that have been around for a long time. And then we will eventually get to be the ones to temper the new apprentices’ expectations, and teach them, but also learn from their ideas. It is just fascinating to think that we are part of this ecosystem that has lasted for generations of developers and that despite our relative inexperience we are still invaluable assets.

I know that after reading this, I am feeling a lot less nervous about graduating in the next few months and that my contributions to my future development team will be necessary for their survival, and I’m excited to learn what I can from them. However, I’m not sure how the “Solution” part of this pattern really addresses the core tenant of the pattern. Yes, it is a good idea to make sure that your voice is heard and have a more experienced person tell you if there are flaws in your idea and where to improve. However, for many of us, we’ve never really been in a professional environment so it is kind of hard to achieve their solution. However, I don’t think there is a real issue or something I disagree with, but it just seems like it isn’t fully attainable for everyone.

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.

Apprenticeship Patterns – Nurture Your Passion

For this blog post, I have chosen the “Nurture Your Passion” pattern in which this pattern talks about how one should keep their passion for whatever they are doing secure from the inevitable draining activities that will harm your passion. When one progresses into their career, the circumstances will change and the activities you used to do for enjoyment will soon turn annoyances or be in such a crunch that there is no time for blank. It is up to yourself to mitigate these issues and to help preserve your passion.

The time of coding and working with all these programs and getting a fully functioning product is quite fulfilling to see. The work needed to get there and the problems that life will throw at your way will make you want to reconsider your decisions however such as trying to sift through countless bugs or being in a less than optimal working environment. There a number of different options to consider when trying to mitigate this issue, such as exploring different forms of media that contain information that you would like to look at or interacting with different people with the same passion to help bolster your own. The book goes into different patterns that describe these solutions such as breakable toys and kindred spirits where you have these different resources to use to help keep you going.

This pattern does indeed resonate with me as while coding has started out as a side hobby, quick and enjoyable with no commitments to it whatsoever is slowly changing to me more intensive and time consuming leading to generally less enjoyment. This makes me think of the eventual future of potential crunch times and unenjoyable meeting that will take place in which I will have to start picking up new skills to help mitigate these issues such as improving my communication skills incase any situations such as bad interactions with other people in the workplace could be solved by talking myself out of it. There is the chance of a new hot idea in the future that I could latch onto to help keep my interest up and going.

From the blog CS@Worcester – kbcoding by kennybui986 and used with permission of the author. All other rights reserved by the author.