Category Archives: Week-15

“Record What You learn”/”Share What You Learn”

This is the last blog post for Individual Apprenticeship Patterns, I want to end with “Record What You Learn”. Most of what we were talking about was learning and how to apply it to the real world. I thought this is important because I am also doing this in daily basic. I keep making same mistake, and I learn to avoid it slowly. There are issue I just need to more practice to avoid, but there are mistakes I could have learnt. The book suggests that some platform to write down. Ade uses two instances of the same wiki, one for his private thoughts and the other for stuff he wants to share with the world. That is the good idea, some from my mistakes I didn’t want lets other to know about it. But after this book I wouldn’t mind others to check on my mistakes. They could help me to fix it or at least I will learn from it.

By said that, I also want to connect this to the next pattern “Share What You Learn”. Like I mention above, we could become a journeyman, the ability to communicate effectively and bring other people up to speed quickly. We learn what need to be share and what shouldn’t. It does not matter what you take note for yourself. Before share to others, you need to think if that will have negative effect to them or even to the team. This could damage the relationship of the group. They also suggest that shared as blogpost about the lesson which is soft of what we are already been doing. In blogpost we also could share our solution and have conversation with other.

This is my final thought of the book. I think this book is good on the guideline on the ethics side of the industry. I also have honest advice from experience people. They gave short good example/advice that easy to ready. I am will read the rest of the patterns and keep this book with me.

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

The White Belt

For this week’s blog I have decided to write about the chapter called “The White Belt” from out textbook. The context of this chapter is that you have developed a deep understanding of your first language but have plateaued and you are rather comfortable with that spot. I find this to be exactly where I am now. I have spent four years writing in Java a majority of the time. I would say that Java is the language I feel most comfortable in, and have the strongest understanding of how it works. Other languages that we have touched upon in my college career such as C and typescript/javascript, I am not as comfortable in because of this lack of depth of knowledge in these languages. This leads us to the problem portion of the chapter, which is that we have problems gaining knowledge of new things when we are coming from a position of comfort. The book points out a fear of personal development coming to a halt, and I think that rings true with me. I am afraid that once I leave college I will not learn as much as I need/want to. I am afraid of being a “one trick pony” with Java. What if my job requires me to code in C? C++? Any other language? I feel right now in this minute that if this were the case, I would be able to get by, but just barely and not very comfortably. And that is a feeling I do not want to have every Monday through Friday in my career! So how do we fix this issue of complacency? The book starts off the solution with a quote from Star Wars, which I thought was genius. The quote is, “You must unlearn what you have learned”. Now this doesn’t mean go and forget Java and all of its syntaxes and learn another language completely. This means unlearn your learning habits, keep your knowledge of Java but also learn to gain a knowledge of another language. Keep doing this, and soon enough you will be a master of programming. I find this solution to be rather comforting as I also find myself in this position of plateau quite often. I am hoping to continue my education of coding long after I leave college.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Sustainable Motivations

There are many things that can motivate us to be programmers. Some of them can motivate for the long term, while others may not be sustainable. We may become very good at a particular language or framework. This specific expertise may very well translate to a larger paycheck. But if your true goal is mastery … Continue reading Sustainable Motivations

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Sprint 6 Retrospective

Sprint 6 lasted from April 24th to May 6th. This sprint, my group and I had a main goal to focus on completing a powerpoint of our final project to present to the class on May 15th. Unknowingly, we instead spent most of our class time trying to merge and integrate our project with everybody else’s, which in turn broke some of our features and we never fully completed this integration.

While my teammates worked through those issues, I spent a lot of time trying to merge my completed dropdown button feature on to the main branch. This was also unsuccessful, partly due to merge conflicts since minor fixes and contributions were being pushed at the same time I was trying to push my own changes. My feature has been working on my own local branch for quite some time, in fact it was easier to develop the dropdown button than it was to merge it with everybody else’s project.

Working with professor wurst, I created a new branch that included my feature since attempting to push to the main branch wasn’t working. I tried creating a new folder, pulling the most up to date branch on a clean slate, then rewriting my changes in class which only took me about an hour. This plan was also unfortunately unsuccessful. Ultimately, as the deadline for the end of the sprint drew closer, we had to compromise on some of our more ambitious goals in order to start work on the presentation, which was meant to be the focus of the entire sprint.

I was still able to write about the ins and outs of my dropdown button, and I included screenshots from my local running branch. Thankfully, I believe I will have much to talk about. I will explain in depth some of the code lines and how they tie together with the modules and components necessary to make the whole thing work. I also want to include references to where I got the idea for the dropdown, since I stumbled upon a very helpful website that included HTML sample code for me to modify and trim down to fit our projects needs. I lastly will talk about how our work can be improved in the future. Our project contains a lot of filler text and our buttons don’t do much besides display text on the screen. To fit more specific needs, the text can easily be changed and more functions in the HTML can be added without necessarily changing the buttons around. Some ideas would be displaying various messages, videos, or information otherwise that would fit a more specific need depending on who will actually be using the app. Ill include a link to the presentation below this paragraph.

https://docs.google.com/presentation/d/1mJS7XpGuvMmKmI_LZyf-CLtPi8Xi8Ft_8yVu3f09ewk/edit?ts=5cc73c24#slide=id.g59df31ee4a_1_27

Overall I think we will get a good grade on the project, on our presentation, and on the class as a whole. I enjoyed this class more so than some of the others I took this semester, and I feel that I had more motivation to put in more effort into this class than some of the others.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

Study the Classics

Before I became a Computer Science major and aspiring software craftsman, I was very much into reading what many people would consider “the classics”. Whether it was the Iliad and the Odyssey or A Brief History of Time, I have always been fascinated by works of literature that had such significant content or perspectives on the world that they were revered throughout centuries as “the classics”.

So when I came across this pattern, Study the Classics, I immediately resonated with the context they put forth and their motivation for including it in their book. The solution / action which they suggest to us budding apprentices is to collaborate with others and ask about a concept unfamiliar to us and to try and seek out the book which that concept was written about.

Immediately my mind drifted back to learning the Gang of Four’s software design pattern book, which I know for a fact to be highly revered and considered one of the “classic texts” in our craft. Even when I first read it for school assignments, I was enamored by how rich the concepts were and how articulately they were explained. My learning and overall understanding of software development as a whole is unquestionably markedly better than it ever would have been had I not been exposed to this book.

At the same time, I am aware that as good as this book is, and as valuable and timeless as the information in it is, it is definitely not a holy bible for software developers. There can not exist one text to rule them all, because there is no single entity capable of compiling everything we would possibly want or need to know into a single source. So in the future I will definitely seek out multiple individuals or groups of authors who are very well known and revered in our field, so I can add their works to the collection of books I need to read to be as knowledgeable and as prepared as possible for the uncertain road that lies ahead of me in my journey to competence in software development.

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

Apprenticeship Pattern “Learn How You Fail”

For the final pattern that I will be writing about for this capstone, I wanted to write about something that I’ve felt for a while, but I did not know if my intuition was correct. I picked this one because of this line, “someone who has never failed at anything has either avoided pushing at the boundaries of their abilities or has learned to overlook their own mistakes.”

I feel that I have faced setback after setback in my life. I like to believe that it helps make me into a better, stronger, and more resilient person. When I struggle to learn something, I find that I understand it more thoroughly than if it came easy. It will also be much less likely to forget.

The struggle is something to be embraced. It should not be a reason to give up. On the contrary, it should be a sign you’re going in the right direction. It’s like a video game where you’re not progressing in the level if there’s no bad guys in the way.

I thought the “action” piece that the authors suggest is an apt one. The long and short of it is that to practice, you should use a text editor instead of an IDE to write an implementation of an IDE in one sitting. Since there is no IDE, it might catch the errors that you would have otherwise overlooked. I have not started studying for my Unix final, and this might be something I might try. However, I think we’re mostly doing things with shell scripts and the like, which is somewhat like a text editor anyway.

I think this pattern goes well what I wrote about in my retrospective just now. For as much as I enjoyed working with my scrum team, we were not perfect. Reflecting on how we fell short will ensure that the next team I work with will be even better.

I find I perform best in the areas that I have reflected the most. A part of it feels like neurotics, but it is important to do it. I reflect on most areas of my life, whether or not I am graded or paid. I feel that it is an important step to self-betterment on the way to self-fulfillment and mastery.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Sprint 6 Retrospective

This last sprint was actually very productive. I feel good about it!

We left off with our form buttons working, however our task was to get the submit button functioning. I believe we had created it already, but it didn’t actually do anything quite yet. We were discussing for some time in a group how we wanted this to work, and I think we ended up struggling for a bit to be able to really understand how to approach the problem. Looking back, this likely came from a lack of really understanding how angular is supposed to function on a webpage.

I believe the majority of us in the group came from the background that our program gave us. That means that we’re used to the object oriented structure that languages like Java use. Java, for example, has classes as the main structure of the program, combined with abstracted classes like Interfaces that all other classes can implement. With Angular we’re using Typescript which is also an object oriented language. We’ve mostly been using components for now, which are essentially classes, and we have yet to use services much in our program, which are essentially interfaces.

In order to implement the functionality for the button, I elected to use a service for it. I did use a youtube video to follow along, but only for understanding where to start. Our group knew we probably needed a click event that created another component, but we didn’t entirely understand how we wanted that to work. Using a service essentially bridges the gap between our form component and our dialog component in this case. Also, by using a service, it creates functionality not only the submit button we were working on, but any future buttons we want to implement that work in a similar way. Services have a decorator, “@Injectable”, which works in a very similar way to Java’s “implements” keyword. By injecting services into your components, you allow any component you want to implement the functions and data present in your service.

We also spent some time yesterday, on the last day of the sprint, merging our branch with the master branch. Some funky things are happening with git currently that I’d like to figure out a little bit better. For example, when pulling the master branch, I got much of the other work that people have been doing. That’s okay and it’s expected, however some of the other components were absolutely riddled with bugs (completely separate from code my group had worked on) that were preventing compilation. I had to spend a large amount of time yesterday fixing and working on the errors in order to even compile and get the angular server running locally, which was quite a hassle. After this, I also had to solve several merge conflicts that arose from pushing our changes to the master branch. These issues were largely found in the app.module.ts imports and everything, and also in files like package-lock.json. Once we resolved this issues, everything seemed to be fine (minus the actual styling of the full application), and we wrapped things up.

All that’s left is to finish our group’s powerpoint presentation and then we’re good to go. It’s been a fun semester, we’ve all learned a lot about the agile workflow, angular, git, and more. Capstone complete!

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Dig Deeper

For the final reflection of my Apprenticeship Patterns series, I’ve decided to choose Dig Deeper from Chapter 6: Construct Your Curriculum. This pattern suggests that you stay conscious of the fact that, as an engineer, you’ll be forced to learn new concepts at a sometimes alarming rate. As a result of this, you’ll likely only learn things at a relatively shallow level of understanding. That is, you’ll only have time to learn what is necessary in order to complete your current task. While this seems like enough, it often can result in issues (bugs and more) in what you’re working on — and it’s limiting your own potential growth at the same time. The solution is to remain vigilant. Put in the work required in order to fully understand a tool. The system, and you, will benefit in the long run if you put in the effort now to learn things properly. Dig into the depths of every concept you’ll be using so you can use it properly.

I’m graduating this month and that means that I’ll be out of formal education for some time. While I do intend to return for a master’s level degree, that won’t be for some time still. And, while I know I’ll be learning a tremendous amount in the workplace, there is still so much more that I want to learn over the next few years that I may not get on the job. It’s the start of my CS career, and I’d like to hit the ground running. I need to make sure that I dedicate time to learning more theoretical concepts at a deep level.

The book draws a distinction between those programmers who have achieved deep understanding over a concept vs. those who haven’t by identifying those who create piles of rubble, and those who create cathedrals. We have a set of tools at our disposal — it’s really easy to use them to create throw things together and construct something that has functionality that is limited to strictly function. However, it’s the true sign of a craftsmen when one can use those same tools in order to create something beautiful. That is exactly what digging deep into each tool you learn can give you, and it’s something I’m going to focus on going forward into my career as a software craftsman.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice

Hello dear readers. Welcome to my last blog post about the Apprenticeship Patterns. This is the 10th Pattern that I really found interesting and wanted to share with you all.

You are graduating, you probably have a job offer (or a few) in the table, you are ready to start this whole new journey and you think you have a good background to create a successful career. YES you do and Congratulations, but it doesn’t end here. You have worked hard to be here but you still got a lot of work to do.

After you Find your Mentor you will see that the Mentor will be giving you different exercises for you to work on based on your skills and weakness and you will see that every exercise will teach you something better or perfect your skills. When you start working in the company, you will face challenges in every project but don’t stop your exercising outside of work. I feel like in companies you apply a very specific knowledge and you would want to be on top of the new stuff that come out if you want to have a good career.

I really like the title of this pattern ” Practice, Practice, Practice”. I used to have a Math teacher in high school and she was always saying “It’s 99% hard work and 1% talent” and I totally agree with her now. That’s why the practice should never stop, doesn’t matter how far up you have gone in your career.

Also look at the bright side, while you just pick random exercises or small projects to work on, you don’t have to worry about deadlines and no pressure. You will notice at the end how happy you will feel about what you have worked on independently.

So just like the authors of this book suggest, go online and find different problems to work on. If you want to feel more challenged find coding competitions and enter them. Don’t worry if you don’t win. You will definitely learn something out of that experience.  After a while go back to where you started and you will see how you have progressed. my last advice you all of you would be: don’t just settle when you start working in a company. Keep growing outside of it. Practice, Practice, Practice…

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

Reflecting on “Apprenticeship Patterns” – Confront Your Ignorance

Here we are – the last Apprenticeship Pattern of the semester! I’ve learned so much about how to successfully transition from a budding computer science undergraduate to a new software development professional. Now that the semester is just about over, I am going to be spending most of my time between now and the start of my new job learning about their tech stack. As I’ve discovered while getting to know the engineering team, I don’t have any experience with the technologies that they use. This brings me to the apprenticeship pattern for this week, “Confront Your Ignorance.”

Confront Your Ignorance pretty accurately describes the position that I am in right now. In this situation, the apprentice has identified several areas or skills that they don’t know much about, and they are interested in learning more. Sometimes, those around the apprentice may already feel comfortable with these skills. The simple solution for the apprentice is to begin “filling in the gaps” in what they know about any skill(s). This could be in the form of articles, tutorials, or Breakable Toys (personal, private projects that allow the apprentice to safely learn about different tools without consequence of failure), among other methods. This pattern is closely related to Expose Your Ignorance, another pattern that I wrote about in the past (found here). While it is possible to keep these patterns mutually exclusive, a balance should be made between the two so that the apprentice feels comfortable enough to share what they don’t know about different subjects with other teammates, as well as puts in the effort to work on it and learn more.

I have been able to relate to each of my discussed apprenticeship patterns in some way, and this pattern is no different. While I am aware that I have a lot of ground to cover in order to understand as much as I can about my company’s tech stack before the start date, it will be great to combat this by confronting this ignorance head-on with multiple learning strategies, mostly by reading more books and completing online coursework.

Thanks for reading! I hope to keep up with this blog as I continue self-learning throughout my professional career.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.